larlet-fr-david-cache/cache/f599501674792192b83b5bbc2d7e5324/index.md

title: 4 Rules for Intuitive UX
url: https://learnui.design/blog/4-rules-intuitive-ux.html
hash_url: f599501674792192b83b5bbc2d7e5324

<p>This is my advice on improving the UX of your designs WITHOUT hours of user research sessions, paper prototyping playtime, or any other trendy UX buzzwords.</p>

<p>(Seriously, search “design thinking”. 0 results. <em>Nailed it</em>!)</p>

<p>Who’s this article for? I’m looking at you:</p>

<ul>
<li><strong>Developers</strong>. You created your own app, but every time someone downloads it, they struggle to use it. And you know if they’re telling you this, then it’s <em>really</em> bad.</li>
<li><strong>Graphic designers</strong>. Looking to make the transition into digital, but trying to learn UX by reading articles online is… a very painful way to die 😬</li>
<li><strong>PMs</strong>. Your job is already like 25% UX designer. Would be nice to level up those skills.</li>
<li><strong>And the hustlers</strong>. Anyone working on digital side projects nights/weekends. This one’s for you too 🍻</li>
</ul>

<p>If you’re already a UX designer, I don’t expect this article to go over super well with you. I’m basically skipping over entire chunks of our field in favor of focusing entirely on <strong>the single most lacking skill in aspiring UX designers</strong> (or UX-adjacent folks who find themselves designing screens).</p>

<p>I call it “<strong>speaking interface</strong>”.</p>

<p>When I started as a professional UX designer, I was <em>shocked</em> how many times my clients would hand me the initial wireframes (or the living, breathing, in-browser MVP) and there’d be <strong><em>completely obvious UX mistakes</em></strong> all over them. I’m not talking about things you need hours of research and A/B testing to discover. I’m talking, like, <em>dead simple</em> mistakes.</p>

<p>For lack of a better example:</p>

<blockquote style="margin: 0 auto;" class="twitter-tweet"><p lang="en" dir="ltr">Somewhere out there, there&#39;s a team that knows HTML, but doesn&#39;t know the difference between a radio button and a checkbox. <a href="https://t.co/VBwk8Jxekd">pic.twitter.com/VBwk8Jxekd</a></p>&mdash; Erik D. Kennedy (@erikdkennedy) <a href="https://twitter.com/erikdkennedy/status/867412999115464705?ref_src=twsrc%5Etfw">May 24, 2017</a></blockquote>
<script async="" src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

<p>Now my clients weren’t <em>this</em> bad, but <em>look </em>- you don’t need to be Bret Victor to understand that if you can only select ONE thing from a list, you need RADIO BUTTONS, not checkboxes. To understand <em>that</em>, you just need to be able to <em><strong>speak interface</strong></em>. And that’s the craziest thing to me. Interface fluency is something <em>anyone</em> can achieve. You don’t need college, you don’t need Lambda school, yadda yadda.</p>

<p>Frankly, you just need the <strong>presence of mind</strong> to (A) pause every single time you’re confused or frustrated by some app, (B) verbalize <em>what</em> about the interface makes you confused/frustrated/etc., and then (C) figure out how you could avoid that specific snafu that in your own designs.</p>

<p>Rinse and repeat that non-stop and you’ll be a pro in no time.</p>

<p>What I want to talk about today is <strong>four little rules</strong> that will help eliminate these pain points in your own designs. They’re the heuristics that are a level or two deeper than “use radio buttons if the user can only select one thing”. But, if you can remember to obey the things in this checklist, you’ll be that much closer to creating designs that your users can use easily right off the bat, freeing up your time for other, more important things.</p>

<p>(That’s when the other UX designers can lecture you on the newest academic user research methodologies!)</p>

<p>Here’s what we’ll be covering:</p>

<ol>
<li><a href="#1-obey-the-law-of-locality">Obey the Law of Locality</a></li>
<li><a href="#2-abd-anything-but-dropdowns">ABD: Anything But Dropdowns</a></li>
<li><a href="#3-pass-the-squint-test">Pass the Squint Test</a></li>
<li><a href="#4-teach-by-example">Teach by example</a></li>
</ol>

