Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

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?

share|improve this question

This question has an open bounty worth +50 reputation from Michael Lai ending in 3 days.

This question has not received enough attention.

I would like to know whether it is considered important both in terms of risk analysis and implementation effort estimation to try and track the stability of a UI component or a design concept in an Agile + UX project.

    
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 21 hours ago
    
@DaveAlger That's exactly right! –  Michael Lai 15 hours ago
    
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 2 hours ago
    
@Jonny I have updated the question with the link –  Michael Lai 2 hours ago

1 Answer 1

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.

Automation

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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