What's a PRD anyway?
After publishing this post originally, we got requests to clarify the term 'PRD'. A PRD is a Product Requirements Document. This is a document that product development teams use to specify what they will build. It will contain features, user stories, business goals, and whatnot. It's usually drawn up by another team that bases the information in the document on research and the company's business goals. We also learned a lot about how other folks view PRDs (see below).
Every product begins with an idea. A lot of things can inspire ideas, but there's always a hint of assumption in every idea. It's a little arrogant, but product teams assume a lot of things at the initial discovery stage of their process ' that they know that a problem exists and, worse yet, that they know how to solve it. That initial spark is necessary to start building up momentum in the design process. But bad things start to happen when teams don't budge from these initial assumptions.
More Like PRDon't, Amirite?
We talked in previous blog posts about the dreaded product requirements document, or PRD. But we were surprised to find that people liked PRDs. Some designers liked the constraint, and developers like the idea that this document could somehow magically prevent feature creep.
Refuse to wireframe without requirements. If they won't give you requirements, then you're not designing, you're wasting your time.
' Dylan Wilbanks (@dylanw) July 3, 2014
PRD's aren't bad per se. They're good starting points, and often-times they're the result of user research, which can be great for validating early concepts. The problem is teams constantly fall back on the PRD and fail to create new sparks. Why bother opening up the problem when someone else has already done the thinking?
Docs are Out, Prototypes are In
Documents become less relevant as the team moves forward with the product. A successful team will prototype early and replace their abstract documents with clear and tangible customer feedback.
A prototype is a rudimentary version of a product. This really broad term can mean anything from early sketch prototypes to more fleshed-out coded prototypes. Prototyping helps your team quickly find problems before investing resources and time in stupid problems.
We're working on the next big update to Notableand our apps. Part of this effort has been reaching out to customers for their feedback. We recently had a chat with Marieke McCloskey, User Experience Specialist at Nielsen Norman Group, about Concept and Prototype testing with Verify and Solidify. It was really cool to get insight into NNG's prototyping culture. Here's what Marieke had to say:
Whenever we work with a client in the early stages of the design we recommend testing prototypes. Usually we'll start with a combination of a computer wireframe and paper sketch and then move on to higher-fidelity prototypes. It's incredibly satisfying when our clients see how they're avoiding some big usability issues in their final product by testing early and having enough time to improve the design.
' Marieke McCloskey, Nielsen Norman Group
Prevent Trouble Sooner
Product teams are often afraid of running with new ideas because they're afraid for being wrong. There's nothing wrong with being wrong. Realizing you're wrong after you've wasted a lot of resources is a problem.
At ZURB we validate our concepts early to reduce our risk. Product design is a bit of a gamble, and the more we invest in a product, the higher the stakes.
Everything is a Prototype
We can also make prototypes with code. In that format they have different benefits. A coded prototype will help designers refine interactions and find edge cases that cause bugs. We're currently doing this kind of prototype testing with Tavern, a design community site where we give people 24 hours to answer a daily question.
The spark for this came from the everyday design design discussions that happen at ZURB. We released the site internally first, and since that first day, the team's been chiming in with feedback and bugs. We've since released it to a private list of customers and fans, to whom we're talking on a daily basis, soliciting their feedback on the functionality and the content. Tavern, though it's currently highly functional, is simply a super high-fidelity coded prototype.
Getting Started With Prototypes
Break It Down
Breaking the problem into smaller pieces is the best way to prototype. For example, if you're working on an ecommerce site, you probably don't want to prototype the whole thing at once ' instead you'll break it down into separate flows such as the checkout flows.
Know Your Fidelity
Develop a prototyping palette. The sooner you start prototyping, the sooner you will have this palette ready in the future, so you need to start practicing prototyping now!
Each stage of the product requires a different time investment and a different type of prototype. Here's what you can do to effectively prototype at each stage of your product:
- An idea: If your product is still an idea in your head, sketch it out! At this stage, you'll want to put away your computer and devices and get back to basics: a sharpie and paper. You want quick feedback and validation on high-level concepts, so don't spend too much time on minute details. Get those sketches in front of friends and potential customers using a tool like Verify that will help you get that quick high-level feedback.
- Lots and lots of documentation: You have lots of documents, a PRD, and all kinds of other acronyms flying at you. Your next course of action would be to start fleshing out detailed flows with high-fidelity wireframes. The keyword there is 'flows,' so you should string together your wireframes using a tool like Solidify, so you can find those unforeseen gaps in your user flow. If you're looking for even more detailed feedback on interactions, you can't go wrong with a coded prototype. This doesn't necessarily have to be production-ready code, but it needs to demonstrate the functionality you want to get feedback on.
- Live site: If you already have a live iteration of your site or app, that's great! You have real customers using it and you probably get some support emails, with questions, feedback, and bug reports. Start using that to fuel your next iteration. Depending on the complexity of the feature you want to iterate on, you could either sketch, wireframe, or code up a prototype. The advantage of coded prototypes is that you already have the infrastructure setup, so you can push out changes and get feedback quickly.
Do It Fast
Don't spend too much time. Prototypes are meant to be quick. Forget pixel-perfection in a prototype ' unless you're looking for feedback on the visual design as well. Minimize risk by investing just enough time in your prototypes. This means a sketched prototype shouldn't take more than a couple of hours, while more involved coded or hi-fi prototypes could take a few days.
Get Feedback
Don't forget the feedback. Prototypes are a tool by which you can get feedback. This feedback will help you figure out if your concepts are valid, if your flows make sense, and if your interactions are intuitive.
Iterate. Iterate Some More. Are You Iterating Yet?
Don't stop there! We're just getting started here! You got some valuable feedback from customers, now it's time to start over. Was the feedback positive? Great! Build on that, and start fleshing out the concepts and flows with more detail. Feedback not so good? Make your changes, then get back to your customers. By soliciting feedback from customers, you've started involving them in your design process, and that's great! Keep that relationship going by following through on feedback and going back with the changes you've made.
Update: Someone Finally Says It!
So here we thought we might ruffle some feathers by denouncing PRDs, but it seems like we touched on some real pain points. Our post triggered a heated discussion on Linkedin, with a lot of great input from product managers.
Why have I waited 10 years for people to realise this? Alleluia:) It is hard for them to be hand in hand when PRICE! rather than VALUE drive product design. Designed obsolecence has gone from deliberate and planned to an accidental result of process shortcuts!
' Chris Hill, Director at Solve 3D Ltd
We also got some different perspectives on PRDs and prototypes. Some folks liked to use them as a starting point and treat them as a living document throughout the product design process, using prototype testing results to inform the documentation in the PRD.
Another way to look at a PRD is a) as something that changes along with the series of iterations (which I believe the article's sketches diagram alludes to already) and b) not so much a document with specific requirements, but a guiding set of principles that the prototypes will embody. That way, as tangible prototypes emerge, you can still look to a unifying set of "truths" about the product. I believe having something acting as a North Star is one of the pillars that can keep a team together as they make decisions when feedback comes in. Not only does it help prevent feature creep, but it also facilitates some potentially difficult decisions about what to change/drop.
' Ariana Koblitz, Product Experience Designer
It's interesting that Ariana mentions feature creep. For her, a PRD can easily prevent too many features whereas we feel that prototyping and reaching out to customers can do the same. So long as the PRD remains a living document, you might not run into trouble. Problems arise when it's treated as a rigid, set-in-stone ruleset. You'll end up checking boxes rather than building what your customers need.