<p>Any questions? Let’s dive right in.</p>

<h2 id="1-obey-the-law-of-locality">1. Obey the Law of Locality</h2>

<p><em>Put interface elements where they affect change.</em></p>

<p>All else being equal, you should put the elements in your interface <em>near where they affect change</em>. This is because, when a user wants to make a change to the system, <strong>they will unwittingly <em>glance at where that change will happen</em></strong>.</p>

<p>So, let’s say you have a list of <em>things</em>. Where do you put the “ADD A NEW THING” button?</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-where.png" alt="law of locality in playlist illustration" />


</figure>

<p>Q: Well, where does the <em>change</em> happen?</p>

<p>A: At the end of the list.</p>

<p>Great, put the button at the end of the list.</p>

<p>WAIT. You’d think this would be pretty simple. But there’s a <em>temptation</em>.</p>

<p><strong>The temptation is to just put it <em>where we have space for it</em>.</strong></p>

<p>For instance, if you have a menu, maybe you’d think “We have a menu! Why not just put it in the menu!?”</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-menu-no.png" alt="the law of locality violated in a music UI" />


</figure>

<p>The answer is, of course, because <strong>users won’t look for it there</strong>.</p>

<p>(And the ultimate answer is that having a place where “we just put things” will ultimately render your app an unusable mess that people will abandon the first chance they see a half-viable alternative)</p>

<p>Don’t think I’m joking. Have you ever noted <em>this</em> interface?</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-evernote.png" alt="the law of locality violated in evernote's interface" />


</figure>

<p>An equally-bad/common alternative is to just take a solution that you’ve seen applied by A Respected Tech Company without any thought as to if it makes sense for <em>you</em>. “We need an ‘Add’ button? I’ve seen one of those. Hold my beer!”</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-fab-no.png" alt="the law of locality violated with a floating action button" />


</figure>

<p>Look. Another button in a place users <strong><em>will never look for it</em></strong>. To compound things, users will suspect <em>this</em> button actually adds a new whatever-is-currently-displayed-on-the-big-blank-white-space. Because that’s where the control <em>is</em>.</p>

<p>Your users <em>want</em> you to follow the Law of Locality.</p>

<p>So, now that we know it, let’s use it.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-bottom-of-list.png" alt="the law of locality in a list of music playlists" />


</figure>

<p>Bam.</p>

<p>But maybe you’re a born UX designer and <strong>you always visualize what happens when there’s 1000 items instead of 5</strong> and you realize: <em>there’s still an issue here</em>. If the user creates a TON of playlists, this button will disappear hundreds of pixels offscreen!</p>

<p>So maybe you could anchor the button <em>near the bottom of the list</em>, but have it <em>always be visible</em>, no matter how many hundreds of playlists the user has created.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-spotify-new-bottom.png" alt="the law of locality in Spotify's UI" />

<figcaption class="post__figcaption">For bonus points, (1) use the inline button UNTIL it's about to go offscreen, and at that point switch to the anchored solution and (2) make it more visible than Spotify's button, which took me months to notice while I haplessly right-clicked individual songs to add them to my playlists!</figcaption>
</figure>

<p>Brilliant! And this is what Spotify has done.</p>

<p>Another possibility is to say “Hey, we can’t <em>reliably and consistently</em> show the button at the bottom of the list. Where’s the <em>nearest logical place</em> to put it?”</p>

<p>And the answer is, (I think pretty obviously) <em>the top of the list</em>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-spotify-new-top.png" alt="the law of locality obeyed in Spotify's UI" />

<figcaption class="post__figcaption">I wish.</figcaption>
</figure>

<p>Sacrebleu! This is actually just what Spotify-competitor Rdio did, before they were acqui-shut-down by Pandora.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/lol-rdio.png" alt="law of locality obeyed in rdio's UI" />

<figcaption class="post__figcaption">Reconstructed from memory (like all reality, if you think about it)</figcaption>
</figure>

