Product design health checklist

Great design starts with a clear purpose.

Who is your customer, and what pain are they experiencing? What do they wish was happening instead? What will success look like when they get it?

This should be written down and easily accessible by everyone in your company. It should also be specific and detailed enough that people can use it to make tough decisions. A stranger should be able to ask anyone in the company “so what does your company do?” and get the same answer.

Do you immerse yourself in other people’s actual problems before you try to solve them? It’s so important that designers, product managers, and engineers are all in ongoing dialog with the people who use and purchase their work.

These conversations should be about the problems, emotions, and customers “in the world”, not about your ideas. Usability tests don’t count.

These should be something all team members can comment and agree on, and ideally something presented in a meeting with the entire product team so concerns and questions can be raised before more resources are committed. Do you write design briefs and present them to design and engineering teams for approval. This is the design equivalent of an engineering spec. Designers can help write it, but has to be agreed to by all stakeholders before design work begins. One-pager etc.

One common mistake junior designers make is jumping right into the details of a project without considering the high level flow.

If you can’t build and test things quickly, you can’t properly explore all good options before you’re committed to a single direction. This quickly leads to poor usability and a messy, confusing product.

Quality feedback is one of the most common missing aspects of junior design teams. Have you established clear communication channels for soliciting feedback from designers and other people in the company? Is it clear how they should contribute their feedback? Are designers skilled at giving critique, and comfortable in critique sessions? Designers should work with each other and with non-design stakeholders, both live and asynchronously. There should be a safe space with a high volume of constructive feedback. See Feedback 101 for more on giving critique.

Teams often have huge blind spots in how they evaluate “good design”, often focusing too much on one dimension to the detriment of the others. This is especially true of teams whose design function lives primarily within engineering or research teams, who can get overly focused on aspects related to their work.

Good products perform well across the full range of the design hierarchy of needs. Training in heuristic evaluation and using principles of design may help, but hiring trained, experienced designers is best.

Give engineers and other stakeholders a chance to change scope before committing to work. Including PMs, and anyone who can derail a feature before it ships. Most importantly all the engineers who are going to have to build it. Ideally presented in person, taking questions at the end (but not making promises).

Designers Do designers each have responsibility for a part of your product, and are they empowered to make small improvements to that area as issues come up? Do they sit down with engineers to review features and make small adjustments before they ship? Are designers part of sprint planning, demos, and retrospectives? Do they have enough facetime with product managers and engineers to build trust, contribute to product decisions, and help plan upcoming work?

Talking to users at the beginning of a design isn’t enough. To actually know if the design is working, you have to test your creations with real customers. Testing prototypes early in the process is best, but you can mark “yes” as long as you test features before they hit general availability. This acceptance testing is often referred to as “usability testing”, but really should cover all the dimensions of design.

Without measuring, there’s no way to be sure a design is really working. Choose the metrics that matter for you—engagement, funnel analysis, net promoter scores, etc. Make metrics easily available to everyone at the company without them having to ask.

Designers should be able to work quickly in low fidelity, have a high degree of control over visual details, share their work with a link, add comments, and respond to comments left by others. There are a lot of design tools with lots of different features suited to different teams, but these features are the bare minimum in my opinion.

There should be some agreed-on place for designers and engineers to see how the product is supposed to work. Not every miniscule detail has to be defined, but features should at least be captured at the product or business logic level–enough so that a new engineering hire could mostly refactor an existing feature without breaking it.

Designers shouldn’t reinvent the wheel every time they make a new feature, so a design language (or something like one) is crucial to be effective and consistent. Not having software to support this can kill projects before they begin, so engineering is a critical partner for this one. Ideally the same system lives both in design tools (i.e. Sketch, Figma, Invision Studio, Framer, etc.) and real application code (React, Swift, etc.). These two should be kept closely in sync. All components should be responsive and extensible.

Designers are responsible for getting visual details right. Screen resolutions and color rendering are important, so don’t pinch pennies here. Let people choose the computer, display, operating system, keyboard, and mouse that works best for them.

This can be occasionally shared with other teams as long as designers can leave post-its and papers up on a wall without fear they’ll be erased.

Designers can’t be effective unless the entire team know why they’ve been hired and what their job is. This is more than goals, but clear ownership of who’s responsible for each goal. Accountability and leadership is also the biggest way to improve hiring, clearly share levelling etc.

This is a big one. Hiring people without a demonstrated skill is setting your team up for failure. In design, resumes are far less important than portfolios. “The best predictor of future behavior is past behavior” has never been more applicable. This test makes sure designers match the skill level required for the job based on demonstrated ability. Screeners should focus their energy on the quality and depth of portfolios rather than checking boxes on resumes.

If you wait to hire until you find the perfect designer, you’ll never hire anyone. Realistically, great teams are built from people who hit the bar for what you need but develop further on their own. Design is a rapidly changing field, so if you don’t learn and grow, you’ll quickly start to slip.