Tag Archives: User Experience

From Sketch to Code

By 7 commentsagile, User Experience, , , , ,
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.

Is ‘Good Enough’ Good Enough?

By 5 commentsagile, , , , ,

Fast, good, and cheap. Pick two.fastgoodcheap

This is the familiar instruction represented by the project triangle. A project that is of high quality and delivered quickly will be costly. One that is done well with limited resources will likely take time. An inexpensive project delivered quickly will suffer in its execution. Keeping this in mind, compare waterfall with agile.

Waterfall demands a certain level of quality. All of the upfront research and design, as well as the many gates and checkpoints insure that when the product is released, it meets the expectations defined up front. Waterfall projects can be good and fast, or good and cheap, but the underlying notion is good. Now, experience tells us that the definition of ‘good’ can vary greatly on waterfall projects. ‘Good’ can mean that the end users find the product useful and usable, or that the project is predictable, i.e. that the budget is met with the expected scope, or that the target date is hit and the expectations of scope are managed. I’m sure each of you has experienced many variations on what stakeholders consider ‘good’.

Agile chooses fast and cheap. Sprints are short and teams are small. There are many good reasons for this. They are well documented elsewhere, and include getting working software to users faster, being able to address high priority problems quickly, and abandoning features with little value. With this approach, the mantra for each sprint is ‘good enough’. When choosing fast and cheap, what is sacrificed will be quality. At least initially, this may be true, but agile counters this by adding many revisions following quickly on the heels of an initial release. Problems can be quickly identified and fixed in the next release, which may be as little as two weeks away.

This requires a significant shift in thinking for User Experience. It is our job to ensure that the users have something they find valuable and easy to use. We think big thoughts about mental models and context and integrate detailed thoughts on layout and implications. We have been accustomed to defining the entire picture, making sure all the pieces fit, before moving on. It can be very challenging to take one piece of a larger project and just get it to ‘good enough’ while ignoring the rest of the system. We are judged on how the product looks and behaves. Sacrifices made for expediency affect our credibility and reputation.

We also may have different ideas of what constitutes ‘good enough’. To a prototypical engineer, it may mean that the feature is present and functional. For UX, it’s about utility and ease. A product owner may fall somewhere in the middle. Its important for each team to agree on their shared definition of ‘good enough’. If forced to work under the simplest extreme of ‘functional’, we may not be pleased, but at least our target is clear and we know what to work towards.

This change in thinking is a key challenge to successfully integrating UX and agile. One approach is define a rough, high-level vision so that all involved can get a sense of the whole. During each sprint, or prior to each sprint, fill in the details of the pieces, or stories, about to be built. It won’t guarantee that there won’t be rework, but it will help balance the need for holism with the need for speed. If you don’t get it right this time, there’s always next release.

Adopting Agile is Hard

By 1 commentagile, , , ,

Before getting into the details of our particular challenges, I wanted to acknowledge, for all of you going through this, that adopting agile is hard, perhaps one of the biggest professional hurdles I’ve faced in recent history. While I’ve been in the same industry for about 12 years now, I imagine this is about as close as you can come to switching careers without actually doing it. You think you know what’s going on, but the rug keeps getting pulled out from under you. However, I also like the term ‘adopting’ because this is similar to adding a child to your family.

When you have a kid, your life is no longer the same. You’ll sleep less. There will be lots of screaming, and you will have to clean up more crap than ever before. Moving to an agile process seems a lot like that. The hope is that once you figure it out, life is better and you wonder how you ever lived without it.

Even reading about agile can be as confusing as negotiating the parenting section of a bookstore. Want to know how to get your baby to sleep at night? Here are 20 books that all say something different. Want to adopt an agile process? Here are multiple options, each with different interpretations.

To be fair, the looseness of agile, and scrum in particular, is one of the things I like most about it, and what also causes the most pain. If you were to ask a personified scrum process what to do, the answer would likely be, “It depends.” It may be true, but it doesn’t feel helpful.

Agile is more of a philosophy than a process. It dictates very little. We have five scrum teams working concurrently and each one works a little differently. One team has a number of outsourced members across the globe. Two others are working on entirely new initiatives The last two are refining existing parts of the site, although they move from making small tweaks to significant additions or revisions. Some teams do more costing and planning for each sprint, while others are very loose. Each of these teams have developed their own idiosyncratic scrum process that works with their unique situation. This is one of the powerful elements of the agile methodology, the flexibility. It is also one of the biggest challenges. Teams must define their process for themselves. Scrum only provides a framework. Each team is trying to do what is best for their people and their project, but it can be very difficult to work across multiple teams that are working differently.

There seems to be a sense of the serenity prayer to it. Agile is a new process and will require a lot of change. However, realize what you won’t be able to change and find a way to work within those constraints. I appreciate that this process acknowledges the realities of organizations and attempts to work with them. I found Ken Schwaber’s book Agile Project Management with Scrum very helpful in demonstrating this. In this book, Ken presents case studies of teams in different circumstances at different companies. In one case study, knowing that the program management office required Microsoft Project files for status reporting, the Product Owner adapted scrum reporting to fit within Project’s framework. Rather than trying to get another part of the organization to adapt in a futile battle against the windmills, teams in this book found ways to improve their process while working with the constraints they had to live with.

So if this feels painful or impossible, that’s normal. It means that you’re going through change. Recently, our Program Manager and resident certified Scrum Master attended a conference with two major agile gurus. After listening to the other people describe their problems, he says that he came away feeling that we are doing quite well compared to a lot of other companies! Given how hard it has been for us, I really feel for those who are not quite as far along the path.

As we figure things out, I’ll share what I can. Until then, if you have any questions, I may respond with, “It depends.”

If there is something particular that you would like me to write about, visit the Suggest a Topic page. You can vote on existing topics or add your own. I’ll do my best to address them in a reasonable time frame.