<p>The lesson here is clear. Never sell your company, and always always obey the Law of Locality.</p>

<p>(There are actually 3 laws of locality, and “Put UI elements where they affect change” is only the first. If you’re interested, read more <a href="the-3-laws-of-locality.html">here</a>)</p>

<p>Next!</p>

<h2 id="2-abd-anything-but-dropdowns">2. ABD: Anything but Dropdowns</h2>

<p><em>Any time you feel tempted to use a dropdown, ask yourself if one of these 12 controls is better instead.</em></p>

<p>One <strong>non-obvious lesson of UX design</strong> is that <strong>dropdowns</strong> are pretty much the <strong>worst control</strong>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-hell.png" alt="3 dropdowns to specify one simple date" />

<figcaption class="post__figcaption">Welcome to hell!</figcaption>
</figure>

<p>They’re not <em>always</em> bad, but you’re working against the following:</p>

<ul>
<li>Dropdowns take <strong>too many clicks/taps</strong>. One to open, a few more to scroll around to the right option (on mobile), another to select the right option, and (on mobile) another to close. (Compare to the <em>single click use-cases</em> of many of the options listed below)</li>
<li>Dropdowns <strong>don’t show you the options</strong>! You have to click into them to see the possible values, and on mobile, you can often only see a couple at a time.</li>
<li>Long dropdowns are <strong>ridiculous to navigate</strong>. A country dropdown for an app used worldwide could have 195+ countries. At some point, almost <em>any other method</em> of asking a user their country would be quicker than having them scroll through a dropdown (“Smoke signals?” AGCKKHKGH).</li>
</ul>

<p>This is pretty straightforward, so let’s just cover some examples for the various major cases of dropdown replacement.</p>

<h3 id="if-youre-choosing-between-2options">If you’re choosing between 2 options…</h3>

<p>We already have some fantastic options for allowing users to choose 1 of 2 things, all of which (A) show the options right away and (B) require fewer taps/clicks.</p>

<p>For questions to which there is no “default” answer, and either might be picked with roughly equal frequency, try a <strong>segmented button</strong>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-two-segment.png" alt="segmented button instead of dropdown control" />


</figure>

<p>If there is a “default state” that corresponds to “Off”, try a <strong>checkbox</strong>. A checkbox is also good for settings that don’t affect change <em>until the user presses Save or Submit</em>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-two-checkbox.png" alt="checkbox instead of dropdown control" />


</figure>

<p>Similar to the checkbox is the <strong>switch</strong>, which is good for changes that should apply <em>immediately</em>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-two-switch.png" alt="switch instead of dropdown control" />


</figure>

<p>Checkboxes and switches <em>only</em> make sense when there are two options. However, the following controls make sense for 2 to roughly 5 options, so you might try some of the following instead.</p>

<h3 id="if-youre-choosing-between-25options">If you’re choosing between 2–5 options…</h3>

<p>We covered <strong>segmented buttons</strong> above (and they apply here too) but it’s worth mentioning that when there are more options, <strong>vertical segmented buttons</strong> allow even more flexibility of answer length.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-few-segment.png" alt="vertical segmented button instead of dropdown control" />


</figure>

<p><strong>Radio buttons</strong> are similar, but particularly useful if you need to display a couple sub-elements for each choice.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-few-radio.png" alt="radio button instead of dropdown control" />


</figure>

<p>For detailed displays of just a few choices, <strong>cards</strong> are where it’s at.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-few-cards.png" alt="cards instead of dropdown control" />


</figure>

<p>One trick I like is displaying <strong>visual options</strong> literally.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-tesla-visual.png" alt="visual options instead of dropdown control" />

<figcaption class="post__figcaption">Tesla likes it too, apparently.</figcaption>
</figure>

<h3 id="if-youre-choosing-between-manyoptions">If you’re choosing between many options…</h3>

<p>When there are enough options that scrolling through them is annoying, consider a <strong>typeahead</strong> control. It’s like a search bar that shows top matching results as you type.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-many-typeahead.png" alt="typeahead control instead of dropdown control" />


