Parker MalenkeDesign thoughts2022-11-03T00:00:00-00:00https://parkermalenke.com/Parker MalenkeDesign lessons #1: Design for the corners2020-07-24T12:00:00-00:00https://parkermalenke.com/wrote/design-lessons-1/
<img src="https://birdandbush.goatcounter.com/count?p=/feed.xml">
<p>You’re in a groove, slinging pixels around in Sketch and creating a cool new layout for a page that you really like. Everything fits together in a clear hierarchy, fellow designers give you feedback calling it <em>balanced</em> and <em>harmonious</em>, and it tests well in user sessions.</p>
<p>A few days later you get a message from your developer: “How should these columns layout for tablet screens? Everything looks smooshed, but switching to the phone design leaves a ton of space.” You forgot to consider the weird middle widths! You quickly sketch out an idea for stacking some elements to fit better, but it’s definitely a little funky.</p>
<p>Next week you’re reviewing the implementation so far and even the desktop view looks wacky! Turns out your design only really works with headings that are about four words long. Longer text wraps and pushes some elements way out of alignment, while one or two word headings leave unbalanced blank spots.</p>
<p>As your mind starts spinning with ways to fix this someone else raises their hand and asks: “What happens if you submit this form with the end time set to before the start time? Which field gets the error? Do we label both fields as incorrect, even though only one of them would need to change? Or do we need to show the error at a higher level?” You didn’t even think this form might have unique error states your style guide didn’t already cover!</p>
<hr>
<p>Today’s products are often complex. They have many different states. People from a continuum of different abilities and goals access them via a wide variety of devices and contexts. It’s easy to focus your design effort on the most common use cases and happy paths. But this leaves many open questions about what the edge case experience will be like.</p>
<p>These open questions will have <em>some answer</em> created for them by the time the product ships, whether you put in the time to craft a compelling solution or not. <em>Something</em> will appear on the screen when a a user enters an unusually long heading or visits a site from an unusual device. If you don’t take ownership of the edge cases these experiences will end up disjointed, kludgy, and detract from your product’s quality.</p>
<p>Alternatively, these edge cases are an opportunity to demonstrate your commitment to product quality. Even if only a few people experience each unusual scenario, the chances are good that most people will encounter one or two edge cases in their interactions with your product. You can surprise users in these moments with either your delightful thoughtfulness or disappointing apathy.</p>
<p>Here are a few frequently overlooked scenarios to consider before calling a design complete:</p>
<ul>
<li>
<p>All responsive sizes (not just phone and desktop)</p>
</li>
<li>
<p>Different label or paragraph lengths, different word sizes</p>
</li>
<li>
<p>Unusual states the UI can end up in</p>
<p>This can vary a lot depending on the complexity of the features you’re working on. It may be helpful to work with a developer or QA tester to make a list of various states the design should account for.</p>
</li>
<li>
<p>Scrolling behavior</p>
</li>
<li>
<p>Hover states</p>
</li>
<li>
<p>Animations or transitions</p>
</li>
<li>
<p>Slower internet connections or slower API endpoints</p>
</li>
<li>
<p>Affordances for assistive technology</p>
<p>This is a much bigger topic but there are a number of basics worth adding to your regular checklist such as: <a href="https://accessibility.iu.edu/creating-content/web-content/headings.html">Heading hierarchy</a>, <a href="https://webaim.org/techniques/keyboard/">Focus states and keyboard navigation</a>, <a href="https://www.washington.edu/accessibility/links/">Link text</a>, <a href="https://accessibility.oregonstate.edu/alttext">Image alt text</a>, <a href="https://webaim.org/articles/contrast/">Proper text color contrast</a>, and <a href="https://axesslab.com/make-site-accessible-screen-magnifiers/">Screen magnification</a>.</p>
</li>
<li>
<p>First run, empty, or loading states</p>
</li>
<li>
<p>Error states and messaging</p>
</li>
</ul>
<p>Check out this <a href="https://twitter.com/steveschoger/status/1284178659927044098">twitter thread</a> from Steve Schoger for another list of overlooked topics.</p>
<hr>
<p>No matter how nice your mockups are, the user ultimately only sees and interacts with the shipped product. Good design requires prioritizing and thoroughly considering the messy and unexpected edge cases a real world experience inevitably includes.</p>
<p>— Parker</p>
Design lessons #2: Don’t be afraid of process2020-08-08T00:00:00-00:00https://parkermalenke.com/wrote/design-lessons-2/
<p>What does the word <em>Process</em> make you think of? Perhaps a bumbling bureaucracy? Forms signed in triplicate? Slow busy work?</p>
<p>There can be a perception that <em>process</em> is the enemy of <em>progress</em>, something that just ends up getting in the way. In reality, work always follows a process, whether intentional or not. Even if you actively avoid laying down a workflow you will eventually find yourself treading similar steps again and again, entrenching an unplanned process. These emergent workflows tend to be chaotic and inefficient, leaving gaps and wasting effort.</p>
<p>If you’re willing to take a little time and apply a bit of forethought upfront, you can craft a thoughtful process that allows you to achieve better quality and increase your output.</p>
<hr>
<p>In reality, design is a team sport. Your work lives within a larger web of connections with other team members. Researchers, developers, product, marketing, accessibility — designers work with many different people on every project. Each person on the team contributes something special and adds value to the finished product. Process is the tool that allows you to shepherd the work through this web of contributors effectively and efficiently.</p>
<p>The key to healthy process is to recognize that the process itself is something you’ll need to work on. Good processes don’t just appear out of nowhere, some effort and intention must be invested in developing, sharing, and refining them.</p>
<p>So don’t be afraid to talk about process. Don’t just follow what feels like the path of least resistance. Take a little initiative to set up a workflow that works <em>for</em> you. And if you already have a process, don’t be afraid to tweak it. Process isn’t a burden to carry, it’s a tool you can sharpen and hone to help you.</p>
<hr>
<p>Some tips for crafting effective processes:</p>
<ul>
<li>
<p>Seek input</p>
<p>Remember, a process is a tool for helping a group of people work together. Make sure you learn from the people involved in your process and adapt it based on their feedback.</p>
</li>
<li>
<p>Become a broken record</p>
<p>Write your process down. Talk about it in meetings. Mention it in emails. A process does no good if people don’t know about it.</p>
</li>
<li>
<p>Create a shared vocabulary</p>
<p>Established processes such as agile development or Basecamp’s <em>Shape Up</em> encapsulate their key ideas by naming them: <em>sprint</em>, <em>story</em>, <em>pitch</em>, <em>cycle</em>. Naming a chunk of your process helps to define it more sharply, talk about it more easily, and build more mindshare around it.</p>
</li>
<li>
<p>Wrap tricky steps in timeboxes</p>
<p>Timeboxes can help avoid spending too much time on any one step of your process. Allowing for variable scope keeps the machine moving regularly.</p>
</li>
<li>
<p>Clearly identify decision makers</p>
<p>Consensus-driven decisions can bog down any process, and often lead to poorer outcomes. Whenever possible designate a single decision maker and task them with the responsibility to seek out, understand, and incorporate stakeholder input.</p>
</li>
</ul>
<hr>
<p>At the end of the day, your work follows a process whether it’s one you’ve consciously created or not. Don’t be afraid to commit to adopting a process. Putting a bit of thought and intention into the path your work follows can pay big dividends by making you more efficient in the long run.</p>
<p>— Parker</p>
Design lessons #3: (Written) communication is key2020-08-22T00:00:00-00:00https://parkermalenke.com/wrote/design-lessons-3/
<p>Design inevitably involves working with other people, and working with other people means talking to them. Sometimes we can chat in person, but most opportunities for communication come in the form of the written word. Emails. Slack posts. JIRA comments. Google docs.</p>
<p>In fact, not only does text dominate interactions within our teams, it’s also the number one way our products communicate with users. Consider how blank and meaningless your favorite app or product becomes when stripped of its text:</p>
<div style="" class="flex space-x-5 mt-8">
<div class="min-w-0 relative" data-controller="video">
<video muted="" controls="" loop="" class="max-w-full fancy-shadow z-0 relative cursor-pointer" src="https://parkermalenke.com/wrote_files/2020-08-12-design-lessons-3/maps-video.mp4" data-target="video.video" data-action="click->video#toggleState"></video>
<button class="absolute z-10 rounded-full flex align-center justify-center bg-purple cursor-pointer" style="width: 56px; height: 56px; left: calc(50% - 28px); top: calc(50% - 28px);" data-target="video.play" data-action="video#toggleState">
<img class="ml-2" data-target="video.playIcon" src="https://parkermalenke.com/images/play.svg" alt="">
<img class="hidden mt-2" data-target="video.pauseIcon" src="https://parkermalenke.com/images/pause.svg" alt="">
</button>
</div>
<div class="min-w-0 relative" data-controller="video">
<video muted="" controls="" loop="" class="max-w-full fancy-shadow z-0 relative cursor-pointer" src="https://parkermalenke.com/wrote_files/2020-08-12-design-lessons-3/podcast-video.mp4" data-target="video.video" data-action="click->video#toggleState"></video>
<button class="absolute z-10 rounded-full flex align-center justify-center bg-purple cursor-pointer" style="width: 56px; height: 56px; left: calc(50% - 28px); top: calc(50% - 28px);" data-target="video.play" data-action="video#toggleState">
<img class="ml-2" data-target="video.playIcon" src="https://parkermalenke.com/images/play.svg" alt="">
<img class="hidden mt-2" data-target="video.pauseIcon" src="https://parkermalenke.com/images/pause.svg" alt="">
</button>
</div>
<div class="min-w-0 relative" data-controller="video">
<video muted="" controls="" loop="" class="max-w-full fancy-shadow z-0 relative cursor-pointer" src="https://parkermalenke.com/wrote_files/2020-08-12-design-lessons-3/youtube-video.mp4" data-target="video.video" data-action="click->video#toggleState"></video>
<button class="absolute z-10 rounded-full flex align-center justify-center bg-purple cursor-pointer" style="width: 56px; height: 56px; left: calc(50% - 28px); top: calc(50% - 28px);" data-target="video.play" data-action="video#toggleState">
<img class="ml-2" data-target="video.playIcon" src="https://parkermalenke.com/images/play.svg" alt="">
<img class="hidden mt-2" data-target="video.pauseIcon" src="https://parkermalenke.com/images/pause.svg" alt="">
</button>
</div>
</div>
<hr>
<p>Communication is the magical ingredient which allows us to pool our effort, work together, and create something none of us could individually. Writing is one of the most powerful and common types of communication. With it we can reach hundreds or thousands of people at once, cut across timezones, bolster our memory, and scaffold our ideas.</p>
<p>Writing, and writing well, is an essential part of good design work. I think designers often underestimate the power of including this tool in their toolbox. Some may recoil from calling themselves a “writer”, others may prefer to leave the word-smithing to the experts. But a designer who can write well makes themselves both a more effective team member and a better designer.</p>
<p>Much of a designer’s day to day success depends on written communication. If I can’t clearly explain my idea in an email or JIRA story then my idea becomes far less valuable, potentially even harmful if it ends up causing confusion instead.</p>
<p>You can always call a meeting to hash through a particularly thorny topic, but I’ve found that even after extended discussion both parties often walk away with very different versions of the original idea.</p>
<p>Writing forces you — and helps you — to crystallize your own thoughts and provides a more tangible artifact you can review, question, and refer back to when communicating with others.</p>
<p>Written communication also forms the backbone of the products we ultimately spend our time designing. I think this can sometimes get lost in the shuffle of user testing, wire framing, refining visual design, tweaking animations, etc. At the end of the day, it’s words on the screen that guide users through the product and allow them to control features or create content.</p>
<p>Yes, we work with UX Writers and Content Strategists, and we try to practice content-first design. These roles and practices are awesome, but they don’t replace the communication-oriented mindset of a designer who takes writing seriously. Experts and specialists can help refine your work, but incorporating writing earlier into your design process can give you a much stronger foundation to stand on later.</p>
<hr>
<p>At the end of the day, good design means taking writing seriously. You don’t have to be an amazing writer (I know I’m not). Just recognize the importance, put some effort in, and try to get better, bit by bit.</p>
<p>— Parker</p>
Patterns vs. components in design systems2020-08-27T00:00:00-00:00https://parkermalenke.com/wrote/patterns-vs.-components-in-design-systems/
<p>One of the biggest challenges you’ll face when creating a design system is striking an appropriate balance between overly prescriptive guidelines and allowing too much customization. Make your components too rigid and they won’t work in many contexts, leading people to spend a lot of time working outside of the design system. Build in too many options and configurations to your components and you lose most of the consistency and efficiency promised by a design system.</p>
<p>Components form the majority of the guidance in most design systems. They’re fully specified and redlined, and perhaps backed by an HTML/CSS/JS implementation as well. A few configuration options may be offered, but by and large components tend to be a what-you-see-is-what-you-get type of resource.</p>
<p>I’d like to introduce the idea of a different type of resource, which I’ll call a <em>pattern.</em><sup class="footnote-ref"><a href="#fn1" id="fnref1">[1]</a></sup> This type of guidance works great for situations that need some degree of consistency, but where a full component would be too constraining. Let’s look at an example.</p>
<p>Consider an accordion that opens to reveal more content. These are pretty common elements seen in all sorts of websites and apps. In fact, they’re so common perhaps you intend to use them in several different parts of your experience. A small accordion within the help content, a larger accordion for partitioning settings, and you’re even using a similar paradigm in your tables to display tertiary information.</p>
<img srcset="https://parkermalenke.com/wrote_files/2020-08-25-patterns-vs-components/accordion.examples.jpg 2x" class="max-w-full border border-solid border-gold my-6" alt="">
<p>While these all fit under the category of “accordions”, there are enough differences that it would be difficult to create one component that works in all cases. Maybe you create separate components for each use case: a default accordion, a small accordion, a table accordion, etc. But this approach limits reuse, isn’t super sustainable, and won’t scale easily to support new accordion use cases you might discover in the future.</p>
<img srcset="https://parkermalenke.com/wrote_files/2020-08-25-patterns-vs-components/accordion.components.jpg 2x" class="max-w-full border border-solid border-gold my-6" alt="">
<p>This is a great scenario for an accordion <em>pattern</em>. A pattern doesn’t fully specify every dimension and style associated with a bit of UI. Instead, it focuses on describing a few key elements that should stay the same between different occurrence of the bit of UI. Let’s consider what the various accordion instances need to share with each other.</p>
<ul>
<li>We want to use similar icons for identifiability</li>
<li>We always want the icons to appear on the left for consistency, and to better support screen magnification use</li>
<li>Accordions should animate in a similar way</li>
<li>Most accordions should only leave one segment open at a time</li>
</ul>
<img srcset="https://parkermalenke.com/wrote_files/2020-08-25-patterns-vs-components/accordion.pattern.jpg 2x" class="max-w-full border border-solid border-gold my-6" alt="">
<p>We’ve decided these are the most important elements to give an impression of consistency to our accordions. Sizes, backgrounds, and colors can be tweaked to fit each use case, but as long as the pattern tenets are followed our accordions will be consistently identifiable and functionally similar.</p>
<p>From a design system perspective, patterns allow you to be a little less prescriptive than full components, while still providing strong guidance in a few areas to help achieve a degree of consistency and quality. And we didn’t have to create and spec a raft of slight variations on the same component!</p>
<p>Don’t forget you could consider pairing a pattern with a component as well. Let’s say the default accordion we specced out earlier works for 65% of the use cases in our product. Maybe it makes sense to provide one core accordion component for those scenarios and then pair that guidance with a broader accordion pattern to support the other 35% of use cases.</p>
<p>One tradeoff of the pattern idea is that you may lose out on some of the developer efficiency that comes from a fully specced component. Instead of building a component once, a pattern may need more custom code for each instance where it appears in the product. Often you can share some foundational code between the different instances of a pattern, but it is a consideration.</p>
<hr>
<p>Ultimately, the pattern concept is about making the design system work for you, your processes, and your use cases. A full component isn’t always necessary, but that doesn’t mean you should give up on providing some standard guidance.</p>
<p>— Parker</p>
<hr class="footnotes-sep">
<section class="footnotes">
<ol class="footnotes-list">
<li id="fn1" class="footnote-item"><p>I’m probably not the first to have this idea, but I haven’t seen a detailed description of the approach before.</p>
<p>Also, an aside on the name <em>pattern:</em> I’ve found terminology can be a bit of a confusing point within the design system world, especially if you’ve adopted Atomic design verbiage. Atoms, Molecules, Components, Elements, Patterns, Templates — what do they all mean?</p>
<p><em>Component</em> seems to have the most consensus behind it as a signifier for a whole chunk of UI or functionality. It implies completeness, tangibility, reproducability. A standard 2x4 or 2" nail.</p>
<p>I think “pattern” implies a looser set of conventions that may appear in many different forms. More a family of related species that share common traits, but each with some unique flair. <a href="#fnref1" class="footnote-backref">↩︎</a></p>
</li>
</ol>
</section>
Book notes: Atomic Habits2020-09-16T00:00:00-00:00https://parkermalenke.com/wrote/book-notes:-atomic-habits/
<p><em>Atomic Habits</em> by James Clear collects and distills much of the latest psychology research around habits and behavior change. It’s an excellent resource to use when planning a change in your behavior, or thinking about the behavioral habits of users.</p>
<p>Most of it feels a little obvious, and many of the principles are things I’ve sensed or experienced before. The real value of this book comes from the way all the principles are gathered and organized into a single framework that makes it easy to choose and apply the appropriate technique.</p>
<p>Below I’ve collected a short cliff-notes style summary of the major points for future reference. Overall, a quick and worthwhile read.</p>
<p>Rating: ★★★★<br>
<a href="https://www.amazon.com/gp/product/0735211299/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=0735211299&linkCode=as2&tag=parkermalenke-20&linkId=57c7944edc33c01649859f0b1a6e3372">Amazon</a><br>
<a href="https://www.worldcat.org/title/atomic-habits-an-easy-and-proven-way-to-build-good-habits-and-break-bad-ones/oclc/1043389440&referer=brief_results">WorldCat</a></p>
<hr>
<p><div class="table-of-contents"><ul><li><a href="#mechanics-of-habits">Mechanics of habits</a></li><li><a href="#1.-make-it-obvious%2Finvisible">1. Make it obvious/invisible</a><ul><li><a href="#planning-a-trigger">Planning a trigger</a></li><li><a href="#designing-the-environment">Designing the environment</a></li></ul></li><li><a href="#2.-make-it-attractive%2Funattractive">2. Make it attractive/unattractive</a><ul><li><a href="#temptation-bundling">Temptation bundling</a></li><li><a href="#cultural-influence">Cultural influence</a></li><li><a href="#inversion">Inversion</a></li><li><a href="#motivation-rituals">Motivation rituals</a></li></ul></li><li><a href="#3.-make-it-easy">3. Make it easy</a><ul><li><a href="#what-makes-a-habit%3F">What makes a habit?</a></li><li><a href="#law-of-least-effort">Law of least effort</a></li><li><a href="#two-minute-rule">Two minute rule</a></li><li><a href="#lock-in-behavior">Lock in behavior</a></li></ul></li><li><a href="#4.-make-it-satisfying">4. Make it satisfying</a><ul><li><a href="#immediate-satisfaction-promotes-future-repetition">Immediate satisfaction promotes future repetition</a></li><li><a href="#cardinal-rule-of-behavior-change">Cardinal rule of behavior change</a></li><li><a href="#tracking-habits">Tracking habits</a></li><li><a href="#inversion%3A-accountability-partner">Inversion: Accountability partner</a></li></ul></li><li><a href="#extra-tidbits">Extra tidbits</a><ul><li><a href="#choosing-what-to-be-good-at">Choosing what to be good at</a></li><li><a href="#beating-boredom-and-staying-motivated">Beating boredom and staying motivated</a></li><li><a href="#downsides-of-habits">Downsides of habits</a></li></ul></li></ul></div></p>
<hr>
<h2 id="mechanics-of-habits">Mechanics of habits</h2>
<p>Clear describes habits as consisting of four phases, each of which can be targeted and influenced by various techniques. They are:</p>
<ol>
<li><strong>Cue</strong> (Noticing the behavior)</li>
<li><strong>Craving</strong> (Desiring the behavior)</li>
<li><strong>Response</strong> (Acting out the behavior)</li>
<li><strong>Reward</strong> (Being satisfied by the behavior)</li>
</ol>
<p>These phases are targeted by the four laws of behavior change.</p>
<hr>
<h2 id="1.-make-it-obvious%2Finvisible">1. Make it obvious/invisible</h2>
<h3 id="planning-a-trigger">Planning a trigger</h3>
<p>You want to trigger the new behavior. One of the most effective ways to do this is to plan out a specific time and location for it. You can also stack the new habit onto an old one.</p>
<ul>
<li>I will [BEHAVIOR] at [TIME] in [LOCATION]</li>
<li>After [CURRENT HABIT], I will [NEW HABIT]</li>
</ul>
<h3 id="designing-the-environment">Designing the environment</h3>
<p>Your environment is full of cues. Another strategy is to fill it with cues for positive habits. E.g. set out the book I’m reading or move my phone away from my bed.</p>
<hr>
<h2 id="2.-make-it-attractive%2Funattractive">2. Make it attractive/unattractive</h2>
<h3 id="temptation-bundling">Temptation bundling</h3>
<p>Builds on habit stacking by adding a rewarding behavior on the end.</p>
<ul>
<li>After [CURRENT HABIT], I will [NEW HABIT], then [REWARDING HABIT]</li>
</ul>
<h3 id="cultural-influence">Cultural influence</h3>
<p>The people around us have a strong influence on our behavior. We tend to imitate (1) the close, (2) the many, and (3) the powerful.</p>
<p>Join a culture where (1) your desired behavior is the normal cultural behavior, and (2) you have something in common with the culture.</p>
<h3 id="inversion">Inversion</h3>
<p>Highlight the benefits of avoiding a bad habit to make it seem attractive.</p>
<h3 id="motivation-rituals">Motivation rituals</h3>
<p>Do something you enjoy immediately before starting a difficult habit.</p>
<hr>
<h2 id="3.-make-it-easy">3. Make it easy</h2>
<h3 id="what-makes-a-habit%3F">What makes a habit?</h3>
<p>Habits become automatic through repetition. This means the number of times you perform a habit is more important than the amount of time spent.</p>
<ul>
<li>Focus on taking action, not being in motion.</li>
<li>The most effective form of learning is practice, not planning.</li>
</ul>
<h3 id="law-of-least-effort">Law of least effort</h3>
<p>Create an environment where it is easy to do the right thing. Reduce the number of steps, reduce the friction necessary.</p>
<p>Increase friction for bad habits.</p>
<h3 id="two-minute-rule">Two minute rule</h3>
<p>Habits should begin as two minute tasks (read one page, instead of a chapter). Make it easy to choose the better behavior in decisive moments.</p>
<p>The more you ritualize the beginning of a process, the easier you can slip into a state of deep focus.</p>
<p>It’s more important to start a habit than to optimize one that doesn’t exist.</p>
<h3 id="lock-in-behavior">Lock in behavior</h3>
<p>A commitment device is a choice in the present that locks in better behavior in the future.</p>
<p>You can also try to automate your behavior as much as possible (auto saving deduction or social media timer lockout).</p>
<hr>
<h2 id="4.-make-it-satisfying">4. Make it satisfying</h2>
<h3 id="immediate-satisfaction-promotes-future-repetition">Immediate satisfaction promotes future repetition</h3>
<p>Humans will repeat satisfying behaviors. We prioritize immediate satisfaction over delayed gratification.</p>
<p>Make “doing nothing” enjoyable when avoiding bad habits. Find the benefit of avoidance and enjoy it.</p>
<h3 id="cardinal-rule-of-behavior-change">Cardinal rule of behavior change</h3>
<p>What is immediately rewarded is repeated. What is immediately punished is avoided.</p>
<h3 id="tracking-habits">Tracking habits</h3>
<p>Making progress is a satisfying feeling. Tracking habits can capture this satisfaction.</p>
<p>Don’t break the chain, or at least never miss twice in a row.</p>
<p>Make sure you are measuring the right thing, though.</p>
<h3 id="inversion%3A-accountability-partner">Inversion: Accountability partner</h3>
<p>Create a social cost to make behavior unsatisfying and undesirable. (Either inaction or active negative action.)</p>
<p>A full habit contract makes this real and effective.</p>
<hr>
<h2 id="extra-tidbits">Extra tidbits</h2>
<h3 id="choosing-what-to-be-good-at">Choosing what to be good at</h3>
<p>Maximize success by choosing the best field of competition. Play a game that favors your strengths. Genes don’t eliminate the need for hard work, they <em>clarify</em> what to work hard on.</p>
<h3 id="beating-boredom-and-staying-motivated">Beating boredom and staying motivated</h3>
<p>Human motivation is greatest when we are just on the edge of our capabilities. The greatest threat to success isn’t failure, but boredom. Habits can become routine and boring. Anyone can work hard when they’re motivated.</p>
<h3 id="downsides-of-habits">Downsides of habits</h3>
<p>Habits mean you can do things without thinking about them, but you can also miss little errors. Full mastery also requires deliberate practice. Reflection and review is a key part of maintaining mastery over time.</p>
<p>The more we cling to an identity, the harder it is to grow beyond it.</p>
How I found a UX job after being laid off during a pandemic2020-11-15T00:00:00-00:00https://parkermalenke.com/wrote/how-i-found-a-ux-job-after-being-laid-off-during-a-pandemic/
<p>I always appreciate learning about the journeys other people go through, everything from how they got started in an industry to the inside story of how a company was launched. Although perhaps smaller and less epic, I figured I’d share my own story of finding a new UX job during a potentially challenging time.</p>
<p>(If you’re short on time you can also just <a href="#lessons-learned">skip to my lessons learned</a>.)</p>
<h2 id="where-this-story-started">Where this story started</h2>
<p>Before getting into the details I’ll just share a bit of context around where I was at in my career. I have about seven years of experience in the UX world and had only worked at two companies prior to being laid off: <a href="https://www.pearson.com/">Pearson</a> for the last ~5.5, and a small UX research consulting group for ~1.5 before that.</p>
<p>While at Pearson I worked on a variety of general web application features for a few years before spearheading a design system effort. You can <a href="https://parkermalenke.com/#casestudies">read more about the details</a> in my portfolio.</p>
<p>In my yearly performance reviews I generally received exclusively positive feedback, was promoted once, and twice received relatively significant raises. I had the impression there wasn’t much additional room for me to grow upwards in the company, although my direct manager was encouraging of my ambitions when we would discuss them.</p>
<h2 id="getting-laid-off">Getting laid off</h2>
<p>I dialed in to a video call on May 12 along with the rest of my immediate team to learn that our group was being let go as part of a larger restructuring of the design organization within Pearson. They didn’t tie this directly to COVID (although I’m sure it contributed to some extent), and in fact I wasn’t all that surprised as we had gotten a new VP-level design leader who seemed intent on making many changes. Reading the tea leaves he dropped didn’t paint a bright picture for the design system team. My direct manager had a similar impression and found a new job, quitting about three weeks before our team was downsized.</p>
<p>In retrospect, I should have been paying closer attention to the moves of the company and been a little more proactive about keeping tabs on what other options were out there.</p>
<p>Fortunately, Pearson was pretty generous with severance terms. We were all still officially employed for another month, although management was clear that they didn’t expect us to really work during that time. With my five years of seniority I would get 10 weeks of severance and subsidized COBRA after the final termination date.</p>
<h2 id="starting-the-job-hunt">Starting the job hunt</h2>
<p>I had a lot of work cut out for me since I had done a terrible job of keeping my work history up to date. In fact, I essentially needed to recreate my entire portfolio from scratch. I spent the first few weeks trawling through my old work files, remembering what I had done and figuring out how to assemble the pieces into a compelling story. I decided to focus on just a few portfolio case studies, but to go pretty deep in each of them. I based this on some advice I found on Twitter, and on my own experience reviewing other people’s portfolios. I also had some feedback that hiring managers would be quickly scanning for key terms, so I decided to structure each case study with a condensed summary of the major points at the top, and the full analysis below.</p>
<p>Putting together each study took about a week and a half. I didn’t want to apply to new jobs without being prepared to put my best foot forward, but I felt pressure to start applying as quickly as possible. This was a fairly stressful time, as it felt like I wasn’t making much progress. Looking back, I’m glad I invested in creating a solid foundation that served me well in later applications and interviews, although it was frustrating at the time.</p>
<h2 id="sending-in-applications">Sending in applications</h2>
<p>Once I felt confident in my portfolio I started sending out applications. I mostly found jobs on LinkedIn and <a href="https://www.builtincolorado.com/">Built In Colorado</a>. It was at this point that I regretted not investing more time in building a larger network in the industry. I know from previous experience that having a connection to a hiring manager makes a significant difference versus sending in a cold application, but I didn’t have much of a choice. I did try to make the most of the people I did know by using LinkedIn’s feature that searches for any 2nd-degree connections I had with each company I applied to. I think this definitely helped in several cases, and I recommend taking the time to look up potential contacts and ask for quick introductions.</p>
<p>Most applications asked for a resume and cover letter. I wrote cover letters for every application, even when they were optional, because I thought it would increase my chances and was a good opportunity to point out why I was especially interested in a particular role or how I had some uniquely relevant experience. I didn’t get strong feedback on how effective my cover letters were overall. It certainly would have saved a lot of time to skip them, as it generally took one to two days to get them into a state I was happy with. Still, I didn’t want to risk losing out on a role by omitting this step.</p>
<p>At first, the cover letters were very excruciating to write (humble-bragging about yourself can be kind of exhausting), but over time I was able to reuse paragraphs and major sections, making the task easier. I also felt like I hit a higher level of quality in my later cover letters as I was able to make small tweaks based on feedback from interviews and became more comfortable writing about myself.</p>
<h2 id="results">Results</h2>
<p>All told, I applied directly to about 25 roles and had recruiters submit my résumé to about 5 others. Out of the roles I applied to myself, I never heard back from 7, was immediately rejected from 7, and progressed to at least one stage in the process with 11 companies. I only progressed beyond the first stage with about 4 companies.</p>
<p>Time between application and first response varied fairly significantly, with the shortest response being the same day (a rejection, sadly) and the longest being 34 days. The mean response time was 15 days, the median was 12 days. Five companies took 20 days or longer to reply.</p>
<h2 id="interviewing">Interviewing</h2>
<p>My first contact with most companies was a casual conversation with a recruiter. I felt less pressure about these basic phone screens and they were a good chance to learn more about the company and the role, since job descriptions could sometimes be a little vague. This was also a time for the recruiters to mention any quirks about the role, such as their remote work policy. The most common questions I was asked in these conversations were:</p>
<ol>
<li>What are you looking for?</li>
<li>Tell me about yourself?</li>
<li>Why are you leaving?</li>
</ol>
<p>I’d definitely recommend taking a few minutes to think about how you might answer these questions in the context of the specific company and role. For the third question, I always mentioned that I had been laid off as part of a larger restructuring (e.g. I wasn’t the only one let go). You definitely don’t want to start off by lying to the recruiter. I also tried to give some additional depth, such as mentioning my former manager and mentor had quit and I wanted to find a new boss I could learn from. As far as I could tell, being laid off never had an adverse effect on my applications, and I didn’t really expect it to.</p>
<p>From there the interviews would typically progress to meeting with the hiring manager and/or other members of the team. Depending on the company these could go in different directions. Some focused heavily on behavioral questions, others wanted to talk more about my design process and approach. I would try to ask recruiters for as much information as possible before going into these interviews, typically by saying something like: “what will they be looking for, and how do you recommend I best prepare myself?” This usually helped set me on the right course as I prepped. Depending on the company you can also learn a fair bit about their hiring practices by googling around and reading forums.</p>
<p>Most interviews took a traditional form where I just answered a variety of questions. Twice I had little design thinking/whiteboarding exercises, and once I had an app critique. For anything non-standard it was very helpful to gather as much information as I could beforehand and develop a bit of a framework for how I would approach the various prompts.</p>
<p>My general interview prep advice is:</p>
<ul>
<li>Treat the first few interviews of your overall job search as practice. You’re going to be rusty, so just do your best and then review your performance afterwards to see what adjustments you want to make. I didn’t really do any practice interviews, but I probably should have before doing a real one.</li>
<li>Don’t be afraid to talk yourself up. This comes with the practice of doing a few interviews. For most of us, most of the time, we’re trying to be team players and diffuse praise back towards our colleagues. Now is not the time to be humble. Take ownership of your accomplishments and the results you drove, even if indirectly. I gradually realized I could take a pretty strong stance without coming anywhere near being too arrogant or disingenuous.</li>
<li>Think through some behavioral scenarios ahead of time, and write down your answers, at least in bullet points. Even if your interview isn’t strictly based on behavioral questions, I found it quite helpful to have several stories I could tell depending on the question. It’s also much easier to remember your past experience when you’re relaxed at home, and not stressed in front of an interviewer.</li>
</ul>
<h2 id="how-did-covid-impact-things%3F">How did COVID impact things?</h2>
<p>I didn’t get a ton of feedback on how much the Covid-19 pandemic affected the market, probably partly because I hadn’t actively looked for work in quite a while and therefore didn’t have much to compare it to. Especially in tech, it depends a lot on the specific company and industry. Some companies I applied to were growing like crazy and positively affected by the shift away from physical spaces and interactions, others did admit to general belt-tightening. I never felt like I couldn’t find jobs to apply to, though. I’m not really sure if things were more competitive due to more designers being on the market.</p>
<p>As far as the effect on the actual process it was about what you’d expect: a lot of video calls. Pretty much every company was working fully remotely for the foreseeable future, and many said they were either planning to stay that way or open to employees continuing to work from home.</p>
<p>Chatting over video generally worked alright. In-person would have allowed for a little better read on the room, I think, but I was able to establish pretty good rapport with most interviewers. Make sure you have a semi-professional space to call from and use headphones with a separate mic to avoid audio interference.</p>
<h2 id="getting-hired">Getting hired</h2>
<p>Ironically the job I wound up accepting is one I never submitted an application for. I had applied to several different roles at Amazon using a referral from a former colleague. While none of those jobs panned out, I now had a profile in their system and was eventually contacted by a recruiter who, I believe, found my information by searching for someone with experience in design systems.</p>
<p>After going through the full interview process I eventually received an offer and accepted it on October 2, making the full job search a 4 month and 20 day ordeal.</p>
<hr>
<h2 id="lessons-learned">Lessons learned</h2>
<p>I had a lot of takeaways from this experience and intend to do several things differently in the future. Here are my top tips:</p>
<h3 id="1.-keep-a-work-journal">1. Keep a work journal</h3>
<p>One of the biggest pain points, especially early on, was updating my portfolio after years of neglect. I very much wish I had at least kept a basic list of notes that could inform the more polished portfolio case studies. In my research for portfolio best practices I came across this <a href="https://alistapart.com/article/the-career-management-document/">article on A List Apart</a> which recommends keeping a document of bullet points about your accomplishments from the previous week, including any portfolio artifacts. This basic source of content can then be refined down into a case study when you need to update your portfolio.</p>
<h3 id="2.-prep-for-questions">2. Prep for questions</h3>
<p>Along a similar vein, I had a little trouble thinking of scenarios or stories to tell for certain behavioral questions. I would tag entries in your work journal that might make good stories for interview questions you might expect to get in the future. For me, I struggled with questions like “tell me about a time you failed”, since I don’t tend to think of my work in such black and white terms. If I was reviewing events regularly it would be easier to identify applicable situations as they came up, rather than comb through the memory banks months or years later.</p>
<p>Here’s a list of questions I tried to prepare for:</p>
<ol>
<li>What are you looking for?</li>
<li>Walk me through your background? (2 — 4 minutes)</li>
<li>Why are you leaving?</li>
<li>Biggest strength/weakness? (Especially tied to your particular skills or the job you are applying for.)</li>
<li>Tell me about your design process?</li>
<li>What was a tough conversation, conflict, or challenge you had around getting someone to help you with something?</li>
<li>How have you responded to larger changes outside of your control?</li>
<li>What’s a time you changed your mind?</li>
<li>When have you failed and how did you deal with it/learn from it?</li>
<li>When have you had to be strategic with your time or resources in order to meet priorities?</li>
<li>How have you persuaded people at work?</li>
<li>What’s your proudest professional accomplishment?</li>
</ol>
<h3 id="3.-expect-an-emotional-roller-coaster">3. Expect an emotional roller coaster</h3>
<p>Getting laid off is an extremely disruptive experience, and job searching as you watch your savings dwindle adds a whole other layer of stress. Beyond the larger scale burden, I also experienced smaller scale fluctuations in mood as I would find a particularly exciting job opportunity or would be rejected from a job I felt eminently qualified for. Some days I felt very discouraged and almost reconsidered whether UX was the industry for me. Other days I would find the perfect job and start building up how great it would be in my mind. Then a rejection would dash my hopes and start the process all over again.</p>
<p>If you’re job searching without current employment you just need to accept that you <em>will</em> be riding this roller coaster and make concrete plans to help yourself deal with it. For me, this meant getting outside when I could, taking a day off to ride my bike or a long weekend for a camping trip. Coming back from a few days unplugged always helped me reset my perspective a bit and return to a more grounded mental baseline. It was tough sometimes to really take time off from job searching, as I felt like I needed to put 110% into the effort until something came through, but I had to recognize this wasn’t a sustainable path for me.</p>
<p>Taking care of your mental state probably looks different from my approach. Whatever works for you, just do it. Block off some days and invest the time in yourself. Even if you miss applying to one or two jobs because of it, you need to build a sustainable personal foundation that will get you through the stress and pressure.</p>
<h3 id="4.-evaluate-and-focus-on-your-unique-strengths-and-experiences">4. Evaluate and focus on your unique strengths and experiences</h3>
<p>As I applied to more jobs and had more interviews I started gaining a sense of how competitive my skillset was for various roles. I felt like even generic “UX Designer” roles tended to have at least a few specific areas of expertise that hiring managers were looking for. Some wanted extensive SaaS experience, others an emphasis on B2C products or a deep background in native mobile design. Often I only really learned the full extent of the preferences once I started talking with the recruiter or hiring manager.</p>
<p>Going in to my job search I considered myself a relatively experienced all-around designer. I had an extensive background in design systems but didn’t want to pigeon-hole myself as just a design system guru. I also didn’t fully appreciate how much deeper my knowledge was in this area than the average designer. Eventually, I realized I was getting much more traction with jobs that specifically involved design system work. Instead of diluting my unique experience by trying to show how it applied to more generic scenarios, I could lean into my expertise and take pride in all the details I worked hard on over the last few years.</p>
<p>My big takeaway from this was that it’s easier to sell yourself as really great in one or two areas than to try and be all things to all people. Even if you are a quick learner and could do well in a variety of roles, it can be hard to get others to believe that if you don’t already have some depth to back it up. Targeting smaller niches where you can paint a uniquely impressive picture makes it much easier for hiring managers to know if you’re a fit or not.</p>
<p>Going forward, I’ve learned that I need to be a little more strategic about the experience I’m collecting. Do I want to continue down this path towards design system expertise? Or is there another domain I’d like to work in during my career? Instead of just taking the experience that falls in my lap, moving forward I’ll pay more attention for opportunities to proactively collect the experience I want to have.</p>
<h3 id="5.-test-your-market%2C-even-if-you%E2%80%99re-content">5. Test your market, even if you’re content</h3>
<p>I was relatively happy and content in my role at Pearson, and never really looked for or applied to jobs until after I was laid off. In retrospect, this was a pretty big mistake. In going through my job search — reading job descriptions, talking with recruiters and hiring managers, writing cover letters — I learned a lot about what the designer market looks like and how my background measured up. By not testing the waters I had ignored all of this valuable information over the last few years. In the future, I think I will try to apply to interesting jobs every year or two, even if I feel fully content in my current role. Gathering information from the larger design market would help me evaluate where I’m spending my time and validate that I’m on the career trajectory I want to follow.</p>
<hr>
<h2 id="looking-back">Looking back</h2>
<p>Overall, my job search this summer easily cracks my top three most stressful experiences ever, but in the end I feel good about how everything turned out. It shifted how I think about my career, has inspired me to take a more active role in charting my path, and taught me about the practical steps required to do just that. I’m writing all of this down partly to serve as a reminder to myself for the future, but also to share what I’ve learned with the larger design community. I hope this deep dive into one person’s experience can help you, wherever you’re at in your career. If you have any questions, feel free to <a href="https://parkermalenke.com/#contact">say hi</a>!</p>
<p>— Parker</p>
Design systems need a community2021-01-26T00:00:00-00:00https://parkermalenke.com/wrote/design-systems-need-a-community/
<p>I’ve written before about <a href="https://parkermalenke.com/wrote/design-lessons-2">how important processes can be</a> to creating good design work. They’re especially important when it comes to design systems. The over-arching purpose behind systematizing your designs is to promote <em>consistency</em> and <em>efficiency</em>. If you dive into those goals a little deeper, it immediately becomes obvious that they depend strongly on the workflows and processes of the designers who use the design system. Consistency is achieved when multiple designers draw on the system to use the same solution for similar problems. Efficiency is achieved when one designer can contribute their work into the system, and then many other designers draw on that investment in the system in their own work.</p>
<p>The key to a successful design system is getting designers and developers committed to using the patterns and components from the system. One of the best ways to develop and nurture such a commitment is to build a community around your design system.</p>
<p>Imagine a naive version of a design system, where a couple designers go off in a closed room to create the guidance. They peruse existing styles, winnow down the options, and make a bunch of design decisions for the rest of the design organization. They create a snazzy library of pixel-perfect components, pull open the curtains, and wow the other designers with this great new resource.</p>
<p>A couple months go by, and the design system creators are a little discouraged by the designs coming out of the various other teams. People are following some of the basic styles, but adoption is far behind what they hoped for. Some of the products are even using patterns that clash with the official design system guidance. Asking around they discover a few problems:</p>
<ul>
<li>Some designers started using the system’s guidance, but over time discovered it needed to be tweaked to provide the best usability.</li>
<li>Other designers had to continue using old patterns, because the new guidance made trade-offs that don’t work for their use cases.</li>
<li>Some of the pages that serve more marketing functions had to be changed because branding has tweaked their look and feel.</li>
</ul>
<p>It would be difficult for the dedicated design system team to know all of these extenuating factors, let alone stay in touch with all the consumers as their needs change and evolve over time.</p>
<hr>
<p>As an alternative to this more naive approach of “benevolent dictators” who bestow a completed design system on your organization, consider building a shared sense of ownership throughout the design community. You’ll still want a dedicated group who can help steer the direction of the design system, but opening up the doors a bit will help other designers feel like their time spent learning, following, and contributing to the design system is well spent. It will also empower them to share their unique knowledge directly into the system.</p>
<p>So how do you establish a sense of community? The best methods for success will depend on your organization and culture, but there are a variety of methods you can use to help turn your design system into a shared resource.</p>
<h2 id="open-contribution-process">Open contribution process</h2>
<p>One of the clearest ways to establish a shared sense of ownership is to empower external designers to own content that lives in the design system. Nearly every design system will have a process for requesting a new or updated component, but allowing other designers to actually create the content for these changes can stimulate a stronger sense of commitment to the system. It also short cuts the update process, eliminating the need for the core design system team to do all of the work. They can instead coach and guide contributors who are better placed to understand the nuances and use cases of their requests.</p>
<h2 id="temporary-assignments">Temporary assignments</h2>
<p>An even stronger tool for cultivating deep understanding and buy-in to the design system is to have designers from consuming teams spend time as temporary members of the core design system team. Depending on your setup this could be for as short as a sprint or as long as several months. Bringing others designers onto the team helps them develop empathy for the challenges and opportunities of the design system and enables them to contribute their perspective as a customer of your design system. Ideally, they will return to their normal assignment as a strong evangelist for the design system and will help build the design system community even after leaving the core team.</p>
<h2 id="write-good-release-notes-and-update-regularly">Write good release notes and update regularly</h2>
<p>Consumers of the design system will want to know that it is being maintained over time and see that their requests actually turn into new components or updates in the system. Sending release notes builds trust in the long-term nature of your design system and helps you advertise how responsive you are to requests from the community. You can also highlight contributions from the community or temporary team members to reward people for engaging in the design system. To get the most value out of these updates you should commit to a regular cadence and stick with it.</p>
<h2 id="establish-a-vibrant-forum-for-dialog">Establish a vibrant forum for dialog</h2>
<p>No matter how much ink you spill when documenting your system and its components people will still have some questions or comments. Providing an easily discoverable and frequently active forum for asking these questions can both signal the quality of your design system and encourage participation in it, even when your guidance might not make complete sense to a consumer. Depending on how you build it this forum can also empower your customers to help each other out as well, either by answering each other’s questions or by making it easy to find the answers that other people gave to similar questions. Think of it like a custom version of Stack Overflow just for your design system.</p>
<h2 id="conduct-real-time-training-sessions">Conduct real-time training sessions</h2>
<p>Part of building an exciting, committed community around your system is to show off how exciting and committed you are to it. A great way to do this is to hold training sessions that deep dive into various parts of the design system. Run Lunch and Learn sessions like “Inputs and Forms 101” or “Contributing Your First Component”. These classes are good opportunities to actually talk with the people reading your documentation and get some direct feedback. Does your documentation actually make sense? What other designers are excited about your system? What concerns do other teams have? Dedicated trainings are a great two-way street to share your guidance and gather input from your customers.</p>
<hr>
<p>At the end of the day the success of your design systems depends on getting a high level of buy-in from your consumers. Opening up your processes, building a shared sense of ownership, and showing off your excitement for the system can go a long way towards creating a healthy and active community around the tool you’re providing.</p>
<p>— Parker</p>
Tips for design system component pages2022-11-03T00:00:00-00:00https://parkermalenke.com/wrote/tips-for-design-system-component-pages/
<p>Documentation, along with the actual Figma/Sketch/React components, forms the core of any design system. How can we make our documentation and component pages the best they can be? Here are a few tips I’ve picked up along the way.</p>
<h2 id="write-atomic-documentation">Write atomic documentation</h2>
<p>There’s a lot of talk about designing atomically within design systems, but this principle can also help simplify and streamline your documentation itself. Focus each section of the page on a single facet of the component or pattern. Avoid mixing different types of guidance within the same paragraph. For example: when annotating the major building blocks of a component don’t also describe the string length requirements for textual elements; save that information for a dedicated Writing section that can more exhaustively cover voice and tone, content strategy, and similar text-focused guidance.</p>
<h2 id="use-a-consistent-structure">Use a consistent structure</h2>
<p>Organizing your documentation into a similar structure across every component page will help consumers quickly find the guidance they’re looking for. Not every page contains the same information, but many pages will have a least some amount of overlap in the type of content they include. Standard naming and formatting will help make this information more accessible as consumers become familiar with the system.</p>
<p>Here are some of the standard categories I find useful when documenting UI components:</p>
<ul>
<li>Types (<em>Primary</em>, <em>Secondary</em>, etc.)</li>
<li>States (<em>Focused</em>, <em>Pressed</em>, <em>Disabled</em>)</li>
<li>Anatomy (what are the major elements and their names)</li>
<li>Interaction (what can a user do with the component)</li>
<li>Writing (how to write good text for the component)</li>
<li>Accessibility (any unique considerations)</li>
<li>Usage (advice for how and when to use the component)</li>
<li>Responsive (how the component adapts to viewport changes)</li>
<li>Redlines/Specs (exact pixel measurements of the component)</li>
</ul>
<h2 id="follow-the-inverted-pyramid-model">Follow the inverted pyramid model</h2>
<p>Journalists often follow an inverted pyramid model when writing their articles, focusing on the most important and straightforward facts at the beginning of a piece and transitioning into less important background information towards the end of an article. Component pages should take a similar approach. Expect most consumers to read only a small portion of any page and organize your information accordingly.</p>
<p>The first chunk of the page quickly answers questions like: What is this component? What does it do? Is this the component I’m looking for? Then transitions into describing the core features of the component.</p>
<p>Use the rest of your content to flesh out the details of these features, their nuances, recommended configurations, etc.</p>
<p>Don’t be afraid to include a lot of information in your component pages, just structure it in such a way that obscure details don’t drown out the major points.</p>
<h2 id="always-tell-the-truth">Always tell the truth</h2>
<p>Imagine a perfectly organized, beautifully laid out, engagingly written component page, but every third paragraph contained out of date information. Accuracy is an essential element of design system documentation, a resource often referred to as the “single source of truth”. Make sure consumers can actually trust the information you’re sharing.</p>
<p>Seems obvious, but this can be harder to achieve in practice. Little tweaks get introduced, behavior is adjusted to make development easier, features get de-prioritized but remain in the design specs, etc.</p>
<p>A few tools to help combat the entropy:</p>
<ul>
<li>Use beta versions of your pages to start writing guidance which may not be the truth <em>yet.</em></li>
<li>Integrate your documentation into a single source as much as possible (design, redlines, code/api). This will make it easier to identify any mismatches as updates roll out.</li>
<li>Include a step to check for accuracy in your publishing process.</li>
</ul>
<h2 id="balance-words-with-images-and-animations">Balance words with images and animations</h2>
<p>Sometimes a picture really is worth a thousand words. Judicious mockups and diagrams can help clarify complex UI or concepts with just a glance. Brief gif or video animations can quickly communicate detailed interactions or motion designs. At the same time, images can lack the specificity possible with text. Not everyone reads the same thousand words when they look at the same picture. Don’t be afraid to include as much text as needed to fully explain the constraints of a component.</p>
<h2 id="do-include-do%E2%80%99s-and-don%E2%80%99ts">Do include Do’s and Don’ts</h2>
<p>We know users scan and skim, rather than truly read. This behavior applies to design system documentation too. Often, your consumers will have at least partial familiarity with a given component, having used it before or seen it in other’s work. Writing atomically and organizing in standard structures does help optimize for this type of consumption, but you can go even further towards getting the most salient information before your consumer’s wandering eyes.</p>
<p>Do’s and Don’ts provide a stripped down way to reliably highlight the most important information for a reader to glean from a documentation page. While a design system guarantees a certain amount of consistency just by existing, you get the most bang for your buck when designers follow conventions and use their judgement to apply standard principles to diverse use cases. While you may explain these conventions more precisely or technically in the body of your documentation, the concrete examples provided by a set of do’s and don’ts help crystallize their meaning in more practical terms.</p>
<hr>
<p>And there you are, six tips I’ve learned from my time working on design systems. If you have any thoughts on these or new tips of your own, do get in touch.</p>
<p>— Parker</p>