Agile UX Design
Agile Development has its origins in the field of software engineering but has proven its efficacy in other creative fields. One such field is user experience (UX) design, and here we are proposing how the “sprint-based” approach of Agile might be applied to the design of a desktop software application or mobile app. Waverley thanks User Test Lab’s Stefano Dominici whose blog article “Sviluppo Agile e User-Centered Design” served as the basis for this document and Danny Hope, UX designer whose work is represented in the whiteboard image below.
Research and analysis
The foundation of a successful product design and development effort. Some clients will have portions of this research done when they approach us, others will call us as they initiate an overview of company and product goals, competitive products, user needs, and, time permitting, formal field (ethnographic) research.
Ends with a statement of product features, project goals and, in some cases, a business plan.
Sprint 00: persona, scenario, and story development
The elements that ground the design process. Personas are fictional but specific: distinct in their goals, technical expertise and areas of concern. They often end up working together through the software, usually asynchronously. Scenarios are situations populated by one or more personas; the finished design is all about positively impacting a scenario. And scenarios, more than any other element, drive content. Finally, stories are the narrative texts that describe an interaction of personas (users) with the finished product, accomplishing goals. Throughout this phase we develop empathy for the personas, so it’s useful to involve a technical Lead in this process. Stories in particular are critical drivers of production sprints, helping to meaningfully divvy-up the development effort.
Ends with a list of personas, scenarios and stories, developed as time and budget allow.
Sprint 01: information architecture, task selection, wireframes
The core of the design. What information is presented, how it’s “chunked” and laid out, and how the chunks link together so that the resulting content and flow meet the needs of the various personas. Key personas and top stories are the drivers here, yielding an “A-list” of tasks. Card sorting and “walkthroughs” of rough designs with flesh-and-blood representatives of personas can be used to support the evolving information architecture, which we’ve found is best represented in a written document (high-level functional specification). The presence of a technical Lead is again recommended, since s/he will serve as an advocate of design details during the upcoming production sprints.
Ends with a high-level functional specification including wireframe designs of major screens.
Sprint 02: specification and wireframe development
The written specification and wireframe designs take center stage as the design evolves. User stories and scenarios continue to inform the process of adding detail and resolving gaps and inconsistencies in the design, which is represented visually and verbally. We’ve found that the concurrent efforts to fully describe a design both verbally and visually greatly enhances the clarity of what is being created. Two parallel vocabularies emerge in these twin product descriptions; both are essential to the felt sense of completeness and coherence that are the mark of a strong user experience. It’s as if the verbal description ensured continuity of metaphor and narrative while the visual description ensures legibility, clarity, and aesthetic appeal.
Ends with a detailed functional specification and detailed visual representations of major screens.
Sprint 03: visual design, asset creation, project estimation
Portions of the wireframe are “frozen” and their individual UI elements get fleshed out at a pixel level. Simultaneously, the technical team and product owner get involved in estimating the difficulty of the user stories and producing a development schedule and cost estimate for a first version of the product. In defining this first version (sometimes referred to as a minimum viable product or MVP) priority is given to “top” stories, the ones that meet the greatest number of needs for the most important personas. One goal of this phase is to have a written Statement of Work which details estimated project costs, anticipated development timeline, intermediate deliverables, and mutually agreeable terms for the engineering effort. Another goal is to have the design sufficiently clear to enable the technical team to provide a reasonably accurate estimate of costs/duration. In cases where the product is open-ended the Statement of Work takes a “time and materials” approach, but an effort is nonetheless made to estimate the cost and timing of a first version.
Ends with finished visual designs of most screens and a signed Statement of Work.
Sprint 04: start production
Production starts on executable code. The goal of this phase is to have a working, testable “stub” of the design which can be used in either formal or informal usability testing (as budget allows), in presentations to external clients or management, and as a foundation for the rest of the application. The creation of visual assets continues on an as-needed basis, and change requests begin to be logged by the client and/or product owner(s).
Ends with a refined specification/design and one or more testable “stubs” of the application.
Sprint 05 to sprint N: design revisions and production
Revisions are proposed based on testing (whether formal or ad-hoc) of the first working stub or stubs. These are passed to the visual designers and engineers along with further stories, duly sorted in order of priority, that are in need of implementation. Production at both the pixel level and the subroutine level continues in alternation with testing, proposed revisions, and delivery. Step by step the app gets built, used, tweaked, and built some more.
Ends with a progressively more fleshed-out app that approaches full functionality.
Sprint N+1: publication
Release of the “1.0” or MVP version and careful monitoring of client and customer feedback. No matter how attentive the design process there are often surprises once an app is in the hands of real users. Some will end up using the app in unexpected ways. Others, through their feedback, will suggest enhancements and extensions we hadn’t thought of. It’s also very likely that the 1.0 release will be partial, with certain second and third-tier stories and wireframes still in the cooker. In this phase the prioritization of what gets finished or polished next will shift.
Ends with a finished “1.0” or MVP app available for download to users and the collection of user feedback. As this feedback is digested, additional personas, scenarios and stories are produced.
A word about revisions
A stated goal of the Agile Development process is to respond quickly and effectively to design and specification changes, even significant ones. We fully support this notion while reminding our clients that flexibility and agility need the support of a budget that can flex with the evolving specification and possible re-work of completed sections. Changes inevitably impact costs, but we’ve repeatedly found that changing a product developed with an Agile process is less expensive and less stressful than requesting and implementing changes using a “waterfall” process.
Concluding remarks
We feel it’s appropriate to apply the Agile methodology to the UX design of a Web application, desktop software application or mobile app for the same reasons we tout its advantages in engineering and testing of those deliverables. Given the interweaving of design and engineering inherent in the production of a successful product, the above approach seems to us a matter of necessity.
As in any Agile process, a firm adherence to sprint timeframes and to guidelines for team roles and self-organization is essential to success.
