PRDs (Product Requirement Documents) and MRDs (Marketing Requirement Documents) come in many flavors. My question today is, “What kind of requirements doc is the most conducive to creating great UX and great products?”
Let’s assume for a minute that you have a Product Manager that knows their stuff backwards and forwards. The goal is to get that knowledge and wisdom into a format that can be easily consumed by engineers, project managers, designers, executives and potential customers. This will make sure we are all on the same page and build something great.
Other goals should include speed and agility. By this I mean that the process can be quick with minimal friction and also leave room for new learning and creativity to make the outcome as high quality as possible. In reality, no one knows everything up front. We learn as we progress.
I think I can say, without reservation, that a 100,000 words in a Word Doc is the worst possible method. It’s worse than nothing at all. Who can read those things? I have tried to read those rambling docs before and nearly set myself on fire to escape the agony.
One way I have seen that works well is to create user stories. The key word here is story. Stories are easier to remember and to wrap your heads around. A story is meant to exercise the system in a way that lends itself to lots of scenarios. Example:
A marketer wants to wait until a form is filled out and then respond instantly to the prospect with an email. A few weeks later, the marketer wants to follow-up with another email. They think a third email is a good idea, only if they have expressed some interest by visiting the website more than once in that time period.
This is an actual story I used years ago for Marketo. It obviously does not describe all the things a Marketer could do, but it lays the groundwork of what they are trying to achieve and the kinds of information they need to feed the system.
The next step for a great UX is to create visual representations of these user stories. I have been using PowerPoint to storyboard these visual requirements docs. I use bubbles to call out specific logic and animation to show how the user would go about doing this task. I am interpreting the user stories and describing a beautiful/fun/easy/organized way of achieving the goal. The visual docs are very easy to consume by the engineering team. They know what the end result is going to be. It’s also easy to iterate collaboratively with the executive and product teams.
I don’t think this is a “one size fits all” solution. The important takeaway is that long text documents rarely are as clear and consumable as we would hope. I think Visual Docs are the way to go. If you have super long text docs, you should ask the key questions:
- Who are these docs for?
- Are they reading them?
- Do they understand them in spirit and in detail?
- Could this have been done quicker?
Always challenge the status quo. Without that, there is no chance for improvement.