The concept of a stability index where the likelihood for the content, where it is code or a specification (e.g. in the documentation of the Node.js API) looks to be rather useful and can be adopted for use in a design or style guide/document.

Since the design pattern or a UI component are generally an evolving aspect of the software, some aspects will inevitably change, with other aspect becoming more persistent and stable than others. Where there is a high likelihood of change or instability, it is practical to document so that designers and developers can be made aware.

Is this a useful concept to include when documentation UI design patterns and components in a print or digital style guide? Has anyone seen the implementation of this concept anywhere?

  • are you strictly asking about how likely a section of documentation is to change or remain the same? are you suggesting that some patterns in a style guide are more stable than others and want to indicate this in the style guide itself? – DaveAlger May 22 '15 at 13:55
  • @DaveAlger That's exactly right! – Michael Lai May 22 '15 at 20:49
  • Would it be possible to give an example of what a stability index looks like? Maybe one showing a high and one showing a low stability? I may not be looking right but I couldn't see them in the nodejs docs. – Jonny May 23 '15 at 9:07
  • @Jonny I have updated the question with the link – Michael Lai May 23 '15 at 9:27
  • I think it's a deeply interesting question and is very common in API design documents. – Kit Grose May 26 '15 at 1:00

It would be really hard to measure the stability of a pattern within the context of UX and particularly with its UI components.

Regarding UI

Monitoring for instability definitely makes more sense in the development context rather than design although you do some roundabout things to check for continuity in how people interpret your UI components. For example, if you have them catalogued you could routinely subject the individual elements to testing via an online tool e.g. http://fivesecondtest.com/ and evaluate if there are any variations in perception with a large enough swing to suggest a problem.

My hunch would be that you'd not really notice any difference over time with UI components. If they're bad or problematic to begin with then that problem will likely persist. Take the infamous 'hamburger icon' that has been around since the Xerox Star's implementation of the first GUI and it is a still misunderstood despite 35 or so years of use. Likewise if you nail it and have something super clear that becomes ubiquitous like the 'cog icon' for settings then you kind of know that is going to work long term. (personally I still think the cog can be misleading but it's helpful in it's universality across languages nowadays).

Regarding Patterns

Testing the stability in UX patterns is more about reliability and effectiveness at delivering strong UX and helping serve business goals rather than the way you might measure things from a dev perspective. So with that in mind stability testing of UX patterns already exists as User Testing (http://en.wikipedia.org/wiki/Usability_testing).

The user and how their perceptions change over time are what guides patterns as well as UI and is what you would measure stability against. That is why User Testing exists as a discipline because it's where we measure change in users' understanding of their digital environment and whether a company is successfully sequencing there customer journeys to increase conversion etc.


I guess your question asks if there is room for more automation in all this? I'd say there absolutely is, but humans are infinitely varied in their behaviours and there's only so far we can go. We measure the common behaviour and cater to that whilst trying to support the novice and the power user. The better businesses, designers and developers become at defining their requirements the more opportunity there is for scripting testing processes that are hands free from a User Testing practitioner perspective.

I do like the idea that as patterns become more established then if you are using a well known one you could run simple automated test that would check if your website would convert better on a different one etc. At the moment the whole idea of 'patterns' is still quite fragmented and unordered, I guess over time (like everything in the digital space e.g. UI design, Visual Design, IxD) a more specific job role might emerge such as 'Digital Pattern Architect' and it's those professionals that will name and catalogue that space. With that cataloguing and specifying it becomes a thousand times easier to remotely monitor patterns without putting User Testing professionals in a room with people to distill their problems into tangible, actionable UI and pattern improvements.

In summary...

So essentially I'm saying that from a Pattern perspective stability is already measured but will surely become more automatically monitor-able over time. In terms of UI components they need to be tested and defined successfully early on but their long term success won't change enormously. It's worth noting that UI is device specific and as we never know what new devices are around the corner it must still be reviewed regularly. Devices and visual trends will change but users wanting clear, consistent and navigable UI's won't. That's why we always start and end with the user.

I hope that helps and I haven't completely misinterpreted your question!


I think it's an interesting question to ponder, but I don't know what the relevance of the answer is:

  • In the API case, the stability indicator is for the programmer to determine whether (or how much) he wants to base his implementation on this API (as opposed to implementing the functionality by himself, or using another library with another API). If the API changes, it means additional work for the programmer - at a time he does not control himself, but which is controlled by the API developer.

  • In the UI guideline case, stability would indicate how much positive evidence we have, that this particular pattern (or icon or...) works. Even if this can be monitored objectively, what is the message to the developer? Is he free to ignore guidelines which are not yet "Stable"? I don't think so, because then they should not be part of the guideline. The guidelines shall be followed, even if they are just made up without evidence, since they guarantee consistency (at least one reason for them).

In addition, I am not sure how you want to arrive at a "Stable" rating at all. "Stable" means there will be no changes in the future. How can you guarantee this? Next week, another cool app is coming to the market which pioneers an innovative solution, and over the course of six months, many people in your target group learn and know a new style of interaction. Do you want to stick to your guideline because it was "Stable"?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.