Back To CourseUser Experience Design Training
6 chapters | 63 lessons
As a member, you'll also get unlimited access to over 70,000 lessons in math, English, science, history, and more. Plus, get practice tests, quizzes, and personalized coaching to help you succeed.Free 5-day trial
Temitayo has 11+ years Industrial Experience in Information Technology and has a master's degree in Computer Science.
A product specification document (PSD) helps to capture all the expected specifications and requirements for a product that's being conceptualized. This enables both the design team and potential product users to understand more about the product before it's actually built and readied for distribution or end-use.
The PSD is often confused with a product requirement document (PRD). However, while their contents are similar, the PRD has a more technical inclination.
For example, where a PSD would list the requirements for a user login page and the standard security requirements, a PRD version would describe those standard security requirements in-depth.
Let's look at an example of how to effectively write a product specification document.
William works as a product manager for a payment service provider. He's saddled with creating a PSD for a product in the early conception stage. With the product in mind, William first researches potential and existing users and competitors of the product, as well as the capability of the in-house technology team to develop and maintain this product using a product build approach. In other words, he checks to see if the product's development needs to be outsourced. He also reads positive and negative reviews of similar products currently on the market and examines the potential composition of the product team.
Next, William needs to define what the product is meant to do or the problem it will solve and how it will help customers or users achieve their desired goal in using the product. This step is very important since it's only through a clear understanding of the product's purpose that management and other team members will support the idea. He needs management approval for this product to be created and development to continue.
Once the product's purpose is clarified, William moves on to defining how the product will utilize user profiles, and help users achieve their goals and complete desired tasks. Every user of a product has particular needs or goals that they're looking to meet through the use of the product. For our payment service provider example, there are some users who feel having to create an account profile on eCommerce platforms is not necessary. They want to log on as a guest and conclude their transactions semi-anonymously. Others want to have an account profile but require less burden involved in the process. All of these users' needs have to be accommodated in a product if it is to succeed.
On the other hand, the product itself might have a goal that can be achieved by requesting users to have an account profile; for example, taking care of issues resulting from transactions. The product manager needs to examine both needs and see if this can be achieved without compromising the end product's quality.
William needs to ensure that goal-related tasks are well designed around the expected user's profile. For example, he needs to ask, 'What task can a logged on or a guest user perform on the product, and how will it affect the overall product's aim and objective?'
William needs a well-defined product principle to help drive his passion for the success of the product and its quick adoption for use by target users.
The product principles are sets of strategies, values, and goals that represent the overall direction a product is heading in line with the expected user's profile. Product principles are a value and vision that must also be bought and driven by the product team.
An example of this is when a user who wants to make a transaction on an eCommerce site without creating a user account or profile, still expects that transaction to be safely carried out. This user expects his or her transaction to be simple, straightforward, and secured.
Going with these expectations, a suitable product principle would be 'Safe and Simple to Use', among other catchy phrases aimed at assuring the users of its readiness to support their expectations.
At this stage, based on the initial product information that he's been able to come up with and working together with other members of the product team, William creates a prototype, or preliminary model of the product, and subjects it to various types of testing, including the following:
Based on the results gathered during prototyping and product concept testing, William identified and drew up a list of assumptions that needed to be questioned in order to help him and his team more closely understand the product as well as compare initial specifications to the actual situation.
Next, William wrote down all he had gathered so far about the product along these lines:
He now has a living document which can be updated with more details as the need arises.
William senses that too many features could be a problem in the product. He knows the best option would be to prioritize the features according to the exigency of needs. He might not have to discard all those not prioritized but rather reschedule them for implementation under future releases or whenever it becomes feasible to do so.
Having many features on a product sometimes is a plus when compared with competing products in the same category but not always an assurance that those features, if implemented, would have an edge. Rather, an abundance of features most often results in product release delays or coming in over budget.
After putting together the draft version of the PSD, the document should be reviewed by other team members to see if they can understand it and provide further input. While compiling the PSD, William tried as much as possible to leave out specifications involving user interface, quality assurance, and user experience design so product team members specializing in those areas could review the PSD and provide their input.
It's only through a review of the draft document that the team will be able to confirm the document meets all of the team's requirements for completeness. Once this is confirmed and after approval by management, the document is ready to go live.
With the PSD approved and product implementation in process, William still has to monitor that the product is being developed along the lines defined in the PSD. He is the product owner who knows all of the necessary components that the product needs to have at completion, which means he needs to be consulted throughout the process.
During consultations, William will need to refer to the PSD and, where necessary, update it with changes to match the present needs. All of these changes will tracked by versioning the document. This William does by creating a revision table where changes carried out are noted and dated on the document. With this, he can conveniently roll back to any document version if need be.
A product specification document is a document that contains specifications and requirement information about a product to be built or implemented. It's used by the members of the product team to come up with a final product. A PSD remains a living document that can be updated as the product's requirements change in order to increase the product's marketability.
To unlock this lesson you must be a Study.com Member.
Create your account
Did you know… We have over 95 college courses that prepare you to earn credit by exam that is accepted by over 2,000 colleges and universities. You can test out of the first two years of college and save thousands off your degree. Anyone can earn credit-by-exam regardless of age or education level.
To learn more, visit our Earning Credit Page
Not sure what college you want to attend yet? Study.com has thousands of articles about every imaginable degree, area of study and career path that can help you find the school that's right for you.
Back To CourseUser Experience Design Training
6 chapters | 63 lessons
Next LessonSoftware Design Document: Templates & Examples