Every new product design seems perfect, while it’s still in the head of it’s author. Everything is clear, consistent and evident.
Even the stage of composing sponsor pitches and marketing content — dedicated to describing the overall idea and why it is good — does not help much to think about the downsides and possible bottlenecks.
Without investing much resources into development and testing you can discover the majority of corner cases and difficult questions by simply writing texts and scripts for the support team or site pages.
Doing this, you’ll have to other way but to think through every single step of the user scenarios, describe every single interface element and what it does, come up with solutions for every possible problem a user might encounter.
Well, alright, that depends on your imagination — whether you’ll find the most intricate ways to break the standard scenario. But at least you’ll start breaking the idea into detailed descriptions and facing possible obstacles.
A useful trick here will be the question ‘What if I can’t do that?’. Take your standard persona and user scenario and describe the ideal session with your app, service or site. Make your description detailed enough, down to the actions like ‘I click the app icon on my iPhone home screen’ or ‘I log in’ or ‘I fill in my card number and CVV’. And for every step of this description ask yourself two questions:
- how did I get here? This question is relevant to all entry points for you to remember about app distribution, installation processes etc
- what if I can’t do that? What if I can’t log in? Is the signup/signin process simple enough? What if I can’t fill in my card number because I don’t have it with me? What if I can’t proceed with hailing a taxi because my GPS is faulty and the service can’t determine my position? What if I can’t send the confirmation code because my network is suddenly down?
You really don’t have to answer all these questions right there in the support docs (although you maybe should?), but they will help you plan backups, workarounds, discover bottlenecks and potential blockers. Useful stuff, isn’t it? And just this simple.
Top comments (1)
I want to tag team this from a developer stand-point. All of these documents you're referring to help define boundary conditions.
And can help developers see potential pathways to resolve the issue; sometimes creating novel solutions.
I know for myself in implementing things, the best and most powerful thing I can do is to state in my own words what done looks like. And what you're advocating for is the compliment to that action.
Put another way, product should ensure we're doing the right thing, and engineering should ensure it's being done the right way; but both have a valuable voice in the other's responsibility.