Product Dissections: a tool for product managers to become better at UX
Product managers indeed work at the intersection of business, technology, and user experience. Lisa Jewell mentioned in her article that UX is one of the most critical function of a PM’s job. Still most of the people who are starting their careers as product managers are MBA graduates with no experience in UX and design unless they come from a design background or have pursued a specialized program/certification in product management.
And hence, the first challenge is most of the product managers learn UX design while they are on the job and it takes time to build credibility before the team can trust their opinion and decisions around product experience. This becomes an even bigger challenge when the product is relatively new to the market and there are not enough users to A/B test different experiences with and gather quantitative information on which experience is performing better.
The second challenge is, most of the smaller teams operate without a dedicated user research and experience team, in which case the onus is on the PM to deliver a great user experience. So even though the PM might have the required design background and expertise, it is equally important to empower the engineers who are building the user-facing experiences (web and mobile mostly) with UX skills so that the PM does not become the bottleneck for making small and trivial decisions around product experience by those engineers.
In this blog post, I am going to discuss how you as a product manager and engineers building user-facing experience (I am going to call them ‘frontend engineers’ in the rest of the post) can get better with UX and design through product dissections.
Product dissection is a group activity where you along with your frontend engineers review the user experience of an established product from the lens of a user experience designer.
During this activity you try to question and deeply understand why the experience of that product is built in a certain way, you try to understand the thought process of the UX designer for that product and draw inspiration for your product. The most important aspect of this activity is to record your observations and learnings in a structured way for future reference.
How to conduct an effective Product Dissection?
First, plan a fixed schedule for your product dissection meetings. You might want to conduct this on a bi-weekly or a monthly basis. This activity needs at least 1 hour of time commitment. Send the invitation to your whole frontend engineering team. If there are more than 10 people, you might want to break it down into smaller groups.
Second, ask someone to volunteer to choose a product they admire based on the theme that you will decide. For example, choose Slack if you want to understand what a great on-boarding experience looks like, choose Netflix for subscription management, choose Github for access control and management, choose Airbnb or Dropbox for sleek animations and transitions. Once the product is chosen, the person who chose the product will lead the product dissection activity and needs to be prepared with the complete product flow that he will take the whole team through.
Third, assign different roles to people in the room before starting the activity on the designated day. The person who is navigating through the product will be responsible for taking screenshots and recording the screen. One person should be assigned to take notes and record observations from people across the room. Out of the remaining people, assign half of the people to speak in favor of the product being reviewed and remaining half should play the devil’s advocate. Your role as a PM would be to facilitate a productive discussion and learn from the observations.
Fourth, once the activity begins, the product navigator will behave like an actual user and start using the product. People who are speaking in favor of the product will closely observe the flow and take notes to answer the following questions:
- What parts did they like in the whole flow? What was the ‘Aha’ moment for them?
- What parts they think that could have been implemented differently? and why?
- Step inside the shoes of that product’s UX designer and think about why they implemented a flow in a certain way.
- Which interactions were expected and which were unexpected?
- Did the product communicate with user appropriately to help user take the next logical step? Was there a point when the user felt lost?
Once the product flow is complete, each member will speak for about 5 minutes to discuss their thoughts. Based on these responses, people who are playing the devil’s advocate will try to think differently to bring a completely new perspective to the table. This will initiate a discussion within the team members to better understand the thought process behind the user experience. Note taker will record all the key points from the discussion and product navigator will take screenshots of the highlighted parts of the flow which were mentioned during the discussion.
Finally, organize all the notes, screenshots and videos on a cloud drive in a separate folder titled by the name of the product. This can be used for future reference by your team and new members who join the team at a later point in time.
If this activity is conducted regularly it has multiple benefits —
- You are building the required UX expertise within your whole team in a 3–4 month time duration
- You understand the best UX practices across the software industry
- You understand which UX ideas suit your product and which ideas do not
- You and your team will understand your competitors better, if you choose to do this activity for your competitor products
- Internal UX related discussions within the team will be backed by solid examples and data which will improve the decision making process around product experience
Have any thoughts, comments or feedback? Feel free to share it below :)