</figure>

<h3 id="if-youre-choosing-adate">If you’re choosing a date…</h3>

<p>Picking a date from dropdowns is the <em>worst</em>. If I ever do this, then I’ve <em>really</em> failed as a UX designer.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-dates-dont.png" alt="don't use dropdown controls for choosing dates" />


</figure>

<p>But what do you use instead? Well, it depends. First question: what <em>type of date are you picking</em>?</p>

<ol>
<li><strong>Poisson dates</strong>. Dates <em>most likely to be in the near future</em>, tapering off as you go farther into the future (or nearer to the present), e.g. date of an appointment you’re scheduling, date of a flight you’re purchasing</li>
<li><strong>High-variability dates</strong>. Dates that have a <em>similar probability of being anywhere in a wide range of time</em>, e.g. date of birth, day-and-month of your birthday</li>
</ol>

<p>(Yes, I named “Poisson dates” after the <a href="https://en.wikipedia.org/wiki/Poisson_distribution" target="_blank">mathematical distribution</a> 🤓)</p>

<p>For different types of date-picking, you should use different controls.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-dates-chart.png" alt="chart of poisson vs. wide-range dates" />


</figure>

<p>For Poisson dates, you want to make it DEAD SIMPLE to pick dates in the most common range (e.g. for scheduling an appointment, it might be the next, say, 14 days). It’s perfectly OK if picking dates outside of that range is a little tougher.</p>

<p>A <strong>calendar control</strong> fits the bill rather well for Poisson dates. If you know the date to-be-picked is most likely in the next 2–4 weeks, you’re golden.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-date-calendar.png" alt="calendar control instead of dropdown control" />


</figure>

<p>Rather creatively, <a href="https://www.google.com/flights" target="_blank">Google Flights</a> <em>defaults</em> to you selecting a flight roughly 2 weeks in the future, which is perhaps an opportunity for confusion (“I didn’t choose this!”), but probably a better date to default to, and closer to the hump in the Poisson curve.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-google-flights.png" alt="Google Flights defaults to hump in Poisson distribution fo flight dates" />


</figure>

<p><strong>Date text inputs</strong> are probably the best option for high-variability dates, where (A) there’s no reason to favor any date over another, meaning (B) all options will be equally difficult to select.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-date-text.png" alt="date text input instead of dropdown control" />

<figcaption class="post__figcaption">Remember, input[type=date] is your friend… on desktop, at least</figcaption>
</figure>

<h3 id="if-youre-choosing-anumber">If you’re choosing a number…</h3>

<p>Numbers come in all kinds of flavors, but you’re most likely to be tempted to use dropdowns when you’re dealing with <strong><em>counts </em></strong>- e.g. the number of <em>tickets</em>, the number of <em>people</em>, the number of <em>rooms</em>, etc.</p>

<p>How often do you need 1 ticket? <em>Plenty</em>.</p>

<p>How often do you need 10 tickets? <em>Not so much</em>.</p>

<p>How often do you need 10,000 tickets? <em>Is this some kind of cruel joke?</em></p>

<p>For counts of things, you’re also dealing with Poisson distributions, and should use a control that biases towards lower numbers - like a <strong>stepper</strong>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-number-stepper.png" alt="stepper control instead of dropdown control" />


</figure>

<p>For wide-range numbers (like, say, SSNs), you weren’t going to use a dropdown anyways… <em>I hope</em>.</p>

<h3 id="so-can-i-ever-use-a-dropdown">So can I ever use a dropdown?</h3>

<p>Sure.</p>

<p>Remember, they work OK when…</p>

<ul>
<li>Users <strong>rarely need to change the default</strong> value</li>
<li>There are <strong>very few options</strong> - e.g. only 3 will be visible on the default iOS control</li>
<li>The user is <strong>not on mobile</strong> (whereby many of these problems are mitigated)</li>
</ul>

<p>The particularly observant among you may have noticed that the Google Flights interface I lauded above actually has <strong>three prominent dropdowns</strong>!</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/dropdown-google-flights.gif" alt="dropdown controls on google flights" />

