Prototype Validation Part1
It is always worth to remind what is the goal of each design artefact. Wireframes, mockups, prototypes — they help us to communicate ideas, explore variants or define engineering specifications. But the primary goal is the same — we want to validate our assumptions.
Impossible
In the world of UX Design there is only one validation that counts, and that is observing real users. What seems obvious for simple web-app might get tricky for complex enterprise apps. What fidelity level is worth to test and validate? Does it make sense to invest resources in building a fully interactive prototype?
When user goals can be achieved only with a highly customisable app and complex interaction patterns and data, this step of a design process is often completely skipped. It is considered to be either not effective or not possible.
What is considered to as design validation is, in fact, a presentation — a demo walkthrough of future UI. While there is value in this and lot of useful insights can be gathered from demo sessions, it says very little about how the product will match user goals.
Finding the way
When facing similar "impossible" challenges, I am trying to do at least something. In the worst case, I will end up with imperfect single use case prototype that will be so fragile, that with the first technical issue I will just switch to demo mode. But it is worth the effort because it always pays off.
Some user validation of some product areas is always better than no user validation at all.
Validation Session
At the beginning of each session, I explain the full scenario and terminology. People will see new UI for the first time and to make the session flow seamless, understanding the prototype content is starting point. User interface wording is clearly not part of this validation and from this session, I can not assume whether users will be able to locate the feature without further explanation.
InVision
InVision allows creating simple click-through prototypes by linking individual screens. Even with recent incorporation of overlays, InVision is missing complex states and prototype flow is linear.
That is the reason why I am not only encouraging users to achieve specific goal (e.g. "Let's try to create brand new Package now"). I am also describing this use case in little more detail. Not every UI element is interactive and exploring what works and what not will just eat the session time.
I am sharing InVision LiveShare link and give user presenting control to navigate through the prototype.
The actual validation happens as users are talking through what they see and from related observations. We saw user trying to hit "Save" button too often without additional context or comment. Observing this behaviour leads us to further evaluation, why he feels insecure about the data. Previously we just assumed that big "Save" button will work. Technically it worked, but people had no idea when to use it. This observation leads to significant improvement in next prototype iteration.
Conclusions
There is no better way to validate assumptions than involve real users. They will always run into problems, but it is the context that allows designer and product owner to understand why is that happening.
Prototypes of complex apps are often fragile and imperfect and they require additional explanation — scenario, story, use case or terminology. It is important to always remember, that these aspects are then not part of the validation as they were simply given to the user as initial constraints. One of the possible ways is to complement validation with quick first impression study using Optimal Workshop's Chalkmark.
InVision LiveShare is a great tool for prototype validation sessions. While InVision currently does not have all sophisticated prototyping features, starting and navigating LiveShare sessions could not be easier.
Liked it? Please recommend it, or continue reading with Part2 or Design Toolset.
