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.
Category(s): agile, User Experience
Tags: , , , , ,

7 Responses to From Sketch to Code

  1. Interesting, I`ll quote it on my site later.
    Thank you
    Charlie

  2. It’s a good statement you’ve written. Especially on the mathematical explanation. Though there are still a lot of variables that results in different work methods.
    I recognize that what you’re saying often applies to smaller projects. But with larger projects involving multiple designers and developers, you need a different agreements on how to work together. Perhaps even someone that can stand between both roles.
    So I guess you really have to be flexible and find a working method that fits the best with your team and organization.

  3. Wireframes are needed for a new product/concept/workflow. For small changes to existing application wireframes are definitely overkill. I create quick mock-ups by modifying screenshots in Photoshop.

  4. I usually present not very detailed wireframes to the developers in the sprint planning meeting

  5. (oops, cont’d).

    We then discuss the details of the functionality. In detail.

    During this meeting (usually around 5-6 hours) I capture our conclusions directly into the story (using Mingle). The trick for us has been that we usually negotiate a much less expensive to code solution that still lives up to the overall ux requirements.

    Plus, developers have more often than not insightful input to the ux work – and giving that input makes it easier for them to commit to the sprint scope.

  6. It’s a good statement you’ve written. Especially on the mathematical explanation. Though there are still a lot of variables that results in different work methods.I recognize that what you’re saying often applies to smaller projects. But with larger projects involving multiple designers and developers, you need a different agreements on how to work together. Perhaps even someone that can stand between both roles.So I guess you really have to be flexible and find a working method that fits the best with your team and organization.
    +1

  7. I think the most important part of the process is the dev team and the ux team working closely together and having a lot of back and forth. Good devs love having planning time up front because it allows them to visualize the code from start to finish and see if they are building their own roadblocks. Trouble arises when changes take place outside of the view of the devs (or when the devs go rogue and ignore the UX team and then have to patch it up later on = hack city).

    Having the two teams integrate their workflow is what makes a smooth process. You can’t figure out that math equation without knowing how long each task would take, and that requires input from all sides.

Leave a Reply

Your email address will not be published. Required fields are marked *

 

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>