From Sketch to Code
One of the issues often discussed regarding the integration of UX and agile is the amount of UX documentation that is appropriate. There are many who recognize the value of a little, or sometimes a lot, of upfront design, while others see it as waste. The answer is less ‘or’ than ‘and’. Clearly a design by itself delivers no value until it is built and delivered, and no one in their right mind would challenge the necessity of software engineers. Most projects could also benefit from some amount of thinking prior to coding. The challenge for each team is to be constantly searching for the right balance for their team, in the current sprint, working on a given story.
I think that most would agree that when a concept is in its infancy and the rate of change is high, it is more effective to iterate through the designs in a lightweight way, without code. Despite how easy it is to quickly generate working prototypes, it is still not as fast as some of the most lightweight design tools, like whiteboard, paper, napkin sketch, or even wild gesticulating. When ideas are vague, there is no consensus on the basic direction, and the impacts are not well understood, it is far more effective to work collaboratively with stakeholders on low fidelity sketches than to create interactive prototypes followed by group reviews.
On the other end of the spectrum, it is far more effective to make small changes directly to the code, and, if possible, forgo the overhead of continuously updating the design documents. At this point, when the design has solidified, stakeholders agree on the vision, and the rate of change is small, let the finished work speak for itself as much as possible. Only update documents to describe complexities that would not be obvious by looking at the finished product.
In the middle are steps that might include one or more of the following; refined wireframes, light ‘throw away’ prototypes, graphical comps, or even detailed specs.
The logical question is when to transition the design to code. Like many agile questions, there isn’t a single answer, but here is one way to think about the question to find an answer that will make sense for you.
It design time is D and subsequent coding time is C1, and code and revision without any upfront design is C2, then the goal is for D + C1 < C2 AND the output of C1 is ‘better’ than the output of C2. If you don’t agree with this goal or don’t believe it is possible then I probably need to convince you of the value of UX to agile (post coming soon).
If D + C1 > C2, then it must be offset by an even greater improvement in quality of C1 over C2. (Thanks to Adam Sroka for inspiring the mathematical representation)
Keep in mind, what makes sense for one team/sprint/feature combination may not work for another. There have been instances where I’ve sat with a developer an said something like, “Take this widget from this page and add it to this page over here and make it look like the other widgets on that page.” No wireframe. No document of any kind. One developer and one UX’er sitting together knocked it out in under 20 minutes, iterating as we went. There have also been complex interactions with impacts throughout the product that required more extensive exploration before the design stabilized enough that development felt comfortable proceeding. It wasn’t unusual to have both of these kinds of stories in the same sprint.
The reality is that you never get to do the same story with the same team in the same context twice, so there is no way to measure the difference. Ultimately, it comes down to a judgement call between the developer and the UX’er.
UX needs to be willing to abandon the design document before the design is complete and collaborate directly with a developer on it’s evolution, and developers need to be willing to take a step back and explore what they will build before writing to much code.
How well does UX and dev work together in your team? Please share your thoughts on this post in the comments and take a moment and rate this post using the stars beneath the title.