Crafting walkthroughs of the UX prototypes
By: Sujit Devkar
Tags: Product Design, Design, User Experience Design, Prototyping, UX

“If a picture is worth 1000 words, a prototype is worth 1000 meetings.” — Tom & David Kelley

Prototyping is a time-tested method for designing solutions and getting feedback early in the process. As a designer, we collectively, along with stakeholders, solve business problems by envisioning solutions and shaping the vision in the form of tangible interfaces. Here, prototypes are a great way to push our thinking, communicate ideas, and learn from evaluating the concepts. Prototypes help us fail-fast so as to uncover potential design problems and scenarios early on.

“Fail often so that you can succeed sooner.” — Tom Kelley

We all have our own way of prototyping and walking the stakeholders through the prototypes. I would like to share what has worked for me and what hasn’t. Please note I use AxureRP for wireframing and prototyping.

Here are the stages when I use prototype walkthroughs —

Very early in the design

Consider this as an informal evaluation of your concept. Your team has floated an idea and you are sketching it. Feedback on the sketches and paper prototypes ascertain the direction. Your concept may or may not align with Product Owner (PO), Business Analyst (BA). But, once you put it on paper, it gives a channel for discussion. You may also perform initial walkthrough peer designers.

When we build a wireframe, it may be desirable, but it may not be feasible considering the constraints such as team competency or time availability.

“The value of a prototype is in the education it gives you, not in the code itself.” — Alan Cooper

If your business stakeholders give green light to a wireframe that is not feasible in the budget, then you and your team will have a tough time in delivery. Hence, it is a good idea to run it by the internal team like PO, BA, Technical Architect, or the development team.

Walkthroughs at this stage reveal most of the design problems. At the end of every session, we note the changes expected and whether it is a go-ahead. It is your responsibility to fix the identifies issues. We perform the changes as agreed and we are ready for the stakeholder presentation.

When evaluating with stakeholders

We meet our stakeholders regularly to review different tasks in a prototype that are written in user stories. For this walkthrough, we focus on a section of the product that comprises a fixed set of user stories that the development team wants to take in next sprint. We fix the agenda of the meeting with the users and during the meeting, we focus on those items only.

“There are two different types of prototyping. First, the gut sense. You know how far you can take it. Second, you need experts to figure out weather or not it is attainable.” — Tony Fadell

We use tasks based on walkthroughs. Business stakeholders examine the usability of the product. They also evaluate if the product satisfies the needs. A user story based walkthroughs show is the part of the product is ready for user testing or not. The sessions are generally an hour long and we involve only a few people. Thus, the feedback is exactly to the point and revision is easier.

We walk through the prototypes and then work on refinements. Our stakeholders have access to the wireframes as they are available on the Axure Cloud. They can go through the prototype and can come back to us for any doubt or feedback. They have been proactively looking at it.

When evaluating with end-users

Generally, we try to involve new users in every session so we demonstrate the application to a large audience. The walkthroughs are always from the user perspective. We take one task at a time and use the interactive prototype to complete the task.

We record the sessions in MS Teams so the users can access the recording later. Each product wireframe is hosted on Axure cloud with a password and the URL is shared with the participants. After the session, we request users to comment in the wireframe for questions or suggestions if any. Most users don’t comment, and many times they don’t go through the wireframes after the meeting. Some users do need reminders. Thus, we keep accepting feedback for a few days to a few weeks.

“If you think good design is expensive, you should look at the cost of bad design.” — Ralf Speth

You might say, but the users may not be aware of how to use the wireframe? We actually show them how to use the wireframe, how to navigate, how to use hotspots in Axure. Sometimes we request them to demonstrate from their laptop or desktop, how they would perform a task in the prototype.

Some users may not be aware that this is a prototype and not the developed application. So we iterate in our sessions that — This is not the end product. This is a mockup and we can revise it as much as they want, as long the feedback is shared within a given time-window. This has helped the users to know we are not late in the process.

Please note there is also a separate team who performs usability evaluation. We receive feedback from them too that we incorporate as necessary.

Wrapping up

A prototype walkthrough is an effective way to communicate ideas with stakeholders. But, it is not sufficient for usability evaluation. For usability, you must evaluate the tasks with users in separate sessions. A guided walkthrough will help you onboard your stakeholders from business and technology. It will help you build confidence for a business that the product is meeting the needs and for technology that the product can be developed within time and budget. But, ultimately how your users will end up using your product is incomprehensible from walkthroughs.

References

David and Tom Kelley, Creative Confidence: Unleashing the Creative Potential Within Us All

Thanks for reading the article! If you would like to share your thoughts, please share them in comments below.