davidbgk
/
larlet-fr-david-cache
Tarkkaile 1
Äänestä 0
Fork 0
Koodi Julkaisut 0 Activity
A place to cache linked articles (think custom and personal wayback machine)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
252 Commitit
1 Haara
Puu: a019624b80
Branchit Tagit
${ item.name }
Create branch ${ searchTerm }
from 'a019624b80'
${ noResults }
larlet-fr-david-cache/cache/46670cc5f41e6ab7250535b3bf0.../index.md

index.md 25KB
Raaka Normal View Historia

Add cache data
4 vuotta sitten
​
​
​
​
 12345 
  1. title: “God is in the details.”

  2. url: https://medium.com/@buzzusborne/god-is-in-the-details-bc3a9a9a5d88

  3. hash_url: 46670cc5f41e6ab7250535b3bf0dde49

  4. 

  5. <p name="77c9" id="77c9" class="graf--p">It applied to <a target="_blank" href="http://en.wikipedia.org/wiki/Ludwig_Mies_van_der_Rohe" data-href="http://en.wikipedia.org/wiki/Ludwig_Mies_van_der_Rohe" class="markup--anchor markup--p-anchor" rel="nofollow">Ludwig Mies van der Rohe</a> when he was designing buildings in the mid 1900’s, and it remains true in product design today. Though I don’t profess to know much about architecture, another likely commonality with product design is that it’s those same details that are the easiest to forget. But it’s those little things, the tiny minutia of detail, that ultimately make beautiful products, and beautiful houses.</p><p name="e21d" id="e21d" class="graf--p">Unfortunately, when I refer to the “details” in product design, I’m not talking about obvious design things; like colours, drop-shadows or placement. Instead I’m referring to something harder to define; experience and subconscious patterns that help the user feel more at-ease with an interaction. That detail might come in the form of a change in cursor, a “down” style for a button, or a helpful animation.</p><p name="b064" id="b064" class="graf--p graf--last">Whatever form that detail takes, I’ll bet that it wasn’t designed in Photoshop, or included in even the most detailed spec document. It’s the details that fall outside of titles like UX, or UI. It’s interaction detail that can only be found after using a product <em class="markup--em markup--p-em">for real</em>, then dedicating solid design and engineering time to building.</p></div></div></section><section name="1cbf"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="2476" id="2476" class="graf--p graf--first">The details are difficult to include when you’re building a product; they’re expensive both in terms of time and technical overhead — which is why they’re rare. I spend my time in pursuit of these details, and as the designer and developer of <a target="_blank" href="https://prevue.it/" data-href="https://prevue.it/" class="markup--anchor markup--p-anchor" rel="nofollow">Prevue</a>, I have two luxuries which thankfully afford me the ability to obsess over them:</p><p name="c641" id="c641" class="graf--p"><strong class="markup--strong markup--p-strong">The first</strong> is that I have the capacity to <a target="_blank" href="http://blog.prevue.it/posts/use-improve-repeat" data-href="http://blog.prevue.it/posts/use-improve-repeat" class="markup--anchor markup--p-anchor" rel="nofollow">use, improve and repeat</a>. I’m not just talking about about the technical ability to implement the details — I’m also talking about having the <em class="markup--em markup--p-em">time</em> to do so. Sometimes an interaction will take me 50% longer to build, simply because I’ve spent hours obsessing about the animated states that occur over a 0.65 second duration. That’s not a luxury that many products can afford, or are willing to build into scope. Understandably so.</p><p name="2343" id="2343" class="graf--p"><strong class="markup--strong markup--p-strong">The second</strong> is that I use my product, for real, every single day. If there’s an annoying interaction, unnecessarily lengthy animation or a dumb user-flow — the chances are pretty high that I’m going to spot it. That’s the difference between functional testing:</p><blockquote name="a3ca" id="a3ca" class="graf--pullquote pullquote graf--startsWithDoubleQuote">“Does X do Y when you press Z?”</blockquote><p name="a4b4" id="a4b4" data-align="center" class="graf--p">Versus true-to-life user-testing:</p><blockquote name="2a67" id="2a67" class="graf--pullquote pullquote graf--startsWithDoubleQuote">“Does the product intuitively help me achieve a task,<br>quickly, when I’m up against a deadline?”</blockquote><p name="68e7" id="68e7" class="graf--p">But let’s be honest; using a product over-and-over, re-building functionality, and obsessing about the little things takes a <em class="markup--em markup--p-em">lot </em>of<em class="markup--em markup--p-em"> </em>time — perhaps a luxury afforded to side-projects like Prevue, or products with too much money. They’re usually too hard to justify, and they’re definitely the first thing to be sacrificed when push comes to shove. That’s probably why Ludwig Mies van der Rohe only designed a handful of buildings that weren’t ugly skyscrapers — or why Prevue doesn’t ship features very often.</p><p name="225d" id="225d" class="graf--p graf--last">Having spent the last 7 years polishing my own side-project, I’ve learned where to look for “quick wins” when it comes to building detail-oriented design into larger, fast-moving commercial products. So instead of professing to knowing the perfect solution for forcing “detail-mining” into your release schedule, I thought I’d share a few places where you can start looking for improvement in your own projects, and why those details can make all the difference.</p></div></div></section><section name="63d1"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="40be" id="40be" data-align="center" class="graf--h3 graf--first">Visually Confirm Interactions</h3><p name="c5dc" id="c5dc" class="graf--p">I’m going to start with something that applies to most products, yet is so commonly overlooked — button states. Even on a fast internet connection, there’s likely going to be a delay after pressing a button before the next action takes place; like a new page load, image upload, or some kind of event. Yet so few products give any visual confirmation that something is happening in the background.</p><p name="9a00" id="9a00" class="graf--p">Leaving the user hanging there, with no confirmation that their click actually did anything, is likely causing an unnecessary break in their journey. Whilst your servers are processing the action, your user is wondering whether their click actually registered. They’re <em class="markup--em markup--p-em">thinking</em> about your UI. That’s the very opposite of what you want.</p><p name="5a78" id="5a78" class="graf--p">The solution is to consider adding a button style for when the user has clicked, then another style or animation for when the submission has been made. At the very least, this shows that the user did, indeed, <em class="markup--em markup--p-em">click</em>.</p><figure name="83be" id="83be" class="graf--figure"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 200px;"><div class="aspect-ratio-fill" style="padding-bottom: 28.599999999999998%;"></div><img class="graf-image" data-image-id="1*UFlVP_L5ztX-T3sriUjvIw.gif" data-width="700" data-height="200" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*UFlVP_L5ztX-T3sriUjvIw.gif"></div><figcaption class="imageCaption">Every button in <a target="_blank" href="https://prevue.it/" data-href="https://prevue.it/" class="markup--anchor markup--figure-anchor" rel="nofollow">Prevue</a> has a ‘down’ state, and animation to confirm that your click was understood</figcaption></figure><p name="299b" id="299b" class="graf--p">Better still, if the action is likely going to take a little while — consider actually <em class="markup--em markup--p-em">telling</em> the user what’s happening. If you can’t explain something adequately through design, then there’s no shame in literally spelling it out.</p><figure name="2c8b" id="2c8b" class="graf--figure"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 132px;"><div class="aspect-ratio-fill" style="padding-bottom: 18.9%;"></div><img class="graf-image" data-image-id="1*zn3A_E4OKkCs294tL1qy2A.gif" data-width="700" data-height="132" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*zn3A_E4OKkCs294tL1qy2A.gif"></div></figure><p name="4b81" id="4b81" class="graf--p graf--last">Of course, attention to detail can run deeper than basic styling. A good example is when it comes to uploading images (an action that takes considerable time). In the event where user interaction is predicted to last into the 2+ second range, you might be better off faking success than making your user wait.</p></div></div></section><section name="876a"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="cbc8" id="cbc8" data-align="center" class="graf--h3 graf--first">Use Subtle Animation</h3><p name="eddd" id="eddd" class="graf--p">I could talk for days about the importance of animation, and the role it plays in helping users understand an interface — fortunately there are already plenty of <a target="_blank" href="http://stevenfabre.com/work/making-a-difference-with-animation" data-href="http://stevenfabre.com/work/making-a-difference-with-animation" class="markup--anchor markup--p-anchor" rel="nofollow">better resources</a> out there. Instead, I’ll just touch on the importance of subtle, almost <em class="markup--em markup--p-em">invisible</em> animation.</p><p name="aa0e" id="aa0e" class="graf--p">Take the following as an example; dragging an image to a folder doesn’t <em class="markup--em markup--p-em">require </em>feedback — it just works… but the user doesn’t know that. So a small animation that infers success is all it takes to alleviate uncertainty.</p><figure name="7468" id="7468" class="graf--figure"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 350px;"><div class="aspect-ratio-fill" style="padding-bottom: 50%;"></div><img class="graf-image" data-image-id="1*yEeEh-RfVR2lWbo4id9fxg.gif" data-width="700" data-height="350" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*yEeEh-RfVR2lWbo4id9fxg.gif"></div><figcaption class="imageCaption">Notice how the “X images” number takes slightly longer to update? That’s the actual time it takes for the server to respond. In this case, the “nom” animation helps the user continue about their business</figcaption></figure><p name="a1ca" id="a1ca" class="graf--p">Animation can also help to indicate context, and transition between views. Instead of abruptly moving between states, risking losing the focus of your user, animation can help indicate where things <em class="markup--em markup--p-em">came from.</em></p><figure name="0543" id="0543" class="graf--figure graf--last"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 331px;"><div class="aspect-ratio-fill" style="padding-bottom: 47.3%;"></div><img class="graf-image" data-image-id="1*GWM2hrch2ANwKyXxqoKWeQ.gif" data-width="700" data-height="331" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*GWM2hrch2ANwKyXxqoKWeQ.gif"></div></figure></div></div></section><section name="d124"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="620f" id="620f" data-align="center" class="graf--h3 graf--first">Remember, Things Load</h3><p name="0db8" id="0db8" class="graf--p">I recall reviewing the notes from a user testing session whilst working at Skype — where we had given people a drag-and-drop UI that saved ‘<em class="markup--em markup--p-em">on drop’</em>. It was so well-built, that the action of saving was almost instantaneous, and didn’t even require a loading state.</p><p name="4278" id="4278" class="graf--p">It was <em class="markup--em markup--p-em">so</em> fast, in fact, that users had a total disbelief that their action was successful — ultimately causing more confusion and anxiety than necessary. The solution? Pretending that the product was “thinking”, by adding a loading spinner on event of a drop. Even though it wasn’t.</p><p name="6944" id="6944" class="graf--p">That was a good use-case for a loading spinner. But most of the time, I see designers adding spinners, simply because they <em class="markup--em markup--p-em">can</em>. Most of the time, the user doesn’t need to be told that something is loading at all, and adding a spinning graphic is likely to command more attention than necessary.</p><p name="5c38" id="5c38" class="graf--p">Take the following example — the image, which is dynamically generated (slow) then loaded via AJAX, isn’t the point of the page… the text is. In this case, animation replaces the need for spinners or delays.</p><figure name="b8de" id="b8de" class="graf--figure graf--last"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 326px;"><div class="aspect-ratio-fill" style="padding-bottom: 46.6%;"></div><img class="graf-image" data-image-id="1*Q03nt9FrPYewyLbRbRhFNQ.gif" data-width="700" data-height="326" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*Q03nt9FrPYewyLbRbRhFNQ.gif"></div><figcaption class="imageCaption">Loading a dynamically generated image is costly. So instead of commanding the users’ attention with a spinning graphic, there’s a simple blank slate</figcaption></figure></div></div></section><section name="22f9"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="5123" id="5123" data-align="center" class="graf--h3 graf--first">Optimise for Context</h3><p name="ffa7" id="ffa7" class="graf--p">With any product that contains data, images or reporting — it’s likely that no screen is ever going to look the same. Yet when designing, we optimise for the best-case scenario, and often forget about when there’s no data, lots of data, or somewhere in-between. A good start is to ditch lorem ipsum, stock-quality images or perfectly rounded numbers in designs — and optimise for context instead. What does <em class="markup--em markup--p-em">real </em>data look like?</p><p name="22fc" id="22fc" class="graf--p">By considering the various states of a UI, you can begin to get creative about how to design accordingly. For example, a group of images in Prevue will change configuration depending on how many there are — to make sure that no matter what, the users images always looks nice.</p><figure name="5eaa" id="5eaa" class="graf--figure"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 366px;"><div class="aspect-ratio-fill" style="padding-bottom: 52.300000000000004%;"></div><img class="graf-image" data-image-id="1*e_1CqkbgCHHH3kz64Xh16g.jpeg" data-width="700" data-height="366" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*e_1CqkbgCHHH3kz64Xh16g.jpeg"></div></figure><p name="f0a2" id="f0a2" class="graf--p">Being context-aware isn’t just about looking good, either. Situational context is about identifying when and where extra attention should be paid to seemingly straight-forward, commonplace UI.</p><figure name="7c8a" id="7c8a" class="graf--figure postField--insetLeftImage"><div class="aspectRatioPlaceholder is-locked" style="max-width: 350px; max-height: 168px;"><div class="aspect-ratio-fill" style="padding-bottom: 47.9%;"></div><img class="graf-image" data-image-id="1*iD3cU2jlK6Au31UxL2qKXQ.gif" data-width="357" data-height="171" data-action="zoom" data-action-value="1*iD3cU2jlK6Au31UxL2qKXQ.gif" src="https://d262ilb51hltx0.cloudfront.net/max/800/1*iD3cU2jlK6Au31UxL2qKXQ.gif"></div><figcaption class="imageCaption">A modified version of Stripe’s <a target="_blank" href="https://stripe.com/blog/jquery-payment" data-href="https://stripe.com/blog/jquery-payment" class="markup--anchor markup--figure-anchor" rel="nofollow">Payment plugin</a> using learnings from <a target="_blank" href="http://bradfrost.com/blog/post/single-field-credit-card-input-pattern/" data-href="http://bradfrost.com/blog/post/single-field-credit-card-input-pattern/" class="markup--anchor markup--figure-anchor" rel="nofollow">Brad Frost’s article</a></figcaption></figure><p name="2346" id="2346" class="graf--p">Take credit card forms for example — an area where extra care and attention can help users subconsciously understand what’s required of them, and prevent potential errors.</p><p name="fa21" id="fa21" class="graf--p">They’re also a perfect example of the value of real-life testing — there’s so much anxiety involved in entering secure, financial details that you simply can’t appreciate it until you try for yourself. When building the credit card form for Prevue (<em class="markup--em markup--p-em">above)</em>, I tested several live versions in an attempt to perfect the experience. Every time, my card was actually charged $10 — which was a<strong class="markup--strong markup--p-strong"> </strong>great incentive to get it right.</p><p name="3f24" id="3f24" class="graf--p">Context is key in a situation like this, and even the tiniest details can help users understand what they’re doing. For example:</p><ul class="postList"><li name="554a" id="554a" class="graf--li">Format the numbers in the same way as on the physical card</li><li name="94af" id="94af" class="graf--li">Preventing non-numerical characters, or more numbers than necessary</li><li name="db45" id="db45" class="graf--li">Assuming MM/<strong class="markup--strong markup--li-strong">YYYY</strong> if MM/<strong class="markup--strong markup--li-strong">YY</strong> is entered</li></ul><p name="2b88" id="2b88" class="graf--p graf--last">By considering what content might be displayed, the circumstances in which a task might be undertaken, or the feeling of the user at the time — you’ll be able to balance what <em class="markup--em markup--p-em">looks </em>best with what <em class="markup--em markup--p-em">works</em> best.</p></div></div></section><section name="3c12"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="041a" id="041a" data-align="center" class="graf--h3 graf--first">Respect Native Functionality</h3><p name="49b5" id="49b5" class="graf--p">Your product should respect the functionality of the platform in which it lives — which means it definitely shouldn’t alter native functionality, like ‘hijacking’ your scrollbar, and should ideally complement existing user experience patterns.</p><p name="1e7c" id="1e7c" class="graf--p">For example, some people are used to using keyboard commands to perform common actions. So if your product allows the user to perform a potentially disruptive action (like moving content around, or deleting lots of text) — then you should strongly consider allowing Ctrl+Z functionality to ‘Undo’. The same applies for saving (Ctrl+S), pressing ESC to dismiss a modal window, or “clicking away” to close a dropdown or open menu.</p><p name="fd8a" id="fd8a" class="graf--p">By preventing your user from performing an interaction they’re familiar with — you’re creating an unnecessary <em class="markup--em markup--p-em">pause</em>; a moment of uncertainty for them.</p><p name="2dbe" id="2dbe" class="graf--p">There should also be no <strong class="markup--strong markup--p-strong">wrong way</strong> for a user to perform an action. For example, in both Prevue and <a target="_blank" href="https://www.campaignmonitor.com/email-templates/" data-href="https://www.campaignmonitor.com/email-templates/" class="markup--anchor markup--p-anchor" rel="nofollow">Email Builder</a>, users can upload an image by pressing the “upload” button — but if dragging a handful of images directly into the browser is what someone is used to; both products are built to allow for that too.</p><p name="2eba" id="2eba" class="graf--p graf--last">Building two or three different ways to perform the <em class="markup--em markup--p-em">exact same</em> action seems like unnecessary complexity, especially if you don’t even tell users that functionality exists. But when users are able to use your product how <em class="markup--em markup--p-em">they</em> want; you end up creating a seamless and fluid experience that people feel comfortable using. It’s why iPad’s were designed to emulate the familiar actions of leafing through a magazine’s pages.</p></div></div></section><section name="5b5a"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><h3 name="aafd" id="aafd" data-align="center" class="graf--h3 graf--first">Set the Tone</h3><p name="022d" id="022d" class="graf--p graf--empty"><br></p><p name="55d2" id="55d2" class="graf--p">The final, and arguably easiest detail to implement, is <em class="markup--em markup--p-em">tone of voice</em>. In the midsts of designing tough UI and writing functional documentation — it’s easy to forget that you’re building a product for real people. Forgetting to add a human touch to your copywriting can result in error messages reading as though they’re composed by robots — reminding users that they’re dealing with a faceless machine, right at the moment they need the most guidance. <a target="_blank" href="https://twitter.com/davegreiner/" data-href="https://twitter.com/davegreiner/" class="markup--anchor markup--p-anchor" rel="nofollow">Dave Greiner</a> gave me some good advice about copywriting:</p><blockquote name="a80d" id="a80d" class="graf--blockquote">Read your copy aloud, and imagine you’re talking to your user face-to-face</blockquote><p name="0a15" id="0a15" class="graf--p">It’s great advice for two reasons; firstly because you quickly spot when your message becomes unnecessarily lengthy, impersonal, or even rude. And secondly, because reading your message aloud will inform you when being overtly personal isn’t appropriate for the context either.</p><p name="34c1" id="34c1" class="graf--p">Take the following as an example of the latter — where I got the tone and context completely wrong for an error message:</p><figure name="23d3" id="23d3" class="graf--figure"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 239px;"><div class="aspect-ratio-fill" style="padding-bottom: 34.1%;"></div><img class="graf-image" data-image-id="1*W2hilxGUVLGW6w-MHlMgNQ.png" data-width="700" data-height="239" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*W2hilxGUVLGW6w-MHlMgNQ.png"></div><figcaption class="imageCaption">Not helpful.</figcaption></figure><p name="ea75" id="ea75" class="graf--p">In an attempt to be disarming and <em class="markup--em markup--p-em">human</em>, I wrote the above message to be displayed on the rare occasion when uploads failed due to server error. What I didn’t consider was <strong class="markup--strong markup--p-strong">context</strong>. At a point when the user had waited patiently for their upload to process, the app responded with an unhelpful and unapologetic response. If I was a user on my way to a client presentation, or up against a deadline, this would be less than ideal. This has fortunately been fixed, but not before I received a justifiably angry email from a customer.</p><p name="49ee" id="49ee" class="graf--p">Of course there are also occasions when you <em class="markup--em markup--p-em">can</em> have fun, and where a bit of personality can add value to an otherwise boring user experience. Like on the <a target="_blank" href="https://signup.prevue.it/" data-href="https://signup.prevue.it/" class="markup--anchor markup--p-anchor" rel="nofollow">Prevue signup</a>, where submitting the form without entering any details will return this message:</p><figure name="b084" id="b084" class="graf--figure graf--last"><div class="aspectRatioPlaceholder is-locked" style="max-width: 700px; max-height: 237px;"><div class="aspect-ratio-fill" style="padding-bottom: 33.900000000000006%;"></div><img class="graf-image" data-image-id="1*rUpHwI14OIYuNt9dqUv2NQ.png" data-width="700" data-height="237" src="https://d262ilb51hltx0.cloudfront.net/max/1067/1*rUpHwI14OIYuNt9dqUv2NQ.png"></div><figcaption class="imageCaption">For me, this is preferable to putting an error state on every input</figcaption></figure></div></div></section><section name="c9bc"><div class="section-divider layoutSingleColumn"><hr class="section-divider"></div><div class="section-content"><div class="section-inner layoutSingleColumn"><p name="ac9d" id="ac9d" class="graf--p graf--first">The details are the last 1% of a product. They’re hard to define, they’re impossible to scope, and they’re absolutely no substitute to thorough research, great design and clever engineering. They can, however, be the difference between an <em class="markup--em markup--p-em">average </em>experience and a <em class="markup--em markup--p-em">great </em>one.</p><p name="2292" id="2292" class="graf--p">The details will help your product feel natural, fun, intuitive, and even make your users feel smart. It’s in the small things, that easy-to-forget 1%, where you’ll find the key to making people fall in love your product.</p><p name="20e3" id="20e3" class="graf--p">In the details —<em class="markup--em markup--p-em"> that’s</em> where you’ll find God.</p>