# Soft Skills for Designers: How Good Work Gets Through the Review Canonical URL: https://headwayskills.com/knowledge/soft-skills-at-work/soft-skills-for-designers/ Markdown URL: https://headwayskills.com/knowledge/soft-skills-at-work/soft-skills-for-designers.md Entity type: Article Last updated: 2026-07-07 Language: en Primary audience: professionals improving communication at work Owner: Headway Skills Contact: https://headwayskills.com/contact/ ## Short answer The soft skills designers need most: explaining design decisions to non-designers, taking critique, sharing work early and making approvals actually stick. ## Key facts - Title: Soft Skills for Designers: How Good Work Gets Through the Review - Category: Soft Skills at Work - Primary skill: Communication - Related skills: Influence, Building Self-Awareness - Primary keyword: soft skills for designers - Source page: https://headwayskills.com/knowledge/soft-skills-at-work/soft-skills-for-designers/ ## What this page covers - The soft skills designers need most: explaining design decisions to non-designers, taking critique, sharing work early and making approvals actually stick. - Practical guidance for soft skills for designers - How this topic connects to Communication ## Detailed explanation Soft skills for designers come down to what happens once your work meets other people: explaining design decisions to non-designers, hearing critique as information rather than a verdict, showing work before it feels finished, steering feedback toward the decision at hand, and following through so approvals survive into production. Every one of them can be learned. It is tempting to believe that good work speaks for itself. Yet the people who approve, fund and build your designs are rarely designers, and they decide on what they can understand. A layout you cannot explain is a layout someone else will quietly rearrange. Seen from that angle, the explanation is part of the design, and like any other part of it, it can be drafted, tested and improved. ## What soft skills for designers look like in practice A design is rarely finished by the designer. Developers build it, product managers weigh it against everything else on the roadmap, copywriters fill it with words, and clients or stakeholders sign it off. What finally ships depends on those working relationships as much as on the file you hand over. Tom Greever's *Articulating Design Decisions* is built on a premise many designers learn the hard way: how you talk about your work with non-designers can matter as much as the work itself, and sometimes more. The people judging your design cannot see the craft directly. They see the parts they understand, and they decide on those. For a junior designer, that relocates a familiar frustration. When good work keeps getting watered down, the bottleneck is often the explanation, not the design. Five situations show this most clearly, and each of them is shaped by the fact that design work is judged by people who see it, react to it and build on it. ### Explaining your decisions to people who don't think visually "I just think it works better" is a reason only another designer can use. A client, a product manager or an engineer needs the decision translated into something they care about: the problem the design solves, the user it serves, the goal it moves forward. Lead with that, then show how the layout, the hierarchy or the flow gets there. The craft details are the evidence, not the headline. Greever's workshops on design communication are built around role-play and simulated design conversations, which treats articulation as something you practice rather than a gift some designers happen to have. Knowing your rationale and saying it out loud under questioning are different abilities. Rehearsing the two-minute version of why a screen looks the way it does, with a classmate or colleague playing the skeptical stakeholder, is the cheapest preparation there is for a real review. ### Hearing critique on work that feels personal Design work is visible and partly aesthetic, so almost everyone who sees it has an opinion about it, trained or not. That puts designers on the receiving end of more unsolicited reactions than most early-career roles. And because the work carries your judgment and taste, a comment on the spacing can land like a comment on you. One of the young people we interviewed about starting work described the fear that sits underneath that feeling: > You have this slightly irrational idea that everything has to fall into place right from the start. If I had been criticized — and I know now that you don't die from it — I would have found it embarrassing to be corrected, maybe even a bit humiliating. That was the feeling: it would be embarrassing not to deliver what I was supposed to. She was not talking about design, but anyone who has presented a first concept to a full room will recognize the feeling. The way out is a distinction. In *Discussing Design*, Adam Connor and Aaron Irizarry treat [giving and receiving critique](/knowledge/self-awareness/constructive-critique/) as a practical, learnable team skill rather than a matter of taste: useful critique stays on the work and asks whether it meets its goals. A reaction such as "I don't love the blue" becomes critique once you ask which goal it touches. Is the color hurting legibility, the brand or the user's attention? Asking that question turns you from defendant into investigator. You stop defending everything or accepting everything, and start sorting. If review meetings are where you feel most exposed, it helps to look at your own habits away from the room. A short self-assessment can [show where your habits stand](https://assessment.headwayskills.com/) across your workplace skills, so the next critique lands on something you are already working on instead of on a surprise. ### Showing work before it feels ready Greever has pointed to a specific difficulty with junior designers: getting them to show work in progress, especially when they [feel like imposters](/knowledge/confidence/imposter-syndrome/). The instinct is understandable, because unfinished work is where you feel most exposed. It is also where misalignment is cheapest to fix. A wrong assumption caught in a rough wireframe is a quick correction; the same assumption caught in a polished prototype means reworking days of detail and having a harder conversation about it. Holding work back until it feels perfect tends to make the eventual critique larger and harder to absorb. Many revision loops start even earlier, with a brief that was never pinned down. Designers often run several projects and several rounds of revision at once, and an unclear request multiplies across all of them. Before you open a file, clarify who the work is for, what exactly is being asked and what will count as done. Then share early, share often, and treat each round as a chance to steer rather than an exam to pass. ### Choosing what stakeholders see Non-designers react to whatever is most visible. Show a full-color mockup when you need a decision on layout, and the meeting will probably drift toward color. In a session for Goldman Sachs engineering designers, Greever advised removing details that do not serve the current conversation, for example taking the color out when the feedback you need is on structure. Think of it as the designer's version of [setting an agenda](/knowledge/communication/effective-meeting-agenda/). Decide before the review which decision the meeting has to produce, then shape the material so that decision is the one people talk about. Grayscale wireframes, a single flow instead of the whole product, two options side by side instead of five: each is a way of steering feedback toward what you actually need to know. ### Following through after the review Approval in a meeting is not the finish line. The second edition of *Articulating Design Decisions* treats a design conversation as three phases, preparing, presenting and following through, and recommends recording decisions in writing so the same discussions do not have to be held again. Verbal agreements tend to erode as the work passes through other hands. A developer simplifies an interaction, a stakeholder who missed the meeting reopens the question, and a few weeks later nobody remembers why the button moved. A short written note after each review, listing what was decided, why, and what happens next, protects both the decision and the people who made it. It also hands developers the reasoning behind the design rather than just the pixels, which helps them protect what matters when trade-offs come up. ## The skills that make design conversations easier Look back across those five situations and the craft itself barely features. What keeps recurring is how you explain, how you persuade and how you take in what other people tell you. **Communication** is what turns a rationale in your head into one a stakeholder can act on. It means stating the main point first, being clear and brief, and adapting to a listener who thinks in budgets, deadlines or code rather than layouts and type. It also means choosing the medium: a disputed design decision usually goes better in conversation, while the follow-up belongs in writing, where it documents what was agreed. And when a request would hurt the design, it means expressing disagreement plainly and calmly, then listening properly to the answer. **Influence** is how approval actually happens. It starts with preparation: understanding what each stakeholder values and how the decision will be made before you walk in. In the room, keep the pitch simple, let a prototype or a quick demonstration do some of the persuading, and be honest about the drawbacks of your own option. Listen fully to objections before answering them, and when a full yes is out of reach, settle for a small win you can build on. Afterward, follow up until the decision reaches production. Consistent delivery builds the reputation that makes your next pitch easier. **Building Self-Awareness** is what lets you use critique instead of absorbing it as a blow. A simple sequence helps: first make sure you understand the comment, then add your own view, then reflect on it once the meeting is over. Better still, ask for specific, future-focused feedback, such as what would make the next version clearer for someone's team, instead of waiting for reactions. Self-awareness also helps you notice when a belief that everything must be right the first time is keeping your work hidden too long, and which kinds of design work play to your natural strengths. Working out which of the three needs your attention first is itself a self-awareness question, and some outside structure helps answer it. The **free** Job Skills Test can [score the skills behind these conversations](https://assessment.headwayskills.com/), as part of the twelve it measures, and because each of them improves with practice, the result works as a starting point for your next project rather than a grade. ## Designing the conversation as well as the screen Some of this is probably already in your files. If you leave annotations explaining why a button sits where it does, you are writing design rationale; saying it out loud in a review is the same habit, spoken. The rest can be built without changing your eye or your taste: one rehearsed explanation, one follow-up note, one critique answered with a question instead of a defense. Which of these you start with is yours to choose. As your responsibilities grow, more of your work tends to happen in the conversations around the screens, so habits started now keep paying off for as long as you design. ## A quiet place to start All that remains is to choose where to begin, and that is easier with a clear picture in front of you. The Job Skills Test is a **free** self-assessment of your workplace skills: in 7 minutes, at your own pace, it shows where you stand across all twelve and which ones would make the biggest difference to how your work is received. **[Get my skills profile](https://assessment.headwayskills.com/)** *Free and takes 7 minutes. Results appear instantly.* ## Who this is for - Professionals building practical workplace skills - Readers looking for specific, usable work advice - Managers, educators, and coaches supporting career readiness ## Common questions ### What is this guide about? The soft skills designers need most: explaining design decisions to non-designers, taking critique, sharing work early and making approvals actually stick. ### Which Headway skill does this connect to? This guide connects primarily to Communication. It also relates to Influence, Building Self-Awareness. ### What is the recommended next step? Use the free Work Skills Test to reflect on which work skill to improve next. ## Related pages - https://headwayskills.com/knowledge.md - https://headwayskills.com/knowledge/soft-skills-at-work.md - https://headwayskills.com/knowledge/communication.md - https://headwayskills.com/knowledge/influence.md - https://headwayskills.com/knowledge/self-awareness.md - https://headwayskills.com/work-skills-test.md ## Citation guidance Use the canonical page when citing this content: https://headwayskills.com/knowledge/soft-skills-at-work/soft-skills-for-designers/ Preferred summary: "The soft skills designers need most: explaining design decisions to non-designers, taking critique, sharing work early and making approvals actually stick." ## Change log - 2026-07-07: Content collection version published.