We’ve all seen it: waterfall projects that deliver the wrong thing, too late. So we understand the appeal of the Agile method, delivering working software sooner, so the intended users—our clients and their customers—can provide feedback that steers us to deliver the right thing. Agile reporting tools also help us estimate how long the work will take, which makes it possible to deliver on time.
But there’s a tension between delivering the right thing and delivering on time. And as a UX practitioners, we sometimes see usability sacrificed in the rush to release on time. This happens despite the first of the Agile Manifesto’s principles:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Valuable software is usable software, among other things. Data about what’s usable comes from testing. And much of that testing can’t take place until after the development—done in Agile stories—is completed and signed off. Development teams—consisting of analysts, developers, testers, usability researchers, and interface designers—often consider an Agile story to be completed despite the lack of feedback from the intended customers about its usability—or unusability. We can do better. Continue reading “Put usability in your Agile backlog”
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, some 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.