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 Waverley’s newly minted in-house UX design group is proposing how the “sprint-based” approach of Agile development might be applied to the design of a software application. Waverley thanks User Test Lab’s Stefano Dominici whose piece “Sviluppo Agile e User-Centered Design” inspired this article.
Research and analysis
This phase lays the foundation of a successful product design and development effort. Some of our clients have portions of this in hand when they approach us, others will call us as they initiate this phase. It involves an overview of company and product goals, competitive offers, user needs, and, time permitting, formal field (ethnographic) research. This phase ends with a concise statement of project goals, a functional specification, a Statement of Work (SOW), timeline and budget.
Sprint 00: persona, scenario, and story development
These are 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 finished product, 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 and getting on with life. It’s useful to involve a technical lead in this sprint. Stories in particular are critical drivers of production sprints, helping to meaningfully divvy-up the development effort. This sprint ends with a list of personas, scenarios and stories.
Sprint 01: information architecture, task selection, wireframe design
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. The 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 architecture. Again the presence of a technical lead is recommended, since he or she will serve as an advocate of design details during the production sprints. The rest of the technical team can use this time to research techniques required to implement the evolving wireframe. This sprint ends with a rudimentary functional specification including wireframe designs of major screens.
Sprint 02: visual design, asset creation, start production
Portions of the wireframe are “frozen” and their individual UI elements get fleshed out at a pixel level. Simultaneously, production starts on executable code. As before, priority is given to “top” stories, the ones that meet the greatest number of needs for the most important personas. The goal of this phase is to have a working, testable “stub” of the design. This can be used in formal usability testing, in presentations to external clients or management, and as a foundation for the rest of the application. The creation of visual and logical assets continues on an as-needed basis. This sprint ends with a full functional spec including detailed visual designs of major screens and a testable “stub” of the app.
Sprint 03 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. These sprints end with an updated functional spec and a progressively more fleshed-out app that approaches full functionality.
Sprint N + 1: publication
Release of the 1.0 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 can shift. This sprint ends with a finished “version 1.0” app available for download to users and a list of user feedback, often leading to the generation of additional user stories.
Concluding remarks
At Waverley we feel it’s appropriate to apply the Agile methodology to the UX design of an app, for the same reasons we tout its advantages in the engineering and production of the design. 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 timeframes and tasks is essential.