This is my attempt to document some of the things product designers learn as they grow and gain experience. By product design I mean the work of creating products and features, which sits at the intersection of product management, design disciplines like UX / UI / graphic design / ID, and engineering. Each of the below represent things I've had to learn myself, things I've heard other designers have gone through, and/or things I've observed in many people new to the field.
Things Experienced Designers Do
🙅 Making difficult choices - in design you have to make hard decisions where no answer is perfect for the multiple use cases you're trying to enable. Good designers know this and tend to make these decisions, where more junior designers are more likely to try to kick that choice down to the user - either because of a lack of confidence, or because they do not perceive the full cost of that indecision to the user and product. The effect of this is more decision fatigue for users, more setup time, added complexity in preferences, and generally a lot of cognitive overhead for not a lot of gain. Occasionally, asking the user is the right choice, but not usually.
⚖️ Balancing and integrating, not just adding - the easiest thing to do in a product is add a feature. People new to design tend to see the world of product as a set of features to build more than an experience to balance, and they rush to add things until they paint themselves in a corner with an encumbered experience that lacks a cohesive purpose. Balancing and integrating takes a lot more effort, and involves operating at multiple levels of abstraction, such as knowing when to rearchitect or rethink a given part of the product with the addition of a new feature. Experienced designers know information architecture plays an incredibly important role in shaping user experience by creating a legible mental model, a hierarchy of simplicity and friction, and a way to spread the complexity around. Experienced designers also understand the restraint required to avoid adding a feature just because it's ready & cheap to build, if its addition would cause a future, more important feature's addition to be the straw that breaks the camel's back.
📦 Thinking in releases and bundles - rather than thinking on a per-feature level, which is an internal model, an experienced designer should be thinking about what releases go to users, an external model. Perhaps a feature makes one part of the product a bit too complex. Thinking in releases lets designers say "if I add complexity here, I'm going to have to move something over there." Similarly, sometimes features need to be drastically changed or even removed. If these aren't smartly bundled with other capabilities such as a couple of small requests users have long asked for, users will find releases an unpleasant experience, unsure if the next update will be good or bad. It's much better to bundle them into a single "two steps forward, one step back" release, so that every release is a positive experience.
💿 Using real data - when in the nuts and bolts of UI design, the designer's mind is primarily focused on spatial relationships. This naturally leads to designers filling in dummy data to show off mockups in the best possible light. Names get shortened, all data fields gets filled out properly, content doesn't cascade to the next line unless its part of the design, etc. This almost never looks like how the design works in the real world, with real people. Something every designer learns after shipping a few products is that you need to design with real data from the get go, in all its unaesthetic and unwieldy glory.
⍰ Avoiding black boxes - when you're new to design, there's a strong tendency to solve the easy problems first and hide complexity in 'black boxes' that are ill-defined. These black boxes can be things like 'ML will solve this', 'we'll put some therapy content here', 'we'll figure out how to show the feed later', or other things of that nature. These black boxes generally represent the designer's ignorance of a given product aspect, use case, or entire field (e.g. engineering, or a subject matter expert's field), and wind up becoming what the entire product hinges on. They're also often infeasible in practice. More experienced designers know to work out the least clear and hardest things first, because that dictates what is possible, and only after that address the more straightforward tasks of fleshing out the rest.
📝 Writing great copy - words are one of the most essential yet least appreciated parts of a product. They form the user's mental model, guide users on how to use the product, and can affect their emotional response. Most designers, especially new designers, treat copy as an afterthought, but a good designer knows you must sweat every word as much as you do ever UI box, button, or icon. The names of features suggest their capability, and finding words at the right level of abstraction and specificity is difficult, especially for a growing product. For instance, if you've been calling things 'apps' but then you start supporting email lists, do you call it 'apps', 'apps and lists', or change to a more generic word like 'projects'? Copy also overlaps heavily with customer support, and unless designers focus on that overlap, which they rarely do, the overall user experience is going to feel disjointed.
🧑🏻🏫 Favoring clarity over efficiency - we all want things to be simpler, and often that means figuring out how to eliminate steps, pages, or clicks to improve experiences. However, in pursuit of this goal, designers can develop a blind spot because they know their own design too well (the Curse of Knowledge) and lose sight of what users actually understand. Another way efficiency can steer users wrong is by packing too much on a single screen, overwhelming users. Paradoxically, an optimal design may be one that isn't the most efficient, but instead ensures the majority of users clearly understand what action they're taking - even if it is at the expense of some savvy users.
🧠 Considering the learning curve - something I notice in most designers I've met and products I've seen is an insufficient level of consideration to what sort of Knowledge Load a product has. This involves how many concepts are introduced, where they're introduced, how consistently they're messaged, how they're reinforced, etc. Sometimes this also manifests in the overuse of icons, which to users just appear as strange hieroglyphs. Designers usually confuse the process of learning as something to be solved by separate and discrete feature, such as implementing bolt-on new user walkthroughs, rather than a higher level approach to a product's design. Walkthroughs can work for users who are familiar with common patterns in apps, and certainly make designer's lives easier by not having to think about it (see again the Curse of Knowledge), but leaves many other users with an underdeveloped mental model for how a product operates. Ideally, designers would adopt on an education mindset and do an audit to understand exactly where concepts are introduced, and even build analytics to suss out what level of understanding users have on a per-concept basis.
🏚 Using data as a foundation - data structures define a product's possibilities and limitations and outlast almost all features, yet less experienced product designers tend to leave them to engineering and instead focus heavily on UI or use cases. This leads to a lot of unpredictable limitations later in a product, and unnecessary engineering in the meantime. The smartest designers I know have a deep understanding of how data is structured and how each feature uses and modifies that data, as well as a much clearer understanding of what future features are possible or not based on that structure.
🎯 Getting specific - people new to design tend to confuse an idea for the expression of an idea. Ideas are easy, because they don't rely on specifics. Expressing ideas is incredibly difficult, because doing it well requires a deep understanding of the medium that is only possible by having worked in it, such as understanding which methods to use where, identifying subtle technical & conceptual complexities, knowing the rules and how to break them, etc. As Steven Sondheim once said, "God is in the details," which in product design means the magic (and hard, smart work) of how all the specifics fit together to make something greater than the sum of the parts.
🚶🏿Looking ahead - building features as you go is all tactics, whereas plotting a grand plan is all strategy. All product designers struggle to some extent with how to balance tactics & strategy and thus how far ahead to make plans and do work for any given product or feature, but this especially is felt in people new to design. New designers tend to overestimate the correctness of their plans and underestimate their complexities, which can lead to over-architecting systems, 'painted into a corner' situations, an immense amount of technical debt, and/or entire product pivots. As product designers gain experience they get better at investing the right amount of effort and planning for a given feature or plan so as not to under- or over-build, identifying the right choice points where user feedback is essential. A good product designer can tell roughly how far in the future to design in anticipation of; one feature may have a whole range of follow-on capabilities that should be planned for up front, whereas another feature might rest on the feedback users give for the follow-on capabilities to be clear.
🪢 Combining use cases - people new to design often critique products with refrains like "why can't I do [extremely specific thing] easily?" Yet, a product that only did a specific thing probably wouldn't have enough other capabilities to cause a user to even remember to use it, let alone download it. Instead, the best features are usually those that satisfy a whole range of use cases decently well, which means users have enough encounters with the feature to remember to reach for it and when they do, remember how to use it. As designers get more experienced, they learn how to spot commonalities in multiple use cases that suggest a single solution to create 'more wood behind fewer arrows', as well as find the meaningful differences that show a given use case needs a different solution or a specific callout.
🖌 Knowing when to iterate - designs tend to get better with time and iteration, but at some point there are diminishing returns. I've noticed an iteration dynamic that tends to appear across design skill:
- people new to design tend not to iterate nearly enough, sometimes even settling on their first instantiation of an idea because they lack the base of experience to see how an idea could be built in drastically different ways or how to accurately compare the pros and cons of different solutions.
- people who have some experience designing tend to iterate a bit too much, spending time on minor details while larger, (usually) less UI-oriented needs remain under-addressed.
- people who are quite experienced in design tend to iterate just enough to settle on a good solution, in part because they're more efficient finding fruitful paths to go down.
💔 Knowing when to break the rules - a similar dynamic exists with how design rules are followed based on design skill:
- people new to design tend to break rules haphazardly, because they don't have enough of a base of experience to know when to use what kind of design or method for a given problem.
- people who have some experience with product design tend to follow the rules consistently.
- people who are quite experienced tend to find the few places where it makes sense to break the rules, either because the rules didn't have a good solution, or because the product, brand, or market demands a type of differentiation.
🔭 Knowing when something is possible - there's a difference between a novel feature or idea that is proposed by someone new to design versus something proposed by a domain expert. Note this is specifically for saying what is possible, not what is impossible. Paul Graham describes it well:
"Most implausible-sounding ideas are in fact bad and could be safely dismissed. But not when they're proposed by reasonable domain experts. If the person proposing the idea is reasonable, then they know how implausible it sounds. And yet they're proposing it anyway. That suggests they know something you don't. And if they have deep domain expertise, that's probably the source of it."
🖼 Knowing when to curate - in many types of products, the content is the experience and the UI or aesthetics barely matter. Product designers often forget this.
Summary
The more you learn product design, the broader your scope gets, and the more you seek out ways to make a product greater than the sum of its parts. You have to think about the complete user experience across all the activities of a company, across all types of users at all levels of understanding of what you do, across time as the product changes, and from pixels and boxes to words and updates. You have to think not just about your particular instantiation of an idea but also keep an open mind to the many different ways that a problem can be solved - especially those outside your skillset. Your work takes you far beyond your immediate domain of design as you seek to understand all the tools and degrees of freedom you have available to you to create the best product possible.
Related
Speaking Product - How to communicate effectively in cross-functional product meetings