Published: Jan 29, 2014
This is an excerpt from the article "Developing UX Agility: Letting Go of Perfection" by Carissa Demetris, Chris Farnum, Joanna Markel, and Serena Rosenhan, originally published on UXmatters, June 4, 2012.
Once you have a firm grasp of the goals for a project and the functionality you need to design, the next steps for many UX professionals are creating user stories, wireframes, and prototypes. To kick off design, we often brainstorm and sketch. Often, cutting edge Web sites and a desire to meet or exceed competitors fuel our ideas in part. While you are in brainstorm mode, it’s certainly a good idea to sketch out a full user experience, complete with all the latest bells and whistles that would delight users and impress stakeholders.
But when you begin to craft a user experience for the initial stories that you’ll deliver to your Development team for implementation, you’ll need to be a strict editor and include only the core user interface elements. Limiting scope in this way can be challenging when you are used to waterfall approach, in which you may have only one chance to document all of the user interface elements you think your design should include. However, it’s important to keep in mind that the agile development process works best when you start with simple designs that deliver core functionality to users. While making refinements is important, you can add these later. Just as when you are prioritizing high-level requirements, it’s best to start your designs with the simplest thing that could possibly work.
Imagine that you are designing the Gizmo shopping cart. You have the task of fulfilling the following business requirement: A user must have the ability to view the items they have added to their shopping cart and make purchase decisions. While in brainstorming mode, you might think of many ideas for features that you would like to include in your design–for example:
When working in an agile context, you want to start development of the most essential features first. Wait to define less critical features until later iterations. At this point, your design should be more like a haiku than an epic poem. A good start might be a simple list of the items in the cart and their prices, with the ability to remove items from the cart, view the order subtotal, and check out, as shown in Figure 4.
Figure 4 – Shopping cart wireframe with a list of items in the cart and their prices, item deletion, the order subtotal, and a Check Out button.
Since the object of agile development is to get to working code quickly, this may be enough to keep your team busy for the first sprint. Meanwhile, you can work on the design for the next iteration, adding user interface features that would enhance the shopping cart experience. Perhaps you might add the ability to view more product details and product images and change quantities, as shown in Figure 5. In the third iteration, you could go even further by adding the ability to make items gifts and save the cart for later.
Figure 5 – Shopping cart wireframe with product details, images, and editing of quantities
While it may feel awkward at first, you’ll need to take an incremental approach to achieving perfection. There are certainly benefits to scoping your designs to fit iterations. When you think in terms of just enough, just in time, you are less likely to overdesign a solution. Elaborate designs do not always equal a better user experience. Sometimes, providing too many options can get in the way and confuse users who are trying to accomplish fundamental tasks. When you add enhancements incrementally, you also have time for gathering feedback and doing usability testing earlier in the development process.
If you want to hear more about Chris’ thinking on design deliverables, check out his virtual seminar: Choosing the Right Wireframe Strategy for Your Project.
As a UX designer at ProQuest, Chris is a senior member of the Agile UX team and contributed to the design of the ProQuest search interface and Serials Solutions Intota. Learn more about Chris on Twitter by following @crfarnum.
How does your team limit project scope in the early design stages? Tell us about it at the UIE blog.
Read related articles: