Tag Archives: documentation

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.

Two Ends of the Spectrum

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.

Put Another Way

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 Bottom Line

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.

Going Back to the Source: The Agile Manifesto

There are a lot of different ways to implement agile. That is one of its strengths. Agile allows you to create exactly the process that works for your team, company, problem, and client. However, it also gives teams the responsibility to create that process, and that is difficult. Teams typically can’t rely on doing things the way they’ve always been done.

Whatever practices are put in place, be sure that you are true to the agile values and principles. I’ve been interviewing with many companies over the last 6 weeks <shamelessPlug> (I am available for work in the Boston area) </shamelessPlug> and I’ve been surprised at how many people are talking about agile, have not read the manifesto, and think that agile is about sprints, daily meetings, and a lack of big upfront design.

Agile is 4 values and 12 principles. Period. It doesn’t say whether to do upfront work or not, or to work in sprints, or to have backlogs, or to start coding right away. These are techniques that some teams have used based on agile, and others have codified into practices such as scrum, but these practices are like the reflection of the moon in a pond. If the water is choppy, the reflection is broken and unrecognizable. If the water is still, the reflection is very clear. Yet, as alluring as that image may be, it is still not the moon.

If you have never read the manifesto or haven’t in a while, do it now. Really. Go. I’ll wait. It’ll only take a minute.

Back? Great.

One of the values is “Working software over comprehensive documentation”. It doesn’t say don’t create documentation, but place a higher priority on working software over comprehensive documentation. Focus your priority on creating something that works more than an exhaustive description of something to build. Make sure that the documentation the team chooses to create has lasting benefit.

The values are not absolutes, but relative statements. If you adopt practices associated with agile without understanding the conceptual underpinnings, you may find that you are not getting the effect you hoped for, or maybe there are better practices that would support those values better given the unique situation of your team. A team that adopts the practices without incorporating the principles will be like like the moon’s reflection on choppy waters. It will be tough to see a coherent vision of what is being done. A team that chooses its activities based on how the values fit them will be like the reflection in a still pond.

For me, one of the most evocative parts of the manifesto is the last principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” That alone, is worth the price of admission.

Please take a moment to rate this post (under the title) and leave your comments. Which elements of the manifesto does your team most embody?