Experience Prototyping

So what is Experience Prototyping?

Experience Prototyping is a collaborative approach to setting the design trajectory for a medium- to large-size project. Here's what we do:

Time box the process — As we discussed, for large projects a traditional discovery and design phase can drag on forever. In our approach, we limit the preliminary work to between four and six weeks. We're not trying to define every detail before we start but neither are we abandoning the concept of a design phase altogether. We can accomplish a lot in four to six weeks, to get everything headed in the right direction.

Make it collaborative — A big part of the reasons projects fail has to do with a lack of buy-in from all the relevant stakeholders early in the project. In XP, we make sure business, engineering and design stakeholders are all actively engaged from the start. A small group of representatives have a seat at the table for each meeting as the engagement proceeds. Need to see whether our APIs can be built to support a design? The engineers can take that action item. Need to identify which approach best addresses a pressing industry need? The business leader can pull the right people into the discussion.

Focus on usability and engagement first — We ask ourselves "who is this for and what are they trying to accomplish with it?" If we get that bit right and we focus on making it easy and hopefully even fun for them to do what they need to do, we have a shot at creating something worthwhile. If we don't get that right, we can create the most amazing technological wonder and it will not get us where we want to go.

Test the approach — So we've done a lot of things right. We've brought some smart people from different disciplines into the room and we made sure that we we're all in alignment moving forward. Fabulous! We need to put our ideas in front of some representative users. We've done some research, we've attempted to put ourselves into their shoes, but WE are NOT the USER. Early, while changes are still cheap, we have to put these concepts in front of the folks we intend to serve (our employees or our customers) and see how they fare.

What's wrong traditional approaches?

In a waterfall approach, the BA's document all the business requirements, then the designers put together complex information architecture diagrams. Wireframes are constructed to support every requirement, then high resolution visual designs need to be created and the entire UI needs to be documented. That's slow and it's expensive. It's also self-defeating because there's too little collaboration, too little buy-in and by the time we're ready to code, the business requirements are already changing.

In a dev-focused agile world, the pressure on organizations to produce software quickly is driving down time for discovery at the beginning of projects, frequently to less than two weeks and without sufficient stakeholder engagement.

The majority (58%) of discoveries undertaken by respondents were on the short side — at most two weeks. Unless users are easy to access and the problem space is relatively small, two weeks is too short.

— Nielsen Norman Group

So, in summary, the waterfall approach to discovery and design has been slow, cumbersome and expensive. In some cases, this has led to an overcorrection via dev-focused agile, shortening early design work to the point of being marginally effective or eliminating discovery work altogether.

What does this process look like?

The process should be adapted to the challenges of each project but a typical engagement might look like this:

Week 1 — Focus on identifying user types, tasks and experience-based priorities.
Week 2 — Focus on existing user data, current workflow issues and look for ways to simplify.
Week 3 — Focus on desired state user flow, navigation and information architecture.
Week 4 — Focus on key screen layouts and interface paradigms.
Week 5 — Enhance key screen layouts, adding design detail and enhancing the experience.
Week 6 — Test with a small group of users and make adjustments as necessary.

The meeting commitment for these sessions is relatively light: typically one hour, twice per week for the whole team. Between sessions the designer(s) work on make updates, while other participants may have outside research to undertake in preparation for the next group discussion.

The sessions are led by a senior UX leader, who facilitates the discussion and keeps the conversation focused. And while the process is tools-agnostic, we tend to use products like UXPressia, Miro and Figma.

Outcomes

What gets delivered?

The output of the process is a clickable prototype that has been validated by both stakeholders and users. This prototype can be used to socialize the project, to acquire funding and to gain executive buy-in. It also provides a blueprint for detailed design that occurs during the development phase and offers detailed guidance for coders.

What are the benefits?