Agile design and usability: Will a prototype do?

The Agile Manifesto includes twelve principles. These two are related:

Deliver working software frequently [in short sprints that last] from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Working software is the primary measure of progress.

From discussions with other practitioners, I know that software teams can get dogmatic about the above principles, and often work in sprints of one, two, or three weeks in duration to ensure they deliver frequently. Since the classic software-development problem has been delivering the wrong features too late, I understand the desire to deliver working software frequently, with more frequent opportunity for customer feedback.

When the “deliver frequently” principle becomes a fixation, though, other things can get bruised in the rush to produce working software. Consider design and usability research. Sometimes a system’s features are complex and interrelated. Sometimes an elegant and simple solution is elusive. (Technical limitations can contribute to this.) Sometimes a weak design needs testing to make sure it is usable. To ensure design and usability work gets the time it needs, this work is often moved to preceding and successive sprints. This sets the designer and usability analyst apart from the rest of the team.

Here are my ideas to help design and usability work integrate better into short sprints:

  • Ensure a designer understands the entire set of features before the first sprint. Ask for a broad-strokes design for the whole, and share it, so the team has a vision for the user experience. Before a sprint completes, compare the working software to the user-experience vision.
  • Agile tries to keep the deliverable as simple as possible, but simple features from different sprints may not combine into a good user experience. This is a defect, to be fixed like any other bug, before the sprint completes.
  • Ensure that usability and design bugs are resolved, by testing with users to validate the changes.
  • When you need work done that substantially shapes the user experience but that is not related to a specific feature, regard this user-experience work just as you regard database, architectural, or other foundational work. Foundation work is easier for the team to prioritise when planning a sprint.

The above suggestions work within the “deliver working software frequently” principle. I have another suggestion that pushes at Agile’s envelope.

It works!

I think the words “working software” are too restrictive. In my opinion, there are other deliverables that are equal to working software, especially for teams that use very short sprints. A deliverable such as a paper prototype or a low-fidelity interactive prototype is equal to a piece of code, and allows team members—all team members on an Agile team—to focus on design, prototyping, and validation together instead of making a designer or usability work one sprint ahead or one sprint behind the rest of the team.

Teamwork reduces design risk

It takes a range of skills to develop a product. Each skill—embodied in the individuals who apply that skill—brings with it a different focus:

  • Product managers talk about features and market needs.
  • Business development  talk about revenue opportunities.
  • Developers talk about functionality.
  • Usability analysts talk about product- and user performance.
  • Interaction designers talk about the user experience.
  • QA talks about quality and defects.
  • Marketing talks about the messaging.
  • Technical communicators talk about information and assistance.
  • You may be thinking of others. (I’m sorry I’ve overlooked them.)

What brings all these together is design.

Proper design begins with information: a problem statement or brief, information about the targeted users and the context of use, the broad-brush business constraints, Design as a teamsome measurable outcomes (requirements, metrics, or goals), access to a subject-matter expert to answer questions about the domain and perhaps to present a competitor analysis.

Design continues by saturating the design space with ideas and, after the space is filled, analysing and iterating the ideas into possible solutions. The design process will raise questions, such as:

  • What is the mental model?
  • What are the use cases?
  • What is the process?

The analysis will trigger multiple rapid iterations of the possible solutions, as the possible solutions are worked toward a single design:

  • Development. What are the technical constraints? Coding costs? Effect on the stability of the existing code? Downstream maintenance costs?
  • Usability and experience. Does the design comply with heuristics? Does it comply with the standards of the company, the industry, and the platform? Does paper-prototyping predict that the designed solution is usable?
  • User experience. Will the designed solution be pleasing due to its quality, value, timeliness, efficiency, innovation, or the five other common measures of customer satisfaction?
  • Project sponsor. Is the design meeting the requirements? Is it reaching its goals or metrics?

It’s risky to expect one person—a developer, for example—to bring all these skills and answers to the table.  A team—properly facilitated and using an appropriate process—can reduce the risk and reliably produce great designs.