Learning about PRDs as a UI/UX designer
My mentor is a Product Manager, who often wears many hats in the development of a product. PRDs stand for Product Requirements Document, a regular asset that he creates to help his team focus on the big goals for the project. He recommended I explore the creation of one as I embark on a new project where I attempt to improve the process of creating a strong resume via a resume builder feature.
The document comes after initial prototyping and research, and it is what every person involved in the product defers to. It defines the problems the product is fixing. It’s updated regularly, weekly or sometimes daily, it iterates along with the team’s progress. It has 4 main sections, What’s the product for? What features does it have? When is it “good enough” to release, and a loose timeline. It does not focus on solutions, that is what your team’s job is.
The PRD explain why changes were made, it’s what everyone can look back on and they will know why something was done, they won’t explore that avenue conceptually and will save your team time and frustration.
Purpose talks about why people will use the product, what needs is the product meeting? Are those needs not being met at all or being handled poorly? Why is it important?
When talking about features in the PRD, they need to be directly connected to the purpose of the product, how does this feature directly support the main goal of the product? It helps you rank the importance of each feature.
Release criteria goals should be simple, clear on when they are met, things that are possible and not idealized, and something you can measure. KPIs
There are templates you can use (easily found via Google). My mentor uses Google Slides to create a deck that is highly visual. Visuals help understanding in a way text cannot convey and much faster.
Lastly, make sure everyone reviews and understands it. In my experience this can be the hardest part is making sure your team reviewed documents you’ve made. Daily stand ups with a time limit could be useful when sharing, I find generalized meetings tangent off way too easily.
Since my current project is solo I think creating a PRD for me would look more like an evolving case study where I save each iteration and develop my slides. Too often I jump into a project and create a case study later. By integrating the PRD concepts I can have my high level goals and then the nitty gritty solutions, the before and after side by side.
sources:
How to Write a Painless Product Requirements Document
How to Write a PRD — With Examples
and my mentor
Main Image byManfred StegerfromPixabay