How to Build Products More Collaboratively Flashcards
What is one way to get feedback from your teammates early in the design process?
Share works in progress.
Different people on the team know different things. They have different requirements and needs and concerns.
For example, customer service folks know things about customers that engineers do not. Engineers know things about what’s hard to build that the product manager does not. Marketing and sales know things about how to sell the product that I guarantee you do not. The legal department knows what’s required by law and how to keep us all out of jail. And product managers should have data and metrics about how features are performing
What happens when we don’t actively seek input from team members throughout the design process?
We can end up designing things that never ship or that don’t meet user or company needs when they do ship.
As a designer in an agile team, how will you decide which suggestions to work on?
Probe further into each suggestion to identify why they are giving those suggestions and then design to resolve the underlying issues.
When designing the users’ experience, you will need inputs from different stakeholders and functions in the organization. These inputs can come in different forms—data, problems with the current design, ad-hoc solutions, and opinions. To identify which ones to pursue, understand the motivation behind the suggestion, and why they want to add, remove or change things in the product and take the next steps accordingly. You do not have to incorporate every suggestion, and you may need to refine the suggestions that you chose to incorporate. The key is to listen, probe, evaluate and then proceed, instead of filtering out suggestions based on a formula.
What are the potential pitfalls of sharing works in progress on product development?
a. The design process becomes longer due to multiple iterations.
b. The engineering team may waste time by working on half-baked ideas.
c. We undermine confidence in the discipline of design and harm other designers.
The engineering team may waste time by working on half-baked ideas.
There is a legitimate concern that sharing works in progress can derail product development. If engineers begin work on an idea, and the designers realize that they need to change direction, then the engineers will have wasted time in development. To avoid this, we need to make it clear when works in progress aren’t ready to be implemented.
What is an appropriate time to share works in progress?
Share works in progress when you need feedback and input from team members.
There are no hard and fast rules or timeline about when you should share works in progress. In general, the earlier you share, the better. If your designs aren’t technically feasible, you will save your time and effort. Ideally, we share works in progress when doing so will serve a purpose, like getting us feedback from other people on the team.
In what way can an Initiative Document help agile teams manage risk?
By defining the success criteria and outcomes for the project.
When teams define the success criteria for the product or feature that they are working on, they will know if what they are working on is worth the time, effort and money. This can help teams stop work, or even kill a product that does not meet the success criteria, and in turn, not waste resources on things that do not deliver value for the team, the organization or the users.
Why do we create designs, task flows, and storyboards?
So we can think through complicated problems and solutions and share them with team members for feedback
If you wanted to get feedback on the technical feasibility of an idea, what deliverable would help you get that information from the engineers?
An annotated diagram
When you want to assess if an idea is feasible, ideally, you’d want to ask the engineers before you put too much effort into designing it. If the idea is not feasible, you can change course and work on alternative solutions. For this purpose, an annotated diagram will be the most efficient deliverable.
The customer support team has reported that a few users have encountered a problem. As a designer, you realize that it is a known edge case, and the problem can be addressed through a message on the screen in a style that has already been specified. How will you communicate the solution?
Since the problem is a known edge case, and the solution involves a message on the screen in a common style that doesn’t require any visual design work, you can simply share the copy with the engineers to add on the screen and explain where and when to display it. This doesn’t require a pixel-perfect mockup or even a wireframe unless you want to display it in some unusual way.
One of your clients has an idea about how a product feature should be implemented and is fairly convinced that it is the right way to proceed. However, you are concerned that users will not be able to understand it. What will you do?
Run a small usability test with a low-fidelity and high-interactivity prototype to see if it’s confusing for participants.
Just because no one else has tried it before, doesn’t always mean it is a bad idea. However, if you are concerned that it is indeed a terrible idea, but face resistance from your client, you can easily confirm whether it’s confusing or unusable for users with a standard usability test.
What do we mean by participatory design?
Collaborate with customers to generate ideas.
Unlike user research (in which we understand the problems), participatory design involves people in the solution space. Customers will not always know what they want or how they can solve the problems that they face. However, they can provide insights into how they think, and which solutions will work better for them.
Why do teams end up making unrealistic roadmaps?
Parkinson’s Law: Work expands to fill the time given to it.
Scope always creeps
What’s the outcome of unrealistic roadmaps?
Tech debt. Fast-forward two years from now, your project has this tech debt-riddled code base and all the original developers have left. It can end up in really expensive refactors every couple of years.
How can we coordinate with different stakeholders who depend on timelines?
Marketing is a particular type of stakeholder who often wants to know when things are going to be out so that they can line up their own work to go with it.
