No matter how talented the team or exciting the idea, products can fail when teams don’t share a common understanding as to what they are building.
As an experienced digital product designer, I’ve worked with dozens of clients spanning large corporations, startups and government organizations. As an employee at a venture-backed startup, I have been a product design lead and built and managed design teams from the ground up. I’ve seen a lot of product teams over the years, and participated in many product development organizations focused on building and shipping products.
But no matter how talented the team or exciting the idea, products can fail when teams don’t share a common understanding as to what they are building. Encouraging collaboration can lay the groundwork for great teamwork and accelerate results towards a common understanding of the product goals, while helping to reduce risks in product delivery.
In my work on designing products, I’ve seen products fail, due in no part to the passion, talent and enthusiasm of the team. I’ve also seen methods that work well and are reliable. I have tried to capture a few suggestions for best practices in ensuring successful product outcomes in a brief set of recommendations to help product teams work better together.
1. Start by stating the goals so that everyone understands them, and then validate requirements.
At the outset of a design project, be able to clearly articulate the goals — starting from the business case and the problem to be solved. Don’t assume everyone on the team has the same understanding of the business problem being solved, the business goals and the terminology of business metrics. Work to ensure team members from all of the development disciplines understand the business goals and metrics in a language that makes sense to them.
All requirements do not need to be perfectly written and fleshed out in detail but the “why” behind the requirements needs to be well articulated so that team members understand them and can use them as assumptions. Sometimes the assumptions still need to be validated — which is not uncommon. A notion of priority among the requirements is needed: if this is not clear in the requirements, ask for this to be clarified.
Requirements that are too specific can very easily artificially restrict the possible implementation space. Although I do see this commonly in my design practice, I believe it should be a goal to not include solutions in requirements.
As a best practice for enhancing design process, experienced Product Managers with whom I work deliver well-articulated requirements with business rationale and context, and clearly define prioritization. Often they provide the user stories that map to the requirements in their entirety, or else will collaborate with me to define the user stories so that they clearly reflect the requirements, the prioritization and the acceptance criteria. A method that I recommend and see used more frequently as an adjunct to requirements definition is to work backwards and write a hypothetical press release for the product or service, a methodology used by Amazon.
While collaborating on a complex, large-scale enterprise application design project with Deep Ray, Director, Product at VMware (at the time he was the Product Manager on the project) we agreed on the need for the creation of a clear statement of intent and business justification early in the process. We also agreed on the need for stories in clearly written and prioritized format. “Doing this at the outset helps the team understand the business goals and prepare for development, helping to reduce confusion and risk. It helps accelerate the design discussion, which is a front-loaded process” he says.
Senior product executive Joshua Scott also feels that it is critical to provide a clear tether to the originating business metrics and requirements as a core component of software development while also ensuring alignment with market need. “It’s clear that the market needs new processes for software product development that drive business results throughout the entire software supply chain” he says “which at the same time enable traceability back to the originating requirement.”
Spend adequate time understanding the requirements and the priorities with the PM, and ask questions for clarification.
Other PMs write requirements documents that require more analysis and validation to get to the user stories. Spend adequate time understanding the requirements and the priorities with the PM, and ask questions for clarification. To validate requirements, test assumptions and determine if they do not make sense or seem to not fit into the architectural constructs of the planned product platform. Work to understand the requirements, doing the validation and analysis to arrive at a set of user stories that will allow the design team to initiate the design of flows that reflect the feature or the enhancement. This often requires close collaboration with Product Management as the requirements are validated in preparation for design activities.
Define the metrics for success, and how success will be measured. Try to be specific: success metrics such as “Allow an admin to provision a new user in under 3 minutes” and “Enable search on keyword(s) and present results onscreen in less than half a second” are good examples, with specific measurable attributes.
I often find that design teams do not spend enough time understanding and validating the requirements and thinking about prioritization.
I often find that design teams do not spend enough time understanding and validating the requirements and thinking about prioritization. To help with this, the team should hold a review meeting to go through requirements with cross-functional stakeholders and have them explain their distinct points of view about the requirements. Use this meeting as a chance to educate other members of the team so everyone understands the requirements. If there are updates, record this information and share it as part of the project research.
2. Quickly get to artifacts that can be shared and validated.
With a clear set of user stories that accurately reflect requirements, work to get some shareable artifacts — user models (or personas), flows, journey maps, rough sketches and wireframes — that the team can use to confirm and refine their thinking about the feature(s). Remember that wireframes need not be pixel perfect — nor should they be — and they should be used to quickly express and share the flow and intended interaction model for the feature. The goals is to enable discussion and debate among the development team members using an artifact that is understandable by all of the disciplines represented on the development team. Delivering these shareable artifacts early in the development process exposes development to more of the “why” behind the product design, and in turn reduces risk from a lack of understanding of the product intent.
Delivering these shareable artifacts early in the development process exposes development to more of the “why” behind the product design, and in turn reduces risk from a lack of understanding of the product intent.
I use the outset of a project to clearly define and validate the target users — personas — to be served by the delivery of the feature or the product. Even without a shareable artifact (e.g. design sketches) at this stage, try to find target users to interview, get their inputs and feedback on the requirements and assumptions. Study and understand their motivations, pain points and expectations about how the product experience will benefit them. This process of understanding users’ needs helps with validating assumptions and reduces delivery risk. For example, I often see gaps between assumptions about the target users’ technical or analytical skill levels and their true skill levels. You want to close that gap early before starting to design for the wrong target user: not everyone is a techy and can’t be expected to muddle through a confusing experience.
Get the team together to work on rough sketches for the feature or enhancement. Increasingly it’s becoming a standard part of product kickoff meetings to have the team come together and participate in a sketching session — sometimes as part of a Design Sprint. Everyone can sketch, no matter the level of their sketching skills. The idea is to define the major flows of the experience and start elaborating design concepts that might end up as design solutions. Defining and prioritizing flows and sharing them among the team should be a goal at this stage, and they should be in a form that lets the team use the information to learn about and understand the intent and the expression of the requirements.
Design artifacts are an early step in translating requirements into artifacts that are usable by members of the team such as engineering and testing. Once there is a clear understanding of the flows, screen sketching and wireframing can give form to the experience and these can be shared to get feedback from the team. At this early stage I have seen a good outcome by mocking up screens sketches in wireframe form and performing informal user tests with target users. These artifacts also help inform estimating in planning meetings such as sprint grooming.
Cindy Morris, a PM with experience in Agile and Scrum feels that getting early feedback with target users using rough design artifacts works well: “Even though the mockups are in rough form, we can use them to solicit feedback from our customers which helps us reduce the risk of delivering the wrong product”.
In an agile context, I often advise the use of design sprints scheduled one or two sprints ahead of software development to explore design solutions and to test rough concepts with target users, incorporating feedback to adjust designs before they are implemented. To confirm some of our assumptions about users and onboarding task flows, Cindy and I participated in a short design sprint and took a day to spend interviewing enterprise admins for a new enterprise SaaS product, using only wireframe mockups done in Photoshop and Powerpoint. The time invested (less than two days) resulted in a testbed for gathering valuable feedback. We were able to confirm some of our assumptions about the underlying requirements and users’ expectations about a good experience for the new feature, and were able to quickly make adjustments to improve the user experience based on our research.
3. Maintain open communication during development to ensure the team maintains “big picture” visibility.
Maintaining open communication while a feature is undergoing development is critical, so that everyone on the team understands the design intent and has visibility into UX updates as they happen. To share design concepts, I use physical shared surfaces that are in high traffic locations near the engineering team. I usually set up a war room for projects and if available I also set up a Design Wall when designs can be posted in shared areas. (Check for confidentiality first if it’s a publicly accessible area).
Placing a Design Wall in an area easily accessible to product managers and engineers helps them to stay abreast of design changes and gives team members an easy way to post feedback and debate issues that arise during implementation. A meeting held to review the designs on the Design Wall is known as “Walking the Wall”.
With one engineering team, I placed the Design Wall with the entire set of flows and screens for a mobile platform on the wall on the way to the restrooms. All day long, engineers passed by the design wall and would stop to add comments on Post Its, which we collected each day and then incorporated into the design.
If the team is distributed remotely I find ways to seamlessly share design intent and updates with all team members in any location and across time zones. I use cloud based tools such as GoogleDocs, Conceptboard and Invision to share design artifacts with remote teams worldwide. Invision is good for sharing clickable prototypes and design alternatives, showing interaction and flow. Google Slides also works well for wireframing and sharing rapid and fast-changing mockups.
Less like a handoff and more like collaboration
Ensuring that all team members understand the highest level business goals in a language that makes sense to them is the first step in collaborating towards a good product outcome.
It’s important to understand the “why” behind what you are building and be able to ask for clarification for things that are not clear. I remember when I had to ask a PM what “KPI” meant because it was a term used in the business metrics of requirements and at that time it was an acronym with which I was not familiar. I’m always glad to work with PMs that teach me these concepts that I need to understand in order to translate business goals and requirements into shareable design artifacts.
In turn, I commit to give form to the PM’s requirements as quickly as possible to enable the members of the rest of the supply chain team — PM, engineering, design and testing — to clearly understand what needs to be built and how the experience should feel to the end-user. It should also be a goal for design to create the right kinds of design artifacts and assets that increase the productivity of the development team.
Once designs are in process, it’s important to maintain open communication giving teams visibility into design updates as they happen and allow feedback and critique from stakeholders to influence and improve the design.
Using a highly collaborative approach reflected in these recommended best practices sets the stage for a successful product outcome by enabling teams to have a common understanding of the product goals, working closely together to get to a good product launch while helping to reduce risks in product delivery.
AUTHOR
Karen Donoghue is a Principal at HumanLogic.
CREDITS
First photo by rawpixel.com on Unsplash