<figcaption class="post__figcaption">Brilliant detail: on mobile, the 'Economy' dropdown is removed.</figcaption>
</figure>

<p>They actually do a great job with this. The potential usability issues are swiftly mitigated with:</p>

<ul>
<li><strong>Custom controls</strong> that show all options on tap (including on mobile) – and replace 4 dropdowns (for Adults, Children, and Seated Infants and Lap Infants) with <strong>4 steppers in a single dropdown</strong>.</li>
<li><strong>Removing</strong> the “Economy” dropdown on mobile</li>
<li><strong>Few options</strong> and <strong>smart defaults</strong> for each control</li>
</ul>

<p>If you want to print this section out and stick it on your wall, I’ve created a <a href="../extras/selection-controls-ux-checklist.html" target="_blank">printable cheatsheet</a> of dropdown replacements.</p>

<p>Anyhow. Let’s move on.</p>

<h2 id="3-pass-the-squint-test">3. Pass the Squint Test</h2>

<p><em>If you squint your eyes, the Most Important Thing should catch your eye first - and the least important elements should catch your eye last.</em></p>

<p>Pop quiz: what does a user need to do to <em>use this page</em>?</p>

<p>(NB: I’ve blurred it out so you have to go by gut instinct, but it’s a data entry form, to give you a hint)</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak1-blur.png" alt="blurred out version of a train ticketing ui" />


</figure>

<p>My best guess is <strong>two things</strong>:</p>

<ol>
<li>Check any <strong>applicable checkboxes</strong> (??) in the yellow area</li>
<li>Press the <strong>blue “Submit” button</strong></li>
</ol>

<p>Did you guess the same?</p>

<p>Wrong and wrong.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak1.png" alt="train ticketing ui violates squint test" />


</figure>

<ol>
<li>The “checkboxes” are actually very small numerical text inputs. (If you already read Anything But Dropdowns, you know Poisson numbers should be steppers)</li>
<li>The <strong>Most Important Thing</strong> (“Find Options” – which is a very confusing way to say “Submit”, by the way) is <strong>gray and unnoticeable</strong>. A much <em>less</em> important thing (“Help”) is immediately next it, but bigger and <em>more</em> visible.</li>
</ol>

<p>The Squint Test says the <em>Most Important Thing</em> must be the <em>most visible thing</em>. What’s the MIT? The ticket textbox (or stepper 😉) controls and “Submit” button.</p>

<p>If you make it past this page, the next page is even worse.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak2-blur.png" alt="blurred out version of a train ticketing ui" />


</figure>

<p>What will you click: gray button the <em>left</em>, or identical gray button on the <em>right</em>?</p>

<p>Hope you chose left!</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak2.png" alt="train ticketing ui violating the squint test" />

<figcaption class="post__figcaption">In rushing through this form, I actually clicked 'help' first. Oops. My second time on this page, I clicked 'Go Back', having processed there was an 'Add' and 'Go Back' button, and in the other 99.999% of (left-to-right language) websites, 'Go Back' is always on the left.</figcaption>
</figure>

<p>Again, <em>when I squint my eyes and look at the design, I can’t tell what’s important</em>.</p>

<p>Like the Law of Locality and Anything But Dropdowns, the Squint Test is a fairly simple law to enforce. Here’s like a 30-second wireframey redesign.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak2-redesign.png" alt="wireframe redesign of a train ticketing ui to pass the squint test" />

<figcaption class="post__figcaption">In a real redesign, I'd also want to consider allowing the user to specify number of tickets ON THIS PAGE. But that's another law for another time.</figcaption>
</figure>

<p>Does it work?</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-ak2-redesign-blur.png" alt="blurred out version of a train ticketing ui wireframe reddesign to pass the squint test" />


</figure>

<p>You tell me. Four radios and a button. And a tiny little link below it.</p>

<p>I’m not trying to pick on AlaskaTrain.com. You see this kind of stuff all over.</p>

<p>Here’s the signup screen for my beloved recommendation-based social network, Foursquare (blurred, of course).</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/foursquare-blur.png" alt="blurred out foursquare ui" />


