uxdesign.cc
Defining what good design actually lookslike.This article is a lightly edited note I wrote for my team of product designers atDialpad.Good design can be tricky. Whats obvious to one person might not make sense to someone else. Design might feel subjective, but there are things I (and the rest of design leadership) consistently look for when reviewing designs.Good design is the result of early and good collaboration. Early designs usually wont check every box, but we can anticipate some stuff and avoid spending too much time on designs that dont quiteland.This document attempts to define what good actually means for design at Dialpad. It gives us a shared target so that when we get to leadership reviews, weve anticipated much of their feedback and they trust that the direction isgood.Have a NarrativeIts important to start with why were doing a project in the first place. Is it a metric were trying to improve? Is it an unmet user need were solving for? A sale were trying to close? Before I look at any screens, I need to understand why were doing something in the first place. It helps us all stick to first principles when reviewing designs.You know how we say that storytelling is important? This is what wemean.Only after I have this context can I give you feedback thats actually helpful and not just skin-deep increase the spacing here type feedback.You dont always need a slide deck, 12 paragraphs or a 30 second spiel is usually good enough. I dont appreciate being dropped in the middle of a Figma file with no notes, nor do I appreciate being linked to a large Jira epic or 15-page PRD just to know what a projectis.Design leadership covers a lot of ground and Im relying on you to tell me what a project is and why itmatters.Be strategic about what you share and what feedback youre after. You shouldnt show and explain everything in the design file. To this end, its helpful to organize your thoughts and Figma file ahead of time. Its incredibly hard to follow someone rambling while zipping around a Figma artboard over screenshare. You likely wont get the feedback youre looking for thisway.Your OwnIdeasOften a PM or engineer will introduce a project with a solution already in mind. Itll be included in the Jira ticket, described in a PRD, or mentioned in a meeting. And thats great. We should definitely explore and draw out other peoples ideas. But I want to see you thinking of your own ideastoo.Figuring out what to do is a big part of senior designroles.I want to see that youre not just executing someone elses ideas. I want to see that youve explored an idea from at least two or three different angles (read: not the same idea with two or three minor variations).Coming up with different ways to solve a problem shows that youre not just doing what youre told, but really using your own judgment. Thats what makes someone great in a senior role. Dont be afraid to ask questions and suggest bold ideas. The way you come up with and improve ideas is just as important as making themhappen.Consistency vs. InnovationDialpad has been around for a while, which means weve built up a lot of design patterns that are quick and easy to use. But lets not settle for quick and easy if theres room for improvement. Sometimes a new approach could make thingsbetter.When reviewing designs, I ask myself the following questions about consistency and innovation:Are we proposing a new solution to an old problem? Is there a goodreason?Do we have examples across the product that do something similar, while noting the pros andcons?Does the design use patterns customers are used to, or would it be something new theyd have tolearn?If there is an existing pattern that accomplishes a task, I want to see it. At the same time if you think a new pattern is warranted, I want to see that too. Bonus points if you have a reasoned preference towards one or theother.While fixing inconsistencies is important, we should also think about the users context. Sometimes its important to push for a better experience even if it means more work. Other times its better to stick with what we have for the sake of consistency and speed. Having multiple designs drawn out helps facilitate this discussion.Masking ComplexityDialpad is an incredibly complex product that contains a lot of technical workflows and generates a ton ofdata.Our customers shouldnt have to knowthat.Our aim should be to make communication instantly and easily understood, like a web browser does for connecting to and displaying websites.When reviewing designs, I ask myself the following questions about scaling afeature:Is the information presented in a screen easy to understand at a glance? Can the user go deeper if theywant?Does it involve too many clicks? Are we asking users to do things we could automate?How might a new user perceive this feature? What about a poweruser?Do we need to build something new? Or can we change something we alreadyhave?The design should be easily understood but robust enough to handle complexity andscale.UX CopyRemember design is mostly words. I want to see you hold UX copy to the same standard as user flows, rectangles, andcolor.When reviewing designs, I ask myself the following questions about UXcopy:Can there be less words? Whether its a blog post or a single form field, my first reaction when writing anything is to removewords.Is the language clear? Can we simplify or remove technical jargon, acronyms, and internalspeak?Is the language consistent? Will I understand this based on what I already know about Dialpad? Are we using verbs consistently? What about date and time formats? Even things like capitalization are important.We have copy guidelines and a ChatGPT bot trained in Dialpads voice and tone. Usethem!When writing copy, I usually put something like this intoChatGPT:Rewrite the following sentence 10 times. Keep it short, 10-15 words max.Use simple language and the rules you know for our UX copy."A poorly written sentence that gets my idea across."Usually the best copy is a combination of these examples. I used this technique when writing thisarticle.How Does ItFeel?When reviewing workflows, a prototype is worth a thousand static screens. I love seeing prototypes early, like even at the wireframe stage. It helps me preview what it would feel like to actually use thedesign.When reviewing prototypes, I ask myself the following questions:How discoverable is a feature? If I was new to the product, would I understand where to go and what todo?How does it feel? Is it a lot of clicks? How are the transitions betweensteps?How does it make me feel compared to other apps I use? How would I feel if I had to use this design every day? Everyweek?Its not always practical to prototype in code, so things like Figma prototypes offer the next best thing to how a design would actually feel in the product. From new user onboarding through to task completion, an interactive prototype gives me a decent idea of what the user journey would feel like from start tofinish.How Could ThisFail?Most design reviews focus on selling an idea, convincing the audience why a design is good. But thats only part of the equation. I want to know about the downsides too. We should be our own worstcritic.What are the pros and the cons of each design direction. How could a design fail? When reviewing a design, Ill be looking for reasons why it wont work or how it could be abused or exploited, so it helps if youve thought about this too. Thinking about this ahead of time helps facilitate the discussion amongst theteam.While not an exhaustive list of things that will make design good, thinking about these things ahead of time helps focus the discussion with leadership around around deep, meatytopics.When we embrace different definitions of good, lean on clear frameworks, and create a supportive space for critique, we can deliver design work that hits both creative and businessgoals.Subscribe to my newsletter to get more bit-sized thoughts on product design and leadership.How I review design work was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.