This post is another behind the scenes look at a live design review with the Basecamp team.
This type of meeting occurs across thousands of tech companies every day. Members from Product, Design, and Engineering will review a new feature, discuss use cases, consider tradeoffs, make decisions, and establish a plan for how and when to release the feature to users.
As a Product Manager, this video is useful in showing tactics for how to run a productive design review, questions to ask, and how to present alternative ideas.
My notes from the video:
Asking questions is a critical skill for successful product management. The types of questions you ask and how you ask them can be the difference between an unproductive and productive meeting.
- Have you explored, do you want to explore…?
- Why did we make this decision?
- Inquire with the Engineering team, is this change a days worth of work or is it more significant?
- Context: if considering multiple paths for a new feature, but one path requires significant Engineering changes, that path may then be avoided if the cost is not worth the benefit to the user.
- Should the copy reflect the end goal of this feature?
- Context: when discussing what a label/button text should say, consider what action will occur when the user interacts with this element, does the copy provide clear indication of that? In this case were discussing “Create a stack” vs “Stack these projects”.
- Another example: “Empty stack” button vs “Remove all projects from stack” the latter is clearer as to what exactly will happen.
The empathy case. When evaluating multiple options for how a feature should work, have the team visualize a typical user scenario. What is the user doing? Why are they doing it? What is the context? This visualization may help with guiding the team to picking an option.
The edge case. Consider the edge cases that may occur. In the video the Basecamp team discuss a button that doesn’t have an “Are you sure…” type of pop-up after the button is clicked. For a user that mistakenly clicks the button, this could be a frustrating experience. And even though it may be an edge case, it’s worth discussing and deciding on if a fix should be built or not.
Desktop vs Mobile
For a company that has both a Desktop and Mobile version, a constant question is do you release a new feature on one platform and wait for the other platform to catch up?
In this case here is what the team discussed:
- Mobile is about 2-3 weeks behind Desktop on this feature
- Typically we ship on Desktop and are fine with waiting for Mobile to catch up, but in this case maybe we should wait. Consider the scenario for the user: this feature is on the home screen, mobile screens are smaller, a disconnect between two platforms could cause some UX frustrations.
- Go with a “soft launch”. Ship it on Desktop, don’t make a Marketing announcement. For insiders publish a note regarding that mobile is a few weeks away for this feature. Let rest of users “discover” the feature on their own. Make Marketing announcement after Mobile ships.