How/Why/Should you “Refactor User Experience”
The UPA Conference was great — it was especially useful to see the wide range of experiences from the UX trade with agile methods. The diversity of scenarios is tremendous.
I originally considered submitting the topic of this post, refactoring UX, to the Agile 2009 conference, but decided that the notions I was working with were too far away from the strict definition. Refactoring code is producing identical results with better structure. The general notion I’m presenting here is that there are similar methods around UI design and flow that can achieve strong gains in user satisfaction and an improved platform for new features.
The workshop attendees responded to this notion and we talked about it for a while, producing the notes below:
The notes were crafted during a dialogue around the notion of “Justifying UI Refactoring to the Agile Team” although we agreed that we probably shouldn’t actually use the term refactoring. In an ideal scenario, UI reworking at large scale [Edit] would not be required, so premise #1:
1) Avoid it
* Vision - think ahead
* Expection setting
* Delay decisions to last responsible moment
* Parallel tracks
There can be a lot of user impact if you do need to change existing functionality. One approach to this is making gradual iterative changes towards the new design. This is both more user friendly and more aligned with the agile way.
2) Hinting
* Gradual changes based on vision
* Inconsistency between releases is ok
** Focus on UX at release level
* Get big design work done first, widgets later
And alternative to hinting, is a simultaneous beta or preview:
2a) Ship multiple versions to get feedback
Finally, if you have to make a big change, make it so obvious that there’s little chance of pro-active interference between the new UI and the old. We called this “Hitting the reset button” and it requires that the team consider UI as a feature and address it the normal flow of stories.
The dialogue was a productive initial socialization of the concepts and I firmly believe that there’s more for the UX discipline to contribute to how user experiences are best grown while being used.
Thanks to Thomas Lissajoux for some out-of-band dialogues on this topic and to the workshop participants. The UPA conference proceedings are due out shortly and should provide good fodder for more recounting.
Jeremy Kriegel
June 30th, 2009 at 1:52 pm
Sounds like an interesting discussion, but I have to take issue with the notion that in “an ideal scenario, UI reworking would not be required.”
Even if we’ve done the most comprehensive research (rare, and not very agile), made the best possible user-centric decisions (rare due to other project constraints), and even done some testing along the way, I still believe we would learn something new once the final design was released into the wild.
Software design approaches completeness asymptotically.
The more likely scenario is that if the design was done so well, that the gap is so small that it is more valuable to spend time on other stories than on refining that existing one.
andy
June 30th, 2009 at 3:54 pm
Thanks Jeremy, I edited the post to clarify “UI reworking would not be required.” We were talking about large scale , far reaching changes to features already in heavy use.
The challenge we were dealing was how to grow from a relatively simple feature to a grander scale. This may require significant changes to existing workflows.
A related use case is revisiting the overall design coherence to improve consistency, where needed, and better separate functions which are distinct.