</figure>

<p>How do you actually submit the required data? (i.e. the Most Important Thing)</p>

<p>Hint: it’s hidden in plain text in the upper-right corner.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-foursquare.png" alt="foursquare ui redesigned to pass squint test" />


</figure>

<p>But Foursquare is just following Apple’s design standards here. Unfortunately, violating the Squint Test is a tradition even among industry leaders.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-calendar.png" alt="ios calendar app failing the squint test" />


</figure>

<p>One way to find the Most Important Thing is to consider what percentage of pageviews will involve a certain action. Here’s flashcard/memorization software Anki analyzed in this way.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-anki.png" alt="action frequency analysis of Anki UI" />


</figure>

<p>For every 100 flashcards I view, I will <em>then go on to…</em></p>

<ul>
<li>Show the answer (approx. 95 times)</li>
<li>Navigate back to the list of decks (twice)</li>
<li>Start adding cards (twice)</li>
<li>Use some other feature (very rarely)</li>
</ul>

<p>This sort of analysis really hints at what kind of interface would work better here.</p>

<ul>
<li><strong>Emphasize</strong> the most-commonly used functionality (at first approximation, “most used” equals “most important”)</li>
<li><strong>Deemphasize, hide, or remove</strong> the less commonly used functionality</li>
</ul>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/squint-anki-redesign.png" alt="wireframe redesign of Anki UI to pass the squint test" />


</figure>

<p>Now this is just a start (I’d want to see if users understood that the unlabelled plus button <em>added cards</em>, for instance). But with just a couple simple heuristics, we’ve reduced a cluttered, confusing interface of 10 UI elements down to just 5. A reduction of… check my math here… 50%.</p>

<p>For more on the Squint Test, check out my YouTube <a href="https://youtu.be/B4XHaboNMOI" target="_blank">video redesign</a> of the Timezon.es web app. Or, if you don’t have 10 minutes, here’s a <a href="squint-test-ui-design-case-study.html">scannable, illustrated blog post</a> with the same step-by-step redesign.</p>

<iframe width="560" height="315" src="https://www.youtube.com/embed/B4XHaboNMOI" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen=""></iframe>

<h2 id="4-teach-by-example">4. Teach by example</h2>

<p><em>If you’re introducing users to new concepts, a few examples can be worth 1000 words - which your users wouldn’t read, anyways.</em></p>

<p>We have a weird tendency to try and explain things <em>in words</em> when <em>examples</em> would be much clearer.</p>

<p>Consider the new startup Teeming.ai, who recently reached out to me to ask about their homepage design. Headlines on the page read:</p>

<ul>
<li>“Teeming takes the <strong>isolation out of remote work</strong>”</li>
<li>“Teeming helps with <strong>remote team building</strong>” as well as “<strong>learning, problem solving, having fun, and motivating each other</strong>”</li>
<li>“Teeming and video for <strong>synchronous [communication]</strong>”</li>
<li>“Works with all your <strong>favorite video platforms</strong>”</li>
</ul>

<p>But here’s my question for you. <strong><em>What does Teeming actually do?</em></strong></p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-teeming-1.png" alt="teeming.ai UI doesn't teach by example" />


</figure>

<p>It’s tough to tell. I know it has something to do with… <em>good vibes for remote workers</em>? But I have no concrete idea how it would help me, so I wouldn’t otherwise try it, recommend it, etc.</p>

<p>(Sorry Teeming, you know I ❤️ you)</p>

<p>Next, let’s look at <a href="https://ifttt.com/" target="_blank">IFTTT</a>. Maybe you already know what they do - in which case, <em>pretend you don’t</em>, and try to figure it out from these headlines on their homepage:</p>

<ul>
<li>Automatically light the way for the pizza delivery guy (Dominoes+Hue)</li>
<li>Post your photo anywhere and see it everywhere (Instagram+twitter)</li>
<li>Make your voice assistant more personal (Google Assistant+iOS Calendar)</li>
</ul>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-ifttt-1.png" alt="IFTTT UI teaches by example" />


