{"id":2552,"date":"2016-08-11T18:03:06","date_gmt":"2016-08-11T17:03:06","guid":{"rendered":"https:\/\/marvel7077.wpengine.com\/?p=2552"},"modified":"2020-08-21T14:08:45","modified_gmt":"2020-08-21T13:08:45","slug":"god-is-in-the-details","status":"publish","type":"post","link":"https:\/\/marvelapp.com\/blog\/god-is-in-the-details\/","title":{"rendered":"“God is in the details”"},"content":{"rendered":"

It applied to Ludwig Mies van der Rohe<\/a> when he was designing buildings in the mid 1900\u2019s, and it remains true in product design today. Though I don\u2019t profess to know much about architecture, another likely commonality with product design is that it\u2019s those same details that are the easiest to forget. But it\u2019s those little things, the tiny minutia of detail, that ultimately make beautiful products, and beautiful houses.<\/p>\n

Unfortunately, when I refer to the \u201cdetails\u201d in product design, I\u2019m not talking about obvious design things; like colours, drop-shadows or placement. Instead I\u2019m 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 \u201cdown\u201d style for a button, or a helpful animation.<\/p>\n

Whatever form that detail takes, I\u2019ll bet that it wasn\u2019t designed in Photoshop, or included in even the most detailed spec document. It\u2019s the details that fall outside of titles like UX, or UI. It\u2019s interaction detail that can only be found after using a product for real, then dedicating solid design and engineering time to building.<\/p>\n

The details are difficult to include when you\u2019re building a product; they\u2019re expensive both in terms of time and technical overhead\u200a\u2014\u200awhich is why they\u2019re rare. I spend my time in pursuit of these details, and as the designer and developer of Prevue<\/a>, I have two luxuries which thankfully afford me the ability to obsess over them:<\/p>\n

The first<\/strong> is that I have the capacity to use, improve and repeat<\/a>. I\u2019m not just talking about about the technical ability to implement the details\u200a\u2014\u200aI\u2019m also talking about having the time to do so. Sometimes an interaction will take me 50% longer to build, simply because I\u2019ve spent hours obsessing about the animated states that occur over a 0.65 second duration. That\u2019s not a luxury that many products can afford, or are willing to build into scope. Understandably so.<\/p>\n

The second<\/strong> is that I use my product, for real, every single day. If there\u2019s an annoying interaction, unnecessarily lengthy animation or a dumb user-flow\u200a\u2014\u200athe chances are pretty high that I\u2019m going to spot it. That\u2019s the difference between functional testing:<\/p>\n

\u201cDoes X do Y when you press Z?\u201d<\/strong><\/em><\/p>\n

Versus true-to-life user-testing:<\/p>\n

\u201cDoes the product intuitively help me achieve a task, quickly, when I\u2019m up against a deadline?\u201d<\/strong><\/em><\/p>\n

But let\u2019s be honest; using a product over-and-over, re-building functionality, and obsessing about the little things takes a lot<\/em> of time\u200a\u2014\u200aperhaps a luxury afforded to side-projects like Prevue, or products with too much money. They\u2019re usually too hard to justify, and they\u2019re definitely the first thing to be sacrificed when push comes to shove. That\u2019s probably why Ludwig Mies van der Rohe only designed a handful of buildings that weren\u2019t ugly skyscrapers\u200a\u2014\u200aor why Prevue doesn\u2019t ship features very often.<\/p>\n

Having spent the last 7 years polishing my own side-project, I\u2019ve learned where to look for \u201cquick wins\u201d 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 \u201cdetail-mining\u201d into your release schedule, I thought I\u2019d 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>\n

Visually Confirm Interactions<\/strong><\/p>\n

I\u2019m going to start with something that applies to most products, yet is so commonly overlooked\u200a\u2014\u200abutton states. Even on a fast internet connection, there\u2019s 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>\n

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\u2019re thinking<\/em> about your UI. That\u2019s the very opposite of what you want.<\/p>\n

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, click<\/em>.<\/p>\n

\"Every<\/a>

Every button in Prevue has a \u2018down\u2019 state, and animation to confirm that your click was understood<\/p><\/div>\n

Better still, if the action is likely going to take a little while\u200a\u2014\u200aconsider actually telling<\/em> the user what\u2019s happening. If you can\u2019t explain something adequately through design, then there\u2019s no shame in literally spelling it out.<\/p>\n

\"Click<\/a><\/p>\n

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>\n

Use Subtle Animation<\/strong><\/p>\n

I could talk for days about the importance of animation, and the role it plays in helping users understand an interface\u200a\u2014\u200afortunately there are already plenty of better resources out there. Instead, I\u2019ll just touch on the importance of subtle, almost invisible<\/em> animation.<\/p>\n

Take the following as an example; dragging an image to a folder doesn\u2019t require<\/em> feedback\u200a\u2014\u200ait just works\u2026 but the user doesn\u2019t know that. So a small animation that infers success is all it takes to alleviate uncertainty.<\/p>\n

\"Animation<\/a>

Notice how the \u201cX images\u201d number takes slightly longer to update? That\u2019s the actual time it takes for the server to respond. In this case, the \u201cnom\u201d animation helps the user continue about their business<\/p><\/div>\n

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 came<\/em> from.<\/p>\n

\"Transition<\/a><\/p>\n

Remember, Things Load<\/strong><\/p>\n

I recall reviewing the notes from a user testing session whilst working at Skype\u200a\u2014\u200awhere we had given people a drag-and-drop UI that saved \u2018on drop\u2019<\/em>. It was so well-built, that the action of saving was almost instantaneous, and didn\u2019t even require a loading state.<\/p>\n

It was so<\/em> fast, in fact, that users had a total disbelief that their action was successful\u200a\u2014\u200aultimately causing more confusion and anxiety than necessary. The solution? Pretending that the product was \u201cthinking\u201d, by adding a loading spinner on event of a drop. Even though it wasn\u2019t.<\/p>\n

That was a good use-case for a loading spinner. But most of the time, I see designers adding spinners, simply because they can<\/em>. Most of the time, the user doesn\u2019t need to be told that something is loading at all, and adding a spinning graphic is likely to command more attention than necessary.<\/p>\n

Take the following example\u200a\u2014\u200athe image, which is dynamically generated (slow) then loaded via AJAX, isn\u2019t the point of the page\u2026 the text is. In this case, animation replaces the need for spinners or delays.<\/p>\n

\"Blank<\/a>

Loading a dynamically generated image is costly. So instead of commanding the users\u2019 attention with a spinning graphic, there\u2019s a simple blank slate<\/p><\/div>\n

Optimise for Context<\/strong><\/p>\n

With any product that contains data, images or reporting\u200a\u2014\u200ait\u2019s 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\u2019s 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\u200a\u2014\u200aand optimise for context instead. What does real<\/em> data look like?<\/p>\n

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\u200a\u2014\u200ato make sure that no matter what, the users images always looks nice.<\/p>\n

<\/div>
<\/svg><\/div>

\"By considering the various states of a UI, you can begin to get creative about how to design accordingly.\"<\/p><\/span><\/blockquote>\n

\"Image<\/a><\/p>\n

Being context-aware isn\u2019t 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>\n

Take credit card forms for example\u200a\u2014\u200aan area where extra care and attention can help users subconsciously understand what\u2019s required of them, and prevent potential errors.<\/p>\n

\"Credit<\/a>

A modified version of Stripe\u2019s Payment plugin using learnings from Brad Frost\u2019s article<\/p><\/div>\n

They\u2019re also a perfect example of the value of real-life testing\u200a\u2014\u200athere\u2019s so much anxiety involved in entering secure, financial details that you simply can\u2019t appreciate it until you try for yourself. When building the credit card form for Prevue (above<\/em>), I tested several live versions in an attempt to perfect the experience. Every time, my card was actually charged $10\u200a\u2014\u200awhich was a great incentive to get it right.<\/p>\n

Context is key in a situation like this, and even the tiniest details can help users understand what they\u2019re doing. For example:<\/p>\n