The goals of our prototyping sessions is to gain critical information from our stakeholders on their opinions about our app design. The most important thing being whether they think the design has fulfilled our project brief and do they think it would work in practice. From here, we can add or take away any features they think as they are more knowledgable and because we have been working so closely to this app for a while we may have missed some vital elements.
We created a script that would be asked to all stakeholders so that the information we received was in some way structured and we could easily compare the comments. Here is a copy of our proposed questions:
- Does the prototype do what it’s supposed to?
- Does anything distract you or get in their way?
- Does the navigation path work? (Can users find what they’re looking for?)
- Do you think this fits the target market?
- Is anything confusing or unclear?
- How likely or unlikely would you be to recommend the finished product to a friend or college?
- How would they describe this product using their own words?
- Does this app solve the problem?
- What, if anything would you change?
We first of all get the basic questions out of the way and then we see if it is practical to use and easy to navigate. The usability sessions are needed to highlight if anything is unclear to the average user as we need to make is as user friendly as possible.
In the session, we would start off by introducing screenshots printed on A3 to give an outline of the features of the app and the design aesthetics. Also, we would show them how the app would be accessible in daily life by showing them the poster we designed with the QR code on. We would explain how this would be posted through letters boxes juts like they do every time there is a community consultation meeting. However, highlight this would minimise paper because from there the app allows notifications of new developments. This task is so they can see everything together to see if anything stands out immediately.
Following on from this we would then pass them a phone with the app loaded as any other user would see and give them tasks to reach certain pages. This would tell us how the app performs and makes it easy for them to express if they get stuck at any point. In the session, we would try and follow the questions so there is structure and they don’t go off on a tangent. It is also to ensure that the conversation is relevant. Our sessions will be private so that it is not too noisy so we can properly explain and can have a conversation with no distractions.
In terms of the 5 act interview from the Sprint Book, we would have already done a friendly welcome as we greet them at the meeting place and we will start to introduce the prototype with the A3 paper. The questions will follow merged with the tasks and the debrief will come at the end concluding the session.
Hello team, thanks for the detailed account of how you planned for your prototype demonstrations. This will have hopefully enabled you to gather some good quality feedback from your stakeholders. A few things could be noted: (1) instead of referring to the goals in the brief, it may be better to restate the goals you arranged following on from the client workshop in week 1 (it also helps to remind what your project goals were). (2) you mention the outline of the five-act-interview, perhaps go further into detail and map your prototype demo onto the outline suggested. For example your introduction using A3 sheets of paper introducing the touch points for your app on the ‘road’ may be a very good way of starting with the context in which your app comes to live. I would be interested to see how your participants responded to this approach. I look forward to the final post and also your reflective report.