Leading the Witness? Prototypical.
Silos Are for Grain: Part 3 of 5
So we’ve learned how to define the problem with pre-design research, here. And we’ve talked about the importance of iteration here. Meanwhile, all along way we’ve been collaborating and getting consensus with the other two members of the product development team: product management and engineering. The result is a proposed solution that has come as a result of “killing our darlings” and receiving feedback from that same product team. Now, and only now, we’re finally ready to actually put a solution in front of some customers.
I’m not going to go too much into best practices around using interactive prototypes, because I’ve already covered that previously. Instead, I think there are three simple changes to how we present that interactive prototype that can give us much better feedback and data to work with:
- Give a task
- Don’t lead the witness
- Keep it on track
Give a Task
This part of the process should be ingrained in us, whether we know it or not. During the iteration stage, we should be working with a problem statement and a persona. That persona should solve the problem through a narrative. And that narrative should be driven by a task. If our narrative is task driven, then why shouldn’t our testing be the same?
There are times where it makes sense to just throw a user we’re testing into the deep end with no instructions and see what they do. The over-arching problem, though, is that users seldom go to applications to simply browse or explore. They want to accomplish something. So when you are crafting your prototype test, build it around accomplishing a task and see how effectively they can do it.
Whether or not that task maps to the user’s problem should have been defined in the Recon step of your design process. Framing the data through the task you’ve given the user will make it much more specific and actionable.
Don’t Lead the Witness
One of the biggest threats we face as designers, is confirmation bias. We want our intuition to be right, because our intuition and design sensibilities are the value that we bring to the product development table, right?
Wrong. Our greatest assets should be our strategy, process, and visual execution. When it comes to intuition we have to accept a very simple fact: we are often wrong. We must begin every prototype with the assumption that what we have created is totally off.
That is what makes the task driven approach to testing so compelling. Users should have enough instruction to be able to control their experience in the prototype, but after they receive that instruction, we should completely step back. Sure, we should be asking clarifying questions about the user’s intent and get more context about the actions they are making, but at this point they should be flying relatively blind.
Keep Them on Track
It’s important to understand your user’s perception of the testing. Depending on how good your client managers and customer service reps are, this could be seen as a unique opportunity for your users to give their not-so-helpful product feedback straight to the source.
From the get-go, establish that this is not a sales call. The value that they are gaining from this interaction is the opportunity to have a direct and significant impact on product development.
Don’t let them air grievances and suggest features. That type of feedback will get you nowhere, and it will take up lots of precious time.
If you find your user is diving down the complaint and feature request rabbit hole, don’t be afraid to take control of the conversation. Let them know that their feedback is valuable, and they should send it in an email after the meeting, but for now, the time is limited and their feedback on this specific workflow is invaluable.
Putting It Together
Personally, I struggle with taking written platitudes, like those written above, and applying them to specific scenarios I find myself in. Theory often differs greatly from execution — so what does this look like when it’s all put together?
Let’s say you are designing for a social media application and are introducing a new event and calendaring feature.
What we don’t want to do is mock up the event page and throw a user into it to get their thoughts. With zero context and zero motivation, the value of the data we collect will also be just that — zero.
Instead, let’s give the user a task to accomplish. It’s as easy as saying to them, “You’re throwing your friend a surprise birthday party and want to use an event to coordinate everything. Use this UI to send out invites, get information to guests, and maintain a guest list.”
As the user makes their way through our mocks/prototype, this is where we have to throw the chick out of the nest and see if they fly. If we have to intervene at all to get the event set up, we know there is work yet to be done before the experience is ready.
If the user decides to try to hijack the conversation, this is when it is most important to keep them on track. While their grand idea for a marketplace for our social media platform is interesting enough, now is not the time. So we tell them how interesting that idea is and how we’ll take a note to chat about it later. For now, we will focus on accomplishing the task at hand.
This all seems like subtle changes we can make to our prototype testing, but from our experience here at Adobe, we saw an incredible upswing in collecting useful data by making these small changes. Users can be our greatest asset to good product design, but it is our responsibility to effectively mine that information from them.
Post Script
It should go with out saying at this point, but during this prototype testing process it is vital that you have representation from Product Management and Engineering in on the meeting. They will ask questions and gather insights that are out of your scope of knowledge, and that will have a meaningful impact on the final product design.
If you do a user test in a forest and there is no one there to hear it (other than the designer), does the user actually make a sound?
No. No they don’t.