</figure>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-ifttt-2.png" alt="IFTTT UI teaches by example" />


</figure>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-ifttt-3.png" alt="IFTTT UI teaches by example" />


</figure>

<p>You don’t have to list too many examples to paint a decently clear picture: <em>IFTTT hooks apps together to do things they couldn’t do alone</em>.</p>

<p>The crazy part is, if you visit their homepage, they first explain it in text:</p>

<p><em>IFTTT helps your apps and devices work together in new ways. IFTTT is the free way to get all your apps and devices talking to each other. Not everything on the internet plays nice, so we’re on a mission to build a more connected world.</em></p>

<p>YAAAAWN.</p>

<p>My question: <strong>which gives you a better idea of the app?</strong> The examples, or the description? 🤔</p>

<p>I think it’s the <em>examples</em>. The description only resonates once I see a few examples of how it can help me.</p>

<blockquote>
<p>The description of your complex new app/feature only resonates once I see a few examples of how it can help me.</p>
</blockquote>

<p>But examples aren’t just for landing pages. Here’s what you see when you first sign into project management tool <a href="https://basecamp.com/" target="_blank">Basecamp</a>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-basecamp-1.png" alt="Basecamp UI teaches by example" />


</figure>

<p>Rather than seeing a totally blank page, you see <em>two obviously pre-fabricated example projects</em> that <strong>teach you, by example, how the whole app works</strong> (and also gives you an idea of what the tool will look and feel like when you’ve been using it a while).</p>

<p>Seriously, I can browse through fake <em>chat logs</em> by fake <em>users</em> discussing fake <em>file uploads</em> and fake <em>to-do items</em>.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-basecamp-2.png" alt="Basecamp UI teaches by example" />


</figure>

<p>There’s even a friendly… <em>mountain?</em>… telling me I can watch a 2-minute explanatory video about this sample project.</p>

<p>And thank you, Mr. Mountain, for the lead-in: <em>providing videos showing usage is another way of teaching by example</em>! Not only does the sample project model teach by example what my projects will look/feel like, but the video teaches by example what it looks like to <em>use</em> the software.</p>

<p>Brilliant.</p>

<p>If your app allows users to <em>create</em> something, a <strong>showcase</strong> is a great way to teach by example just what’s possible.</p>

<p>The beloved painting app <a href="https://procreate.art" target="_blank">Procreate</a> won an Apple Design Award, the App Store Editor’s Choice, the App Store Essential awards, and John Gruber called it “groundbreaking”, etc. – and yet none of this is as <em>viscerally</em> exciting as seeing what you can create with it.</p>

<figure class="post__figure">

<img src="https://learnui.design/blog/img/4-rules/tbe-procreate.png" alt="Procreate gallery UI teaches by example" />

<figcaption class="post__figcaption">This ain't no ordinary painting app.</figcaption>
</figure>

<p>Whoa.</p>

<p>That’s no MS Paint.</p>

<p>The showcase is a <strong>powerful tool</strong> for making it clear just what’s possible with your app.</p>

<p>So: if your app does something new and unfamiliar – or relies on new and unfamiliar concepts – you should get acquainted with <strong>the ways of teaching by example</strong>. The <em>moment you realize</em> that you’re introducing users won’t have seen before, you should start thinking: <em>how can I give an example to make this clearer</em>?</p>

<blockquote>
<p>The moment you realize that you’re introducing users won’t have seen before, you should start thinking: how can I give an example to make this clearer?</p>
</blockquote>

<p>In review, my favorite ways of doing this:</p>

<ol>
<li>On any page that tries to get the user to use a feature/app/etc., show examples of what they can do with your tool</li>
<li>Use the “first load” experience to provide sample data, showing by example what the properly-working app will look like</li>
<li>Strategically inject help content (like articles, videos, or tooltips) inline with the feature that show how to use it</li>
<li>Does your app allow users to create something? Include a user-submitted gallery of examples to spur imaginations</li>
</ol>

<p>Make sense? Let’s call it a day.</p>