Web Development Network  |  Sites:    Capital Tutorials    Internet Marketing Books    Arcade Games
Depiction- Webmaster Resources
Stock Image


Contributors: SSD VPS in Europe  |  SEO Las Vegas |  EsqRank

Dental SEO Marketing  |  Best Las Vegas SEO Company  |  Currency Converter Live

Misc Links: Submit Tutorials (Earn $$) l Advertising l Privacy Policy | Site Map

RSS News Feeds



A List Apart: The Full Feed

Articles for people who make web sites.

This is the most recent feed available as of 09/28/2016 at 06:10 PM

Task Performance Indicator: A Management Metric for Customer Experience

It’s hard to quantify the customer experience. “Simpler and faster for users” is a tough sell when the value of our work doesn’t make sense to management. We have to prove we’re delivering real value—increased the success rate, or reduced time-on-task, for example—to get their attention. Management understands metrics that link with other organizational metrics, such as lost revenue, support calls, or repeat visits. So, we need to describe our environment with metrics of our own.

For the team I work with, that meant developing a remote testing method that would measure the impact of changes on customer experience—assessing alterations to an app or website in relation to a defined set of customer “top tasks.” The resulting metric is stable, reliable, and repeatable over time. We call it the Task Performance Indicator (TPI).

For example, if a task has a TPI score of 40 (out of 100), it has major issues. If you measure again in 6 months’ time but nothing has been done to address the issues, the testing score will again result in a TPI of 40.

In traditional usability testing, it has long been established that if you test with between three and eight people, you’ll find out if significant problems exist. Unfortunately, that’s not enough to reveal precise success rates or time-on-task measurements. What we’ve discovered from hundreds of tests over many years is that reliable and stable patterns aren’t apparent until you’re testing with between 13 and 18 people. Why is that?

When the number of participants ranges anywhere from 13–18 people, testing results begin to stabilize and you’re left with a reliable baseline TPI metric.

The following chart shows why we can do this (Fig. 1).

A graph showing how TPI scores essentially leveled out upon as more participants were included.
Fig 1: TPI scores start to level out and stabilize as more participants are tested.

How TPI scores are calculated

We’ve spent years developing a single score that we believe is a true reflection of the customer experience when completing a task.

For each task, we present the user with a “task question” via live chat. Once they understand what they have to do, the user indicates that they are starting the task. At the end of the task, they must provide an answer to the question. We then ask people how confident they are in their answer.

A number of factors affect the resulting TPI score.

Time: We establish what we call the “Target Time”—how long it should take to complete the task under best practice conditions. The more they exceed the target time, the more it affects the TPI.

Time out: The person takes longer than the maximum time allocated. We set it at 5 minutes.

Confidence: At the end of each task, people are asked how confident they are. For example, low confidence in a correct answer would have a slight negative impact on the TPI score.

Minor wrong: The person is unsure; their answer is almost correct.

Disaster: The person has high confidence, but the wrong result; acting on this wrong answer could have serious consequences.

Gives up: The person gives up on the task.

A TPI of 100 means that the user has successfully completed the task within the agreed target times.

In the following chart, the TPI score is 61 (Fig. 2).

A pie chart illustrating sample results for Overall Task Performance, and a vertical bar showing Mean Completion Times in comparison with Mean Target Times.
Fig 2: A visual breakdown of sample results for Overall Task Performance, Mean Completion Times, and Mean Target Times.

Developing task questions

Questions are the greatest source of potential noise in TPI testing. If a question is not worded correctly, it will invalidate the results. To get an overall TPI for a particular website or app, we typically test 10-12 task questions. In choosing a question, keep in mind the following:

Based on customer top tasks. You must choose task questions that are examples of top tasks. If you measure and then seek to improve the performance of tiny tasks (low demand tasks) you may be contributing to a decline in the overall customer experience.

Repeatable. Create task questions that you can test again in 6 to 12 months.

Representative and typical. Don’t make the task questions particularly difficult. Start off with reasonably basic, typical questions.

Universal, everyone can do it. Every one of your test participants must be able to do each task. If you’re going to be testing a mixture of technical, marketing, and sales people, don’t choose a task question that only a salesperson can do.

One task, one unique answer. Limit each task question to only one actual thing you want people to do, and one unique answer.

Does not contain clues. The participant will examine the task question like Sherlock Holmes would hunt for a clue. Make sure it doesn’t contain any obvious keywords that could be answered by conducting a search.

Short—30 words or less. Remember, the participant is seeing each task question for the first time, so aim to keep its length at less than 20 words (and definitely less than 30).

No change within testing period. Choose questions where the website or app is not likely to change during the testing period. Otherwise, you’re not going to be testing like with like.

Case Study: Task questions for OECD

Let’s look at some top tasks for the customers of Organisation for Economic Co-operation and Development (OECD), an economic and policy advice organization.

  1. Access and submit country surveys, reviews, and reports.
  2. Compare country statistical data.
  3. Retrieve statistics on a particular topic.
  4. Browse a publication online for free.
  5. Access, submit, and review working papers.

Based on that list, these task questions were developed:

  1. What are OECD’s latest recommendations regarding Japan’s healthcare system?
  2. In 2008, was Vietnam on the list of countries that received official development assistance?
  3. Did more males per capita die of heart attacks in Canada than in France in 2004?
  4. What is the latest average starting salary, in US dollars, of a primary school teacher across OECD countries?
  5. What is the title of Box 1.2 on page 73 of OECD Employment Outlook 2009?
  6. Find the title of the latest working paper about improvements to New Zealand’s tax system.

Running the test

To test 10-12 task questions usually takes about one hour, and you’ll need between 13 and 18 participants (we average 15). Make sure that they’re representative of your typical customers. 

We’ve found that remote testing is better, faster, and cheaper than traditional lab-based measurement for TPI testing. With remote testing, people are more likely to behave in a natural way because they are in their normal environment—at home or in the office—and using their own computer. That makes it much easier for someone to give you an hour of their time, rather than spend the morning at your lab. And since the cost is much lower than lab-based tests, we can set them up more quickly and more often. It’s even convenient to schedule them using Webex, GoToMeeting, Skype, etc.

The key to a successful test is that you are confident, calm, and quiet. You’re there to facilitate the test—not to guide it or give opinions. Aim to become as invisible as possible.

Prior to beginning the test, introduce yourself and make sure the participant gives you permission to record the session. Next, ask that they share their screen. Remember to stress that you are only testing the website or app—not them. Ask them to go to an agreed start point where all the tasks will originate. (We typically choose the homepage for the site/app, or a blank tab in the browser.)

Explain that for each task, you will paste a question into the chat box found on their screen. Test the chat box to confirm that the participant can read it, and tell them that you will also read the task aloud a couple of times. Once they understand what they have to do, ask them to indicate when they start the task, and that they must give an answer once they’ve finished. After they’ve completed the task, ask the participant how confident they are in their answer.

Analyzing the results

As you observe the tests, you’re looking for patterns. In particular, look for the major reasons people give for selecting the wrong answer or exceeding the target time.

Video recordings of your customers as they try—and often fail—to complete their tasks have powerful potential. They are the raw material of empathy. When we identify a major problem area during a particular test, we compile a video containing three to six participants who were affected. For each participant, we select less than a minute’s worth of video showing them while affected by this problem. We then edit these participant snippets into a combined video (that we try to keep under three minutes). We then get as many stakeholders as possible to watch it. You should seek to distribute these videos as widely, and as often as possible.

How Cisco uses the Task Performance Indicator

Every six months or so, we measure several tasks for Cisco, including the following:

Task: Download the latest firmware for the RV042 router.

The top task of Cisco customers is downloading software. When we started the Task Performance Indicator for software downloads in 2010, a typical customer might take 15 steps and more than 300 seconds to download a piece of software. It was a very frustrating and annoying experience. The Cisco team implemented a continuous improvement process based on the TPI results. Every six months, the Task Performance Indicator was carried out again to see what had been improved and what still needed fixing. By 2012—for a significant percentage of software—the number of steps to download software had been reduced from 15 to 4, and the time on task had dropped from 300 seconds to 40 seconds. Customers were getting a much faster and better experience.

According to Bill Skeet, Senior Manager of Customer Experience for Cisco Digital Support, implementing the TPI has had a dramatic impact on how people think about their jobs:

We now track the score of each task and set goals for each task. We have assigned tasks and goals to product managers to make sure we have a person responsible for managing the quality of the experience ... Decisions in the past were driven primarily by what customers said and not what they did. Of course, that sometimes didn’t yield great results because what users say and what they do can be quite different.

Troubleshooting and bug fixing are also top tasks for Cisco customers. Since 2012, we’ve tested the following.

Task: Ports 2 and 3 on your ASR 9001 router, running v4.3.0 software, intermittently stop functioning for no apparent reason. Find the Cisco recommended fix or workaround for this issue.

Combination of pie charts and browser screenshots, depicting progression of change to the Bug Task Success Rate from February 2012 through December 2014.
Fig 3: Bug Task Success Rate Comparisons, February 2012 through December 2014.

For a variety of reasons, it was difficult to solve the underlying problems connected with finding the right bug fix information on the Cisco website. Thus, the scores from February 2012 to February 2013 did not improve in any significant way.

For the May 2013 measurement, the team ran a pilot to show how (with the proper investment) it could be much easier to find bug fix information. As we can see in the preceding image, the success rate jumped. However, it was only a pilot and by the next measurement it had been removed and the score dropped again. The evidence was there, though, and the team soon obtained resources to work on a permanent fix. The initial implementation was for the July 2014 measurement, where we see a significant improvement. More refinements were made, then we see a major turnaround by December 2014.

Task: Create a new guest account to access the Cisco.com website and log in with this new account.

Graph depicting Success/Failure rates from March 2015 through June 2015
Fig 4: Success/Failure rates from March 2015 through June 2015

This task was initially measured in 2014; the results were not good.

In fact, nobody succeeded in completing the task during the March 2014 measurements, resulting in three specific design improvements to the sign-up form. These involved:

  1. Clearly labelling mandatory fields
  2. Improving password guidance
  3. Eliminating address mismatch errors.

A shorter pilot form was also launched as a proof of concept. Success jumped by 50% in the July 2014 measurements, but dropped 21% by December 2014 because the pilot form was no longer there. By June 2015, a shorter, simpler form was fully implemented, and the success again reached 50%.

The team was able to show that because of their work:

  • The three design improvements improved the success rate by 29%.
  • The shorter form improved the success rate by 21%.

That’s very powerful. You can isolate a piece of work and link it to a specific increase in the TPI. You can start predicting that if a company invests X it will get a Y TPI increase. This is control and the route to power and respect within your organization, or to trust and credibility with your client.

If you can link it with other key performance indicators, that’s even more powerful.

The following table shows that improvements to the registration form halved the support requests connected with guest account registration (Fig. 5).

Bar chart illustrating registration support request numbers for Q1 2014 (1,500), Q2 2015 (679), and Q3 2015 (689).
Fig 5: Registration Support Requests, Q1 2014, Q2 2015, and Q3 2015.

A more simplified guest registration process resulted in:

  • A reduction in support requests—from 1,500 a quarter, to less than 700
  • Three fewer people were required to support customer registration
  • 80% productivity improvement
  • Registration time down to 2 minutes from 3:25.

Task: Pretend you have forgotten the password for the Cisco account and take whatever actions are required to log in.

When we measured the change passwords task, we found that there was a 37% failure rate.

A process of improvement was undertaken, as can be seen by the following chart, and by December 2013, we had a 100% success rate (Fig. 6).

Four pie charts illustration the progression of improvement in success rate from November 2012 (63%), May 2013 (77%), August 2013 (88%), and December 2013 (100%).
Fig 6: Progression of success rate improvement from November 2012 to December 2013.

100% success rate is a fantastic result. Job done, right? Wrong. In digital, the job is never done. It is always an evolving environment. You must keep measuring the top tasks because the digital environment that they exist within is constantly changing. Stuff is getting added, stuff is getting removed, and stuff just breaks (Fig. 7).

Two pie charts, one reporting a success rate of 41% for March 2014 and the other a 100% success rate for July 2014.
Fig 7: Comparison of success rates, March 2014 and July 2014.

When we measured again in March 2014, the success rate had dropped to 59% because of a technical glitch. It was quickly dealt with, so the rate shot back up to 100% by July.

At every step of the way, the TPI gave us evidence about how well we were doing our job. It’s really helped us fight against some of the “bright shiny object” disease and the tendency for everyone to have an opinion on what we put on our webpages ... because we have data to back it up. It gave us more insight into how content organization played a role in our work for Cisco, something that Jeanne Quinn (senior manager responsible for the Cisco Partner) told us kept things clear and simple while working with the client.

The TPI allows you to express the value of your work in ways that makes sense to management. If it makes sense to management—and if you can prove you’re delivering value—then you get more resources and more respect.



Why We Should All Be Data Literate

Recently, I was lucky enough to see the great Jared Spool talk (spoiler: all Spool talks are great Spool talks). In this instance, the user interface icon warned of the perils of blindly letting data drive design.

I am in total agreement with 90 percent of his premise. Collecting and analyzing quantitative data can indeed inform your design decisions, and smart use of metrics can fix critical issues or simply improve the user experience. However, this doesn’t preclude a serious problem with data, or more specifically, with data users. Spool makes this clear: When you don’t understand what data can and can’t tell you and your work is being dictated by decisions based on that lack of understanding—well, your work and product might end up being rubbish. (Who hasn’t heard a manager fixate on some arbitrary metric, such as, “Jane, increase time on page” or “Get the bounce rate down, whatever it takes”?) Designing to blindly satisfy a number almost always leads to a poorer experience, a poorer product, and ultimately the company getting poorer.

Where Spool and I disagree is in his conclusion that all design teams need to include a data scientist. Or, better yet, that all designers should become data scientists. In a perfect world, that would be terrific. In the less-perfect world that most of us inhabit, I feel there’s a more viable way. Simply put: all designers can and should learn to be data literate. Come to think of it, it’d be nice if all citizens learned to be data literate, but that’s a different think piece.

For now, let’s walk through what data literacy is, how to go about getting it for less effort and cost than a certificate from Trump University, and how we can all build some healthy data habits that will serve our designs for the better.

What Data Literacy Is and Isn’t

Okay, data literacy is a broad term—unlike, say, “design.” In the education field, researchers juggle the terms “quantitative literacy,” “mathematical literacy,” and “quantitative reasoning,” but parsing out fine differences is beyond the scope of this article and, probably, your patience. To keep it simple, let’s think about data literacy as healthy skepticism or even bullshit detection. It’s the kind of skepticism you might adopt when faced with statements from politicians or advertisers. If a cookie box is splashed with a “20% more tasty!” banner, your rightful reaction might be “tastier than what, exactly, and who says?” Yes. Remember that response.

Data literacy does require—sorry, phobics—some math. But it’s not so bad. As a designer, you already use math: figuring pixels, or calculating the square footage of a space, or converting ems to percent and back. The basics of what you already do should give you a good handle on concepts like percentages, probability, scale, and change over time, all of which sometimes can hide the real meaning of a statistic or data set. But if you keep asking questions and know how multiplication and division work, you’ll be 92 percent of the way there. (If you’re wondering where I got that percentage from, well—I made it up. Congratulations, you’re already on the road to data literacy.)

Neil Lutsky writes about data literacy in terms of the “construction, communication, and evaluation of arguments.” Why is this relevant to you as a designer? As Spool notes, many design decisions are increasingly driven by data. Data literacy enables you to evaluate the arguments presented by managers, clients, and even analytics packages, as well as craft your own arguments. (After all, a key part of design is being able to explain why you made specific design decisions.) If someone emails you a spreadsheet and says, “These numbers say why this design has to be 5 percent more blue,” you need to be able to check the data and evaluate whether this is a good decision or just plain bonkers.

Yes, this is part of the job.

It’s So Easy

Look, journalists can get pretty good at being data literate. Not all journalists, of course, but there’s a high correlation between the ability to question data and the quality of the journalism—and it’s not high-level or arcane learning. One Poynter Institute data course was even taught (in slightly modified form) to grade schoolers. You’re a smart cookie, so you can do this. Not to mention the fact that data courses are often self-directed, online, and free (see “Resources” listed below).

Unlike data scientists who face complex questions, large data sets, and need to master concepts like regressions and Fourier transforms, you’re probably going to deal with less complex data. If you regularly need to map out complex edge-node relationships in a huge social graph or tackle big data, then yes, get that master’s degree in the subject or consult a pro. But if you’re up against Google Analytics? You can easily learn how to ask questions and look for answers. Seriously, ask questions and look for answers.

Designers need to be better at data literacy for many of the same reasons we need to work on technical literacy, as Sarah Doody explains. We need to understand what developers can and can’t do, and we need to understand what the data can and can’t do. For example, an A/B test of two different designs can tell you one thing about one thing, but if you don’t understand how data works, you probably didn’t set up the experiment conditions in a way that leads to informative results. (Pro tip: if you want to see how a change affects click-through, don’t test two designs where multiple items differ, and don’t expect the numbers to tell you why that happened.) Again: We need to question the data.

So we’ve defined a need, researched our users, and identified and defined a feature called data literacy. What remains is prototyping. Let’s get into it, shall we?

How to Build Data Literacy by Building Habits

Teaching data literacy is an ongoing topic of academic research and debate, so I’ll leave comprehensive course-building to more capable hands than mine. But together, we can cheaply and easily outline simple habits of critical thought and mathematical practice, and this will get us to, let’s say, 89 percent data literacy. At the least, you’ll be better able to evaluate which data could make your work better, which data should be questioned more thoroughly, and how to talk to metric-happy stakeholders or bosses. (Optional homework: this week, take one metric you track or have been told to track at work, walk through the habits below, and report back.)

Habit one: Check source and context

This is the least you should do when presented with a metric as a fait accompli, whether that metric is from a single study, a politician, or an analytics package.

First, ask about the source of the data (in journalism, this is reflex—“Did the study about the health benefits of smoking come from the National Tobacco Profiteering Association?”). Knowing the source, you can then investigate the second question.

The second question concerns how the data was collected, and what that can tell you—and what it can’t.  Let’s say your boss comes in with some numbers about time-on-page, saying “Some pages are more sticky than others. Let’s redesign the others to keep customers on all the other pages longer.” Should you jump to redesign the less-sticky pages, or is there a different problem at play?

It’s simple, and not undermining, to ask how time-on-page was measured and what it means. It could mean a number of things, things that that single metric will never reveal. Things that could be real problems, real advantages, or a combination of the two. Maybe the pages with higher time-on-page numbers simply took a lot longer to load, so potential customers were sitting there as a complex script or crappy CDN was slooooowly drawing things on the not-a-customer-any-more’s screen. Or it could mean some pages had more content. Or it could mean some were designed poorly and users had to figure out what to do next.

How can you find this out? How can you communicate that it’s important to find out? A quick talk with the dev team or running a few observations with real users could lead you to discover what the real problem is and how you can redesign to improve your product.

What you find out could be the difference between good and bad design. And that comes from knowing how a metric is measured, and what it doesn’t measure. The metric itself won’t tell you.

For your third question, ask the size of the sample. See how many users were hitting that site, whether the time-on-page stat was measured for all or some of these users, and whether that’s representative of the usual load. Your design fix could go in different directions depending on the answer. Maybe the metric was from just one user! This is a thing that sometimes happens.

Fourth, think and talk about context. Does this metric depend on something else? For example, might this metric change over time? Then you have to ask over what time period the metric was measured, if that period is sufficient, and whether the time of year when measured might make a difference.

Remember when I said change over time can be a red flag? Let’s say your boss is in a panic, perusing a chart that shows sales from one product page dropping precipitously last month. Design mandates flood your inbox: “We’ve got to promote this item more! Add some eye-catching design, promote it on our home page!”

What can you do to make the right design decisions? Pick a brighter blue for a starburst graphic on that product page?

Maybe it would be more useful to look at a calendar. Could the drop relate to something seasonal that should be expected? Jack o’lantern sales do tend to drop after November 1. Was there relevant news? Apple’s sales always drop before their annual events, as people expect new products to be announced. A plethora of common-sense questions could be asked.

The other key point about data literacy and change is that being data literate can immunize against common errors when looking at change over time. This gets to numeracy.

Habit two: Be numerate

I first learned about numeracy through John Allen Paulos’ book Innumeracy: Mathematical Illiteracy and its Consequences, though the term “innumeracy” was originated by Pulitzer Prize-winning scientist Douglas Hofstadter. Innumeracy is a parallel to illiteracy; it means the inability to reason with numbers. That is, the innumerate can do math but are more likely to trip up when mathematical reasoning is critical. This often happens when dealing with probability and coincidence, with statistics, and with things like percentages, averages, and changes. It’s not just you—these can be hard to sort out sort out! We’re presented with these metrics a lot, but usually given little time to think about them, so brushing up on that bit of math can really help put out (or avoid) a trash fire of bad design decisions.

Consider this:  A founder comes in with the news that an app has doubled its market base in the two weeks it’s been available. It’s literally gone up 100 percent in that time. That’s pretty awesome, right? Time to break out the bubbly, right? But what if you asked a few questions and found that this really meant the founder was the first user, then eventually her mom got onto it. That is literally doubling the user base exactly 100 percent.

Of course that’s obvious and simple. You see right off why this startup probably shouldn’t make the capital outlay to acquire a bottle or two juuuust yet. But exactly this kind of error gets overlooked easily and often when the math gets a bit more complex.

Any time you see a percentage, such as “23% more” or “we lost 17%,” don’t act until you’ve put on your math hat. You don’t even need to assume malice; this stuff simply gets confusing fast, and it’s part of your job not to misread the data and then make design decisions based on an erroneous understanding.

Here’s an example from Nicolas Kayser-Bril, who looks into the headline, “Risk of Multiple Sclerosis Doubles When Working at Night”:

“Take 1,000 Germans. A single one will develop MS over his lifetime. Now, if every one of these 1,000 Germans worked night shifts, the number of MS sufferers would jump to two. The additional risk of developing MS when working in shifts is one in 1,000, not 100%. Surely this information is more useful when pondering whether to take the job.”

This is a known issue in science journalism that isn’t discussed enough, and often leads to misleading headlines. Whenever there’s a number suggesting something that affects people, or a number suggesting change, look not just at the percentage but at what this would mean in the real world; do the math and see if the result matches the headline’s intimation. Also ask how the percentage was calculated. How was the sausage made? Lynn Arthur Steen explains how percentages presented to you may not just be the difference of two numbers divided by a number. Base lesson: always learn what your analytics application measures and how it calculates things. Four out of five dentists agree...so that’s, what, 80 percent true?

Averages are another potentially deceptive metric that simple math can help; sometimes it’s barely relevant, if at all. “The average length of a book purchased on Amazon is 234.23 pages” may not actually tell you anything. Sometimes you need to look into what’s being averaged. Given the example “One in every 15 Europeans is illiterate,” Kayser-Bril points out that maybe close to one in 15 Europeans is under the age of seven. It’s good advice to learn the terms “mode,” “median,” and “standard deviation.” (It doesn’t hurt (much), and can make you a more interesting conversationalist at dinner parties!)

Habit three: Check your biases

I know, that sounds horrible. But in this context, we’re talking about cognitive biases, which everyone has (this is why I encourage designers to study psychology, cognition studies, and sociology as much as they can). Though we have biases, it’s how aware we are of these issues and how we deal with them that counts.

It’s out of scope to list and describe them all (just thinking I know them all is probably an example of Dunning-Kruger). We’ll focus on two that are most immediately relevant when you’re handed supposedly-objective metrics and told to design to them. At least, these are two that I most often see, but that may be selection bias.

Selection bias

Any metric or statistical analysis is only as good as (in part) what you choose to measure. Selection bias is when your choice of what to measure isn’t really random or representative. This can come from a conscious attempt to skew the result, from carelessly overlooking context, or due to some hidden process.

One example might be if you’re trying to determine the average height of the adult male in the United States and find it to be 6'4"—oops, we only collected the heights of basketball players. Online opinion polls are basically embodied examples of selection bias, as the readers of a partisan site are there because they already share the site operator’s opinion. Or you may be given a survey that shows 95 percent of users of your startup’s app say they love it, but when you dig in to the numbers, the people surveyed were all grandmothers of the startup team employees (“Oh, you made this, dear? I love it!”). This holds in usability testing, too: if you only select, say, high-level programmers, you may be convinced that a “to install this app, recompile your OS kernel” is a totally usable feature. Or end up with Pied Piper’s UI.

Now, these all seem like “sure, obvs” examples. But selection bias can show up in much more subtle forms, and in things like clinical studies. Dr. Madhukar Pai’s slides here give some great examples — especially check out Slide 47, which shows how telephone surveys have almost built-in selection biases.

So, what’s a designer to do? As you can see from Dr. Pai’s lecture slides, you can quickly get into some pretty “mathy” work, but the main point is that when you’re faced with a metric, after you’ve checked out the context, look at the sample. You can think about the claim on the cookie box in this way. It’s “20% more tasty”?  What was the sample, 19 servings of chopped liver and one cookie?

Confirmation bias

Storytelling is a powerful tool. Again, it’s how our brains are wired. But as with all tools, it can be used for good or for evil, and can be intentional or accidental. As designers, we’re told we have to be storytellers: how do people act, how do they meet-cute our product, how do they feel, what’s the character arc? This is how we build our knowledge of the world, by building stories about it. But, as Alberto Cairo explains in The Truthful Art this is closely linked to confirmation bias, where we unconsciously (or consciously) search for, select, shape, remember, interpret, or otherwise torture basic information so that it matches what we already think we know, the stories we have. We want to believe.

Confirmation bias can drive selection bias, certainly. If you only test your design with users who already know how your product works (say, power users, stakeholders, and the people who built the product), you will get distorted numbers and a distorted sense of how usable your product is. Don’t laugh: I know of a very large and popular internet company that only does user re-search with power users and stakeholders.

But even if the discovery process is clean, confirmation bias can screw up the interpretation. As Cairo writes, “Even if we are presented with information that renders our beliefs worthless, we’ll try to avoid looking at it, or we’ll twist it in a way that confirms them. We humans try to reduce dissonance no matter what.” What could this mean for your design practice? What could this mean for your designs when stakeholders want you to design to specific data?

Reading (Numbers) is Fundamental

So, yes. If you can work with a data scientist in your design team, definitely do so. Try to work with her and learn alongside her. But if you don’t have this luxury, or the luxury of studying statistics in depth, think of data literacy as a vital part of your design practice. Mike Monteiro is passionate that designers need to know math, and he’s of course correct, but we don’t need to know math just to calculate visual design. We need to know math enough to know how to question and analyze any metric we’re given.

This is something you can practice in everyday life, especially in an election season. When you see someone citing a study, or quoting a number, ask: What was measured? How was it measured? What was the context? What wasn’t measured? Does that work out in real life? Keep looking up terms like selection bias, confirmation bias, Dunning-Kruger, sample size effect, until you remember them and their application. That is how you build habits, and how you’ll build your data literacy muscles.

I’ve long loved the Richard Feynman quote (that Cairo cites in The Truthful Art): “The first principle is that you must not fool yourself — and you are the easiest person to fool.” Consider always that you might be fooling yourself by blindly accepting any metric handed to you. And remember, the second-easiest person to fool is the person who likely handed you the metric, and is motivated to believe a particular outcome. Data literacy requires honesty, mastering numeracy, and stepping through the habits we’ve discussed. Practice every day with news from politics: does a statistic in the news give you that “of course, that’s how things are” feeling? Take a deep breath, and dig in; do you agree with a policy or action because it’s your political party proposing it? What’s the context, the sample size, the bias?

It’s tough to query yourself this way. But that’s the job. It’s tougher to query someone else this way, whether it’s your boss or your significant other. I can’t help you figure out the politics and social minefield of those. But do try. The quality of your work (and life) may depend on it.

Resources



This week's sponsor: OPTIMAL WORKSHOP

OPTIMAL WORKSHOP — test your website‘s performance with fast and powerful UX research tools.​



Designing Interface Animation: an Interview with Val Head

A note from the editors: To mark the publication of Designing Interface Animation, ALA managing editor Mica McPheeters and editor Caren Litherland reached out to Val Head via Google Hangouts and email for a freewheeling conversation about web animation. The following interview has been edited for clarity and brevity.

Animation is not new, of course, but its journey on the web has been rocky. For years, technological limitations compelled us to take sides: Should we design rich, captivating sites in Flash? Or should we build static, standards-compliant sites with HTML and CSS (and maybe a little JavaScript)?

Author Val Head describes herself as a “weirdo” who never wanted to choose between those two extremes—and, thanks to the tools at our disposal today, we no longer have to. Without compromising standards, we can now create complex animations natively in the browser: from subtle transitions using CSS to immersive, 3-D worlds with WebGL. Animation today is not just on the web, but of the web. And that, says Val, is a very big deal.

Caren Litherland: Are people intimidated by animation?

Val Head: There are definitely some web folks out there who are intimidated by the idea of using web animation in their work. For some, it’s such a new thing—very few of us have a formal background in motion design or animation—and it can be tough to know where to start or how to use it. I’ve noticed there’s some hesitation to embrace web animation due to the “skip intro” era of Flash sites. There seems to be a fear of recreating past mistakes. But it doesn’t have to be that way at all.

We’re in a new era of web animation right now. The fact that we can create animation with the same technologies we’ve always used to make websites—things like CSS and JavaScript—completely changes the landscape. Now that we can make animation that is properly “of the web” (to borrow a phrase from Jeremy Keith), not just tacked on top with a plug-in, we get to define what the new definition of web animation is with our work.

Right now, on the web, we can create beautiful, purposeful animation that is also accessible, progressively enhanced, and performant. No other medium can do that. Which is really exciting!

CL: I’ve always felt that there was something kind of ahistorical and ahistoricizing about the early web. As the web has matured, it seems to have taken a greater interest in the history and traditions that inform it. Web typography is a good example of this increased self-awareness. Can the same be said for animation?

VH: I think so! In the early days of the web, designers often looked down on it as a less capable medium. Before web type was a thing, a number of my designer friends would say that they could never design for the web because it wasn’t expressive enough as a medium. That the web couldn’t really do design. Then the web matured, web type came along, and that drastically changed how we designed for the web. Web animation is doing much the same thing. It’s another way we have now to be expressive with our design choices, to tell stories, to affect the experience in meaningful ways, and to make our sites unique.

With type, we turned to the long-standing craft of print typography for some direction and ideas, but the more we work with type on the web, the more web typography becomes its own thing. The same is true of web animation. We can look to things like the 12 classic principles of animation for reference, but we’re still defining exactly what web animation will be and the tools and technologies we use for it. Web animation adds another dimension to how we can design on the web and another avenue for reflecting on what the rich histories of design, animation, and film can teach us.

Mica McPheeters: Do you find that animation often gets tacked on at the end of projects? Why is that? Shouldn’t it be incorporated from the outset?

VH: Yes, it often does get left to the end of projects and almost treated as just the icing on top. That’s a big part of what can make animation seem like it’s too hard or ineffective. If you leave any thought of animation until the very end of a project, it’s pretty much doomed to fail or just be meaningless decoration.

Web animation can be so much more than just decoration, but only if we make it part of our design process. It can’t be a meaningful addition to the user experience if you don’t include it in the early conversations that define that experience.

Good web animation takes a whole team. You need input from all disciplines touching the design to make it work well. It can’t just be designed in a vacuum and tossed over the fence. That approach fails spectacularly well when it comes to animation.

Communicating animation ideas and making animation truly part of the process can be the biggest hurdle for teams to embrace animation. Change is hard! That’s why I dedicated two entire chapters of the book to how to get animation done in the real world. I focus on how to communicate animation ideas to teammates and stakeholders, as well as how to prototype those ideas efficiently so you can get to solutions without wasting time. I also cover how to represent animation in your design systems or documentation to empower everyone (no matter what their background is) to make good motion design decisions.

CL: Can you say more about the importance of a motion audit? Can it be carried out in tandem with a content audit? And how do content and animation tie in with each other?

VH: I find motion audits to be incredibly useful before creating a motion style guide or before embarking on new design efforts. It’s so helpful to know where animation is already being used, and to take an objective look at how effective it is both from a UX angle and a branding angle. If you have a team of any significant size, chances are you’ve probably got a lot of redundant, and maybe even conflicting, styles and uses of animation in your site. Motion audits give you a chance to see what you’re already doing, identify things that are working, as well as things that might be broken or just need a little work. They’re also a great way to identify places where animation could provide value but isn’t being used yet.

Looking at all your animation efforts at a high level gives you a chance to consolidate the design decisions behind them, and establish a cohesive approach to animation that will help tie the experience together across mediums and viewport sizes. You really need that high-level view of animation when creating a motion style guide or animation guidelines.

You could definitely collect the data for a motion audit in tandem with a content audit. You’ll likely be looking in all the same places, just collecting up more data as you go through your whole site.

There is a strong tie between content and animation. I’ve been finding this more and more as I work with my consulting clients. Both can be focused around having a strong message and communicating meaningfully. When you have a clear vision of what you want to say, you can say it with the motion you use just like you can say it with the words you choose.

Voice and tone documents can be a great place to start for deciding how your brand expresses itself in motion. I’ve leaned on these more than once in my consulting work. Those same words you use to describe how you’d like your content to feel can be a basis of how you aim to make the animation feel as well. When all your design choices—everything from content, color, type, animation—come from the same place, they create a powerful and cohesive message.

CL: One thing in your book that I found fascinating was your statement that animation “doesn’t have to include large movements or even include motion at all.” Can you talk more about that? And is there any sort of relationship between animation and so called calm technology?

VH: It’s true, animation doesn’t always mean movement. Motion and animation are really two different things, even though we tend to use the words interchangeably. Animation is a change in some property over time, and that property doesn’t have to be a change in position. It can be a change in opacity, or color, or blur. Those kinds of non-movement animation convey a different feel and message than animation with a lot of motion.

If you stick to animating only non-movement properties like opacity, color, and blur, your interface will likely have a more calm and stable feel than if it included a lot of movement. So if your goal is to design something that feels calm, animation can definitely be a part of how you convey that feeling.

Any time you use animation, it says something, there’s no getting around that. When you’re intentional with what you want it to say and how it fits in with the rest of your design effort, you can create animation that feels like it’s so much a part of the design that it’s almost invisible. That’s a magical place to be for design.

MM: Do we also need to be mindful of the potential of animation to cause harm?

VH: We do. Animation can help make interfaces more accessible by reducing cognitive load, helping to focus attention in the right place, or other ways. But it also has potential to cause harm, depending on how you use it. Being aware of how animation can potentially harm or help users leads us to make better decisions when designing it. I included a whole chapter in the book on animating responsibly because it’s an important consideration. I also wrote about how animation can affect people with vestibular disorders a little while back on A List Apart.

MM: Who today, in your opinion, is doing animation right/well/interestingly?

VH: I’m always on the lookout for great uses of animation on the web—in fact, I highlight noteworthy uses of web animation every week in the UI Animation Newsletter.

Stripe Checkout has been one of my favorites for how well it melds UI animation seamlessly into the design. It really achieves that invisible animation that is so well integrated that you don’t necessarily notice it at first. The smooth 3D, microinteraction animation, and sound design on the Sirin Labs product page are also really well done, but take a completely different approach to UI animation than Checkout.

Publications have been using animation in wonderful ways for dataviz and storytelling lately, too. The Wall Street Journal’s Hamilton algorithm piece was a recent data-based favorite of mine and the New York Times did some wonderful storytelling work with animation around the Olympics with their piece on Simone Biles. Also, I really love seeing editorial animation, like the Verge had on a story about Skype’s sound design. The animations they used really brought the story and the sounds they were discussing come to life.

I really love seeing web animation used in such a variety of ways. It makes me extra excited for the future of web animation!

MM: Any parting thoughts, Val?

VH: My best advice for folks who want to use more animation in their work is to start small and don’t be afraid to take risks as you get more comfortable working with animation. The more you animate, the better you’ll get at developing a sense for how to design it well. I wrote Designing Interface Animation to give web folks a solid foundation on animation to build from and I’m really excited to see how web animation will evolve in the near future.

For even more web animation tips and resources, join me and a great bunch of designers and developers on the UI Animation Newsletter for a weekly dose of animation knowledge.



Designing Interface Animation

A note from the editors: We’re pleased to share Chapter 9 of Val Head’s new book, Designing Interface Animation: Meaningful Motion for User Experience, available now from Rosenfeld. For 20% off all books purchased through rosenfeldmedia.com, use the discount code ALADIA.

Each animation in an interface tells a micro story, and as a user encounters more and more animations throughout your site or product, these micro stories add up to reveal the personality and story of the brand or product behind them. The animations create an impression; they give your brand a certain personality. It’s up to us as designers to take control of the combined story that animations are telling about the brand we’re working on. Your animations will be much more effective if you intentionally design the additional messages they’re sending.

Brand animation design guidelines aren’t something entirely new, of course. Brands have been expressing themselves in motion in commercials, TV bumpers, video titles, and similar places for years, and they’ve had guidelines for those mediums. What’s new is the idea of needing animation design guidelines for the web or interfaces. Even if your brand will never be in a traditional commercial or video, having a website is enough of a reason to need a motion style guide these days.

How Your Brand Moves Tells Its Story

Deciding what you use animation for, and how you implement it, for a particular project defines how you express your brand or tell your brand’s story with animation. Often, the decisions of which properties to animate or what easing to use on which elements is done at the component or page level without considering the bigger picture. Assembling a global set of rules about motion and animation for your entire project will help you make more cohesive animation decisions moving forward. These choices lead to more consistent design decisions surrounding animation and make your design stronger overall. It requires you to go back and forth between the big picture of the overall project and the more detailed components, but your entire design will benefit from looking at the project from both perspectives as you work.

There are two approaches to begin defining how your brand expresses itself in motion. The first is to go from the bottom up: start by evaluating what you already have and build from there. The second is to go from the top down: first, determine what it is your brand should be saying about itself on a high level, and then determine how individual animations will express that concept.

The first approach works best for existing projects that already use animation. There could be hidden gems of communication to build upon in the animations you’ve already designed—ones that will inform the bigger picture you’re working to define. The second approach is generally your only option when starting a brand new project, as there won’t be any existing animation to start from. Whichever approach you choose (or even if you use both), you’ll arrive at the same end result, a common set of guidelines for putting your brand in motion, so they are equally good places to begin.

Defining Your Brand in Motion from the Bottom Up

Before you start documenting for the future, you need to get a good picture of what you’re currently using animation for. It’s hard to move forward before knowing where you currently stand. (That is, unless you’re planning to throw it all out and start over.) For existing projects that already use animation, you can start with a motion audit to find all the instances and ways you’re currently using animation. Collecting these in one place will identify the common threads and even help you eliminate unnecessary duplicated or overly similar animations. A motion audit will focus your animation efforts and the design reasoning behind them.

A motion audit gathers up all the interface animations you’re currently using to identify patterns and evaluate their effectiveness as a group.

The Motion Audit

To collect all your animations in one place, you’ll need some screen recording software that will output video. QuickTime is a handy built-in option for Macs, but a more specialized tool like ScreenFlow can save you some time with its more robust cropping and editing tools. Use whichever tool is easiest and fastest for you. The exact software used is less important than the end collection and what it will tell you.

How to do a motion audit (Fig. 9.1):

  • Collect screen recordings of every animation currently on your site. (Be sure to get a recording of all the different states for interactive animations.)
  • Crop and edit the video clips as needed to focus in on the animations.
  • Assemble all the video clips into one document and group them in categories according to content type (for example, one slide for all the button animations, one slide for navigation animations, etc.).
  • Review the document with your team to evaluate your brand’s existing animation style.

When you have all of those in one place, you can look for global trends, find potential redundancies, and most importantly, evaluate if the way you’re currently using animation accurately reflects the personality of your brand or product.

A screenshot of a page/slide of a motion audit document created for Shopify.
Fig 9.1: A screenshot of a page/slide of a motion audit document created for Shopify.

Software for Motion Audits

Recording Animations

For the screen recording part of motion audits, I like to use ScreenFlow. It’s Mac only, but Camtasia offers similar functionality for both Windows and Mac. The QuickTime player that comes installed with OS X is also an option. It’s especially good for recording animations from an iPhone. Just plug it into the computer and select it as a camera in QuickTime.

The Motion Audit Document

My preferred software for the end document is Keynote. (PowerPoint would do just fine here as well.) I prefer it because it makes it easy to set each animation’s video clip to play when clicked and because it lends itself well to be projected and discussed as a group.

When Keynote isn’t an option, creating a web-based motion audit is a good alternative. It’s easy to share, and the video clips can be played directly from within the web pages. I find that having the videos playable from the document is really useful. Often, you’ll discover animations that some of your teammates weren’t aware of or maybe haven’t encountered in a while.

The key is having an end result that can be shared and discussed easily. So if there’s another format that your team has a strong preference for, you can make that work, too.

Evaluate Your Existing Animation’s Design

The first question you’ll want to investigate is: Does the personality expressed by the existing animations fit your brand? Look at the qualities of the animations you’re using to answer this one. What kind of personality traits do the easing and timing used convey? If it’s snappy and bouncy, does that match your brand’s personality and energy? If it’s all stable ease-in-outs, is your brand personality also stable and decided? If you find the mood of the animations doesn’t fit your brand’s personality, small changes to the easing and timing could make a huge difference to bring the animation in line with your brand.

If the personality conveyed from your animations is all over the place and not cohesive at all, starting over and taking the top-down approach described might be the next best step. It’s often easier to work from the top down with a clear vision, as opposed to trying to fix a huge group of existing animations that are all a little bit off.

If the personality conveyed by your animations does fit your brand perfectly, great! Take a detailed look at what all these animations have in common. List the easing, timing, and other design choices they have in common. This will be the basis of your brand’s animation style guide.

Evaluate Your Existing Animation’s Purpose

Next, look at the purpose of the animations you’ve collected. How are they aiding your users in their tasks? Are they bringing something positive to the experience? Their purpose can be anything from something tactical like providing feedback to something more branding related like expressing your brand’s personality. Challenge yourself to articulate a purpose for each one to help you evaluate how useful they are. If there’s no definable purpose for an animation to be there, consider eliminating or redesigning it to have a solid purpose and goal. (Good UX purposes for animation are covered in Chapters 4 through 8.)

It’s also helpful to group the animations in your motion audit by their purpose—gathering up all the animations that are there to give feedback into one section, for example. This can reveal some helpful insights, similarities, and patterns among animations that share a similar purpose.

Define Your Brand in Motion from the Top Down

If your brand doesn’t currently use any animation or if you’re starting a new project, you can develop your brand’s animation design guidelines from the top down instead. That is, start from your brand’s design philosophy or the traits your brand aims to embody and decide how to translate those into animation. It’s starting from a different place, but it gets you to the same end goal of having specific and defined ways that your brand will exist in motion.

The Words You Use to Describe Your Brand

Start with the adjectives that you use to describe your brand or product. The description of the personality or feelings it aims to create. Is your brand energetic? Friendly? Strong? Playful? Stable? All this descriptive language can be translated into motion just like it can for other design tools like typography and color. Animation speaks in similar ways.

A great place to look for these descriptive words is in your copywriting guidelines or voice and tone guidelines. Many of the same words used to describe how to write for your brand can be directly applied to motion as well. Brand style guides or brand books can also be a good source for descriptive language.

If none of the above exists for your brand, you’ll need to do a little work to define your brand’s voice. “5 Easy Steps to Define and Use Your Brand Voice” by Erika Heald could be helpful for a quick start. Or to get even deeper into defining your brand, I recommend reading Designing Brand Identity by Alina Wheeler.

Energetic

If your brand is energetic, friendly, or bold, animation that relies on a lot of overshoots or follow-through and anticipation can help convey a sense of energy. Softly overshooting the target position can make animations feel both friendly and energetic. Drastic overshoots and quick speed changes read as bold and outgoing. Taken even further, adding a bit of bounce to overshoots or follow-through can convey a sense of even more energy in a movement—so much energy that an object has to bounce off its destination once or twice before it settles (Fig. 9.2).

Placement of square shapes in relation to a target finish line
Placement of square shapes in relation to a target finish line
Placement of square shapes in relation to a target finish line
Fig 9.2: Follow-through and overshoots in motion come across as energetic. The more exaggerated the movement, the more energy is implied. See it in action in this video.

Quick, soft movements—like overshoots—tend to read as energetic in a friendly way. On the other hand, quick movement with sharp changes in direction can suggest impatience, curtness, or urgency. That kind of movement is difficult to show in print, but you can see a video version here to see what I mean.

Playful and Friendly

Playful brands can take advantage of squash and stretch to convey that playfulness (Fig. 9.3). Squash and stretch also makes movements read as energetic. However, beware, because it can also make motion look childish or sloppy if it’s done with too much of a heavy hand. But, on the other hand, when it’s done well, it can really set you apart.

Bouncy easing can also evoke friendliness or playfulness. Wobbly bounces can seem playful and elastic, while springy bounces can seem friendly.

Rounded and elliptical shapes suggesting changes in dimension
Rounded and elliptical shapes suggesting changes in dimension
Rounded and elliptical shapes suggesting changes in dimension
Fig 9.3: Squash and stretch tends to create a sense of playfulness and a little goes a long way. See it in action in this video.

Decisive and Sure

Ease-in-outs—that is any easing that gradually speeds up into the action, is fastest in the middle, and then slows at the end of the action—are balanced and stable. They produce animation that accelerates into the action and then slows down to hit its end target exactly and with precision and decisiveness. Sticking with variations of ease-in-outs can communicate a sense of stability and balance for your brand. A variation of ease-in-out easing applied to a simple horizontal movement would look like this video example in Fig. 9.4.

A graphic illustration the curves of an ease-in-out progression
Fig 9.4: Motion with ease-in-out easing like the graph above, and similar easing curve variations, tends to read as calm and decisive action because elements move fastest in the middle of the action and decelerate into their final position. You can see the resulting motion in this video.

Calm

The amount of movement you employ can also say something about your brand. Animation doesn’t necessarily have to include large movements or even include motion at all. Smaller movements read as more calm and subtle than larger more drastic movements. Using smaller movements can contribute to the stable and calm personality of your brand.

You can still imply the same kinds of movements, just in a less drastic way. For example, when you aim to create small movements, you might have a modal animate into place from 50% of the way down the screen instead of 100% off-screen past the bottom of the visible area (Fig. 9.5).

Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Visual comparisons of location adjustments as a square either moves in small increments or large ones
Fig 9.5: Both squares in the frames above arrive at the same destination, but the first one gets there by moving a shorter distance. This smaller movement often reads as feeling calmer and more subdued than larger movements. See both in action in video: small movements vs. large movements.

Stable

Animating properties like opacity and blur instead of creating movement is another way of conveying a sense of calm and stability (Fig. 9.6). (Animating these properties will change the appearance of the object—making it more transparent or blurred, for example—but because the position of the element isn’t being animated, no movement will occur.) It can also convey a sense of softness or even feel dreamy, depending on how softly you use the opacity and blurs. Sticking to these nonmovement properties can still say so much about your brand in small spaces where motion may not be possible or desirable.

A square shape progressively becoming transparent
A square shape progressively becoming transparent
A square shape progressively becoming transparent
Fig 9.6: Animating non-motion properties, like blur and opacity, can read as more stable and subtle. See it in action in this video.

These are just the start of adjectives to consider when trying to convey a specific type of energy in the design of your animation. Like most other design tools, it’s more of an art than a science. Experiment with the guidelines to find what expresses your brand best for you.

Referencing Motion from Real Life

Looking to the physical world can be a great option for finding your brand’s style for motion by finding a physical object or creature to emulate with your on-screen animation. Technically, you could choose anything at all to base your motion on, but this works best when the thing you choose is relevant—either literally or metaphorically—to your product or brand.

IBM has done a wonderful job of this with its Machines in Motion design guidelines. IBM used to make those giant, room-sized computers, typewriters, and other hardware before becoming the IBM they are today. They decided to reach back to their rich history as a company when defining how they would express their brand in motion (Fig. 9.7).

Screenshot of IBM’s Machines in Motion design guidelines
Fig 9.7: IBM’s Machines in Motion design guidelines pair movements from the physical products IBM used to make with matching motion for their animation interactions. See it in action.
 

They used these past machines to inform their motion design efforts on two levels. On a high level, they chose four machine traits that all their interface motions should embody: agility, efficiency, precision, and order. From there, they got more specific and paired motion from the actual machines with screen-based equivalent animations. On-screen menu drawers are animated to have the same motion as the carriage return motion of a 1970s IBM typewriter. Loading spinners are animated to have the same acceleration patterns as reel-to-reel tapes of an old mainframe’s tape drives.

These one-to-one translations of motion from the historical real-world objects to the screen-based motion inform all of their motion design decisions. If you have physical objects, either historical or not, that are significant to your brand or product, you could develop your own guidelines using this same approach.

A more metaphorical approach to emulating real-world objects can work well, too. Finding a particular dance piece or animal movement that speaks to the same personality values as your brand can be a great place to start. Music can be a source of motion inspiration, even if you’re not including any sound in your interface. Choosing a specific rhythm or phrasing from music to apply to your animation’s movement brings a whole new dimension to the idea of UX choreography. There are so many possibilities out there. Find something that feels inspiring for your brand and explore how it can establish a cohesive thread through all your animations.

Staying on Point

  • Animation design guidelines or values can help keep your brand’s motion efforts consistent and cohesive.
  • Collecting and evaluating existing animations as a group with a motion audit can give you valuable insight into how you’re currently using animation.
  • The same words you use to describe your brand and its values can be translated into motion to define your brand’s motion style.
  • Looking to real-world objects or animals to emulate can also help define what your brand looks like in motion.


This week's sponsor: HIRED

HIRED, the most efficient way to find a new job. Get exposed to 4,000+ companies with just 1 application.



Webfonts on the Prairie

I last wrote about the progress of webfonts for A List Apart six years ago. Very few sites used webfonts then, but there was a lot of pent-up frustration among designers to get moving after 15 years of confinement to so-called “web-safe” system fonts.

And move they did. With the learn-as-you-go self-reliance that web creators have always been so good at—a slick change in syntax to grease this thing here, a polyfill to patch that thing there—we’ve come a long, long way with very little preparation.

A success by anyone’s measure (mostly)

As of May 2016, a majority of sites—60% of the Alexa Top 1 Million Sites—were using webfonts, up from only 2% in 2011.

Side-by-side graphs showing adoption of webfonts between 2011 and 2016: from 2% to 60% usage
Image: HTTP Archive.

In “Efficient Web Type, Circa 1556”, designer Kenneth Ormandy notes that “we are building sites that request more fonts, from an 8kb average transfer size at the beginning of 2012 to a 59kb average two years later.”

Graph generated from the HTTP Archive showing font request compared to font transfer size
Image: HTTP Archive.

Data also shows that soon after a site adopts webfonts, it will likely add more: the number of requests go up and, so too, do the sizes of the files requested. An exodus away from system fonts is clearly underway. Webfonts have reached critical mass and will soon be the new normal in web typography.

Now, whether webfonts, cloud computing, or animation, the adoption of new technologies means potential users have come to terms with their fears about them. These fears can be very irrational, and they can persist long after the conditions that gave rise to them are gone. For example, in 2009, web performance expert Steve Souders—then at Yahoo—warned web designers that they should, if at all possible, stay away from webfonts: “My first piece of advice is to avoid using @font-face unless it’s critical to the page.”

Whoa. Okay, but that was back then. This is 2016. With usage at 60 percent, surely nobody would seriously argue for a return to system fonts, right?

Wrong.

In a post called “Webfonts”, web designer Adam Morse says we should all just say no to webfonts and insists that system fonts are a better choice.

What?

Just say no

Morse writes:

There are a lot of arguments around why you should use webfonts. In none of those arguments, have I heard about a single problem being solved for users.

He goes on:

Over the last three years I have participated in a number of testing sessions. In that time I never heard a user complain about:
  • the use of system fonts in a design.
  • a website having the same typeface as another site.
  • a page using system fonts that loaded too quickly.
  • a site NOT using web fonts.

On the flip side I:

  • observed users abandon a website because the page was loading slowly.
  • heard people complain about the dreaded flash of unstyled text.

In sum, Morse’s attitude is that web fonts aren’t worth the trouble they cause some users—especially in low-bandwidth conditions—and that sticking with tried-and-true system fonts is best for all concerned.

Well. In less time than it takes to say “Holy holdout, Batman!” web designer Robin Rendle posted a rebuttal. A few days later came Frederic Marx’s “Webfonts Last”. And in between those volleys, both Jeffrey Zeldman and Jeremy Keith took note of the disturbance in the force and I, sucked into the vortex, offered to write this article. C’est le web.

Morse’s criticisms obviously hit a sore spot with Robin Rendle and Frederic Marx and, frankly, me too. But why so touchy after all this time? Webfonts are a runaway train and anyone standing astride the tracks shouting stop is just asking to get plowed over. Didn’t everybody get the tweet about this? Well, maybe not—maybe some people genuinely aren’t aware that webfonts have become so popular.

As Rob Larsen observes in his book The Uncertain Web:

Most of the time, front-line developers don’t get to spend time looking at the big picture…Even folks who are tasked with keeping track of the big trends can get sidetracked…It seems like people don’t really think about how fundamentally the Web has changed.

But then, also, maybe there’s some truth to what Morse is saying.

Ouch.

J’accuse!

Morse is right to rail against webfonts’ drawbacks. A poor user experience for some of us diminishes all of us. Leave no user behind—who would argue with that? Plus, the browser makers and the W3C have taken too long and have done too little to give web designers the fundamental tools, within CSS alone, to ensure consistent behavior from browser to browser. A standards-based fix is long overdue.

The CSS font-display property proposed by Tab Atkins, Jr. of Google is an attempt at just such a fix.

Atkins lists some of the persistent problems his proposal addresses:

  • Chrome and Firefox have a 3 second timeout after which the text is shown with the fallback font. Eventually, a swap occurs: the text is re-rendered with the intended font once it becomes available.
  • Internet Explorer has a 0 second timeout which results in immediate text rendering: if the requested font is not yet available, fallback is used, and text is rerendered later once the requested font becomes available.
  • Safari has no timeout behavior (or at least nothing beyond a baseline network timeout)

He continues:

While these default behaviors are reasonable, they’re unfortunately inconsistent across browsers. Worse, no single approach is sufficient to cover the range of use cases required by modern user-experience–and performance–conscious applications.

Now, amazingly, jaw-droppingly, these defects are consistent with the very same defects described in Souders’ analysis from 2009—seven years ago!—in which he advised, from a webperf analyst’s point of view and with a webperf analyst’s priorities, that webfonts not be used at all.

Yet the pain of still more Arial, still more Helvetica, proved too much to bear when, at long last, webfonts started looking like a practical option in early 2011. Web design featuring a wide variety of typefaces that were searchable, scalable, zoomable, selectable, and high-DPI friendly was too great a temptation to resist. Scary talk be damned, designers inched forward on their own, saw for themselves, and, in the collective view of the two percent of early adopters, despite a few kinks and blinks—c’mon, is it really a “flash” of unstyled content?—webfonts by and large worked well enough to begin leaving the homogeneity of system fonts behind.

But infatuation will only take you so far. Those early adopters were able to keep moving steadily forward and draw others into the fold only because conditions became increasingly amenable to webfonts. The timing was right.

Like manna from heaven

It’s 2011, and for webfonts to start taking hold, backward compatibility with Internet Explorer is essential. It’s hard to imagine any site giving webfonts a try if it means excluding the huge number of IE 6, 7, and 8 users that existed then. The catch was, with any version of IE prior to version 9, the webfont had to be converted from a TrueType font (TTF) to the Embedded OpenType (EOT) format. Then, the HTML had to include CSS that accommodated both the rudimentary implementation of @font-face that went all the way back to the release of IE 4 in 1997 and also, at the same time, work with the newer syntax demanded in CSS3. Several workarounds emerged, but in the end there was a clear winner: the New Bulletproof Syntax was a clever, yet simple, CSS-only solution to the problem. It’s still in wide use today.

More help was on the way: WOFF webfont compression (and the new and improved WOFF2); finer control over loading using JavaScript; speedier delivery of assets using content delivery networks (CDNs), and emphasis on best practices like setting cache headers so that on initial download, webfonts are stored locally in the cache to avoid delay due to network latency on subsequent visits. Browsers improved, too—they started supporting a greater number of simultaneous connections for faster, parallel downloading of linked assets, and a newer and faster protocol (HTTP 2.0).

The main objection to webfonts has always been the prospect of a fitful user experience on page load, particularly on a first visit, when the browser hasn’t yet had the opportunity to locally cache any of the site’s assets and localStorage can’t yet come into play, as it does in some of the JavaScript polyfills for the controlled loading of webfonts. First, there’s a delay caused by the time it takes the network to deliver the webfont and that, in turn, causes a so-called flash of unstyled content (FOUT) as the browser paints the page with a fallback system font and then repaints the page when the webfont arrives. Now, without getting into the many possible causes for network latency, the simple and only solution for this scenario is a faster network connection.

And so, greatly favorable to the adoption of webfonts—perhaps above all else—and yet easily overlooked because it came gradually and in small doses—was more bandwidth, more bandwidth, and then more bandwidth. The average internet speed in the United States today is three times as fast as it was in 2011.

Progressive enhancers need not apply

Webfonts are sometimes presented as “progressive enhancements” of system fonts. That’s incorrect. System fonts are a parallel solution to the same problem. A webfont is not an “enhanced” version of a system font, nor is a system font a gracefully degraded webfont. It might feel that way because, if a webfont is not available, the browser falls back to a system font. But fallback fonts are system fonts that vary according to which platform the browser is installed on; there is no way to know precisely which font—or version of the font—the browser will fall back to. As any web server administrator will tell you, the only content you can be absolutely sure of is what’s on your server. Everything else is guesswork. In fact, to get webfonts working well, the exact opposite of progressive enhancement is required.

Let’s call it “regressive insistence.” (How’s that for a euphemism?) It’s simple: you pull the hammer labeled “JavaScript” from your toolkit and bang at the browser with it until webfonts work. And with only a little banging, they work quite well. In fact, a particular set of hammer strokes —so to speak—has been standardized in the CSS Font Loading API.

Morse is right that, without extra effort, CSS by itself doesn’t give us the tools to smooth out the user experience as webfonts load (or don’t). But we can achieve that level of control with just a little bit of extra work—well-tested remedies and refinements exist for all of the problems Morse implicitly treats as insurmountable. Typekit’s Bram Stein, Filament Group’s Zach Leatherman, and Google’s Ilya Grigorik have all prominently posted solutions to these problems online. The truth is out there, Scully.

As Jason Pamental writes in Responsive Typography:

The answer isn’t, as some developers have called for, to not use web fonts at all, but rather to do our job and control the process with the tools we have at hand. Type is simply too important a design element to give up just because we’re lazy.

Amen. Which leaves us with the final reason why Morse’s criticisms are beside the point. He puts an unquestioning, almost religious, faith in system fonts.

In his rebuttal to Morse, Rendle notes:

It appears that he argues we should use a “web-safe” or a system font because they’re more predictable. However, I would argue that there’s no such thing as a “web-safe” font.

It’s a fact. Ask yourself this: if network bandwidth had been able to support the requisite file sizes when the web began, wouldn’t fonts sent from the server have been greatly preferred over system fonts? If you can only be certain of what’s under your control on your server, which would you rather have—the certainty of webfonts that are precisely what you and your users want and need, or the crapshoot of fonts preinstalled by makers of operating systems that present you with moving targets that vary from platform to platform? So-called “web-safe” system fonts were a temporary ad hoc solution that web designers had no choice but to accept because network bandwidth was not yet capable of delivering what would, sooner or later, be necesary for the web to take its place as a truly global tool. Webfonts—the ones designers choose—are the true “web-safe” fonts. They always were. If ever there was a time when, by chance, system fonts offered a safe and simple haven for web designers, those days are long gone.

The challenge of multi-script fonts

Most of the fonts Google commissioned in 2015 were Indic—Devanagari, Bengali, Gujarati, Gurmukhi, Kannada, Myanmar, Sinhala, Telugu, Tamil, and Malayalam—along with Arabic, Hebrew, Ethiopic, Armenian, Cyrillic, Cherokee, Lao, Khmer, and Thai. On Google Fonts’ redesigned site, you’ll see new menu items with those choices. The World Wide Web may be a creation of the West, but now, at long last, it needs to get ready for the rest. There’s a great hunger for the web to accommodate the world’s 6,000+ languages; a way to fulfill that need has finally taken shape through a convergence of three key developments:

  • the rise of Unicode.org as a standards body and central authority in deciding which characters are referenced by which code points
  • the implementation of the CSS3 @font-face rule in web browsers
  • support for the OpenType font standard in web browsers

(Full disclosure: as a consultant for Google, I worked on quality control for many of these new fonts. But the views expressed here are strictly my own.)

The need for wider language support alone is enough to drive webfonts unstoppably forward. Sure, if you’re a native speaker of English working blissfully on a Macbook in a London pub and the year is 1886 and the sun never sets on your empire, by all means, stick with system fonts. But the truth is this: you can’t and won’t be able to count on the local operating system of every device to support all of the languages demanded by a truly worldwide web.

But enough. You don’t need a weatherman to know that a protest by one contrarian web designer won’t change the way the wind blows. Besides, websites are team efforts built and improved by collections of people. There are built-in institutional barriers that can delay and sometimes defeat the adoption of a new technology. It’s a thing.

So, let’s take a look at where the adoption of webfonts across the industry stands today, and call it a wrap.

Patterns of adoption

Using webfonts means accepting that the typographic look-and-feel of a site is no longer in the hands of the makers of operating systems—it’s in the hands of those creating the site. Perhaps those hands are yours. Now, some may take on these new responsibilities eagerly; others may not. Those with a background in graphic design who miss the freedom to choose from a variety of typefaces will probably push hard for the change, while those who lack that background, or who champion performance over style, may urge caution.

Typography is a big deal. It’s branding. It’s identity. The desire to stand out visually is as powerful on the web as it is in any other medium—if not more powerful. And so far, along with a reflexive impulse simply to escape the sameness imposed by web-safe fonts, such motivations have proven strong enough to overcome the inertia and “if it ain’t broke, don’t fix it” attitude infusing many organizations.

But no matter how great the desire to change, internal politics, cost analysis, budgeting, and scheduling all take time.

Technical innovations don’t diffuse randomly. There’s a pattern to adoption, like ripples in a pond after a stone is thrown in. Below is a graph of a diffusion curve—the pattern of the ripples—with a red dot placed on the yellow line showing the point where webfonts have progressed with usage at 60 percent of the potential market:

Image showing a graph of a diffusion curve
Image based on Everett Rogers, “Diffusion of Innovation”(Wikimedia)

As you can see, the adoption rate is about a third of the way into the group of users labeled “late majority.” We’re not quite at the point where everybody assumes that everybody is using webfonts everywhere, but we are at the point where those who aren’t are wondering: Why aren’t we?

There’s no going back, and there’s no staying behind.

Are you ready to roll?



This week's sponsor: ADOBE XD

ADOBE XD. Go from idea to prototype faster. Test drive the Adobe XD preview for Mac and tell us what you think.



Help! We (Think We) Need to Hire a Content Strategist

Those of us working in content strategy know that it is a rich and complicated discipline. We understand, of course, that there are different types of content strategists. But we need to remember that outside of our content strategy bubble, the discipline is still pretty new to colleagues and clients. As the discipline matures and more companies are looking to hire for content strategy, how can companies educate themselves on how to use our specific skills?

I’ve recently been on the job market. And so I’ve spent a lot of time wading through content strategy job listings and meeting with hiring managers. My experience suggests that people beginning to actively hire content specialists frequently have little understanding of what their companies need beyond a title. I would even estimate that about half of my interviews over the past few months have consisted of talking through and refining job descriptions with those sitting across the table from me.

Hiring managers at agencies, brands, and startups would do well to hire based on the type of work they want to focus on—not on a price tag or a title. Like experience design (which content strategy is sometimes folded into), content strategy has subspecialties. Some strategists veer more toward the UX side: user research, content maps, content modeling. Others specialize in PR and native advertising (social media, influencer outreach, and content discovery); still others focus more on content management systems and governance.

Some content strategists even overlap with digital strategists (considering the audience, conversion, and the larger digital ecosystem), but then also do some of the more tactical, executional work to bring these digital ecosystems to life. Others may specialize in search and organic growth. Increasingly, former journalists have started to position themselves as content strategists, using their expertise with long-form and mid-length content to cash in on the boom in native advertising work and branded content creation.

And let’s not forget how industry and categories figure into the equation. For example, if you are an ecommerce brand hiring a content strategist for a website relaunch, you may want a content strategist with past experience in ecommerce working on your site, given your specific conversion challenges. Similarly, for highly regulated spaces like financial services, healthcare, or alcohol, a content strategist with past experience navigating these categories makes sense.

If you don’t practice content strategy, talk to someone who does

For any company trying to make their first content-strategy hire, the most logical place to start is talking with a real live content strategist. I don’t mean that you should reach out to a content strategist on the pretense that this is a position for them and then use an interview to pick their brain (and waste their time). For starters, that’s not very nice; furthermore, you don’t want anyone spreading the word that your company doesn’t know what it’s doing and may not be the best place to work.

No, I mean that you should formally engage a content strategist as a consultant. Have them talk to your team, take a look at your business, help write up an accurate job description, and even start recruiting through their network for the specific position you seek to fill. Chances are they know a lot of good people in their community who would be a perfect fit for the role.

Too often, I’ve seen job descriptions written by someone who is obviously not a content strategist and interviews conducted by people who don’t really understand the discipline. This is likely because, depending on the organization and the kind of content strategy work you do, your role could easily sit in Strategy, Creative, UX, Product, Communications, or PR. And if you’re a content strategist more focused on measurement and SEO, a case could even be made for Analytics. While I understand why this occurs, it ultimately means that the candidates won’t be as strong as they could be.

For companies that already have a content strategist or two on staff, it makes sense to engage them as well, even if they’re in a different location or less senior than the role for which you are currently hiring. I guarantee that the kind of feedback they give you will be invaluable.

Don’t look for “unicorns”

Banish the word “unicorn” from your vocabulary—along with, for that matter, “rock star,” “ninja,” and any other ridiculous buzzword of the moment. I’ve worked in the content sphere long enough to know my own strengths and weaknesses. For example, while I’ve certainly worked on content strategy projects that required information architecture, metadata, and taxonomy expertise, I know that my sweet spot lies more in editorial strategy. I’ve learned to position myself accordingly.

Unfortunately, today’s job market sometimes views such candor as a weakness. Ours is a culture that rewards confidence. Indeed, a survey of over 400,000 hiring professionals revealed that confidence is one of the top three traits that employers say they are looking for in new hires. This is particularly true in the tech space, where much has recently been made of the confidence gap and how it negatively impacts women. As a result, during the hiring process, people can feel pressured to claim that they can “do it all” just to nail down the job. And when a hiring manager doesn’t fully understand what they are hiring for, compulsory confidence can be especially problematic.

The thing is, as a hiring manager, you should be skeptical of anyone who claims to do it all. Someone with over five years of experience who says they can do both structural content strategy and editorial content strategy equally well is likely inflating the truth. And while there may be a tiny constellation of people out there who really can do everything, it probably won’t be for the $60 per hour you are offering. Be realistic when you hire. Remember, you aren’t hiring for sales or new business; you’re hiring to get a job done. Don’t fall for the slickest kid in the room—you may find yourself with a mess on your hands.

Ask to see deliverables

As you decide to move forward in the process with a candidate you’ve vetted, rather than giving them a test or a lengthy spec-work presentation, a great way to see if they’re up to the task is to request a package of some of their past deliverables. Here are some deliverables to look for based on the type of content strategist you are hiring for:

  • Website relaunch: content audit, comparative audit, content matrix, editorial guidelines
  • CMS redesign: taxonomy and metadata recommendations, content models, site maps, workflow recommendations
  • Content strategist for an online magazine: editorial calendars, voice and tone outputs, content briefs
  • Content strategist with social-media focus: social editorial calendars, examples of social content, measurement reports
  • Content strategist with SEO and analytics expertise: SEO recommendations, analytics audit

Where do we go from here?

Knowing that you “need” content strategy at your company is one thing; hiring the right kind of content strategist to suit your needs and goals is another. Stop wasting your and your prospective hires’ time. Ask an expert for help, stay realistic about your hires, and request the appropriate deliverables. Making an informed decision about whom you bring on board will set you and your team up for success.

 



Why Aren’t You Asking Questions?

It’s the kickoff meeting. You are the lead designer on the project, and this is the first meeting with everyone in the room. Your client is reciting her wish list, and you’re taking diligent notes—probably with cute, relatable doodles.

An hour passes, and you’ve barely said a sentence. You’re nodding your head, scarcely making eye contact. You have some thoughts, but you aren’t speaking up. Why aren’t you speaking up?

You’ve likely been burned in the past. Perhaps you’ve shared some ideas and they were turned down. You have felt embarrassed in meetings. Projects that you put your heart and soul into were changed at the last minute without your consultation or discarded, apparently without a second thought.

Now, while it’s admirable to be an agreeable, easy-to-work-with colleague, being quiet and keeping your head down isn’t the answer because this is not a production line. You are a designer, and part of your job is contributing to the conversation.

It’s a designer’s job to ask good questions

You want to do your best work and meet your client’s needs, so playing an active role in the conversation is vital. To extract the most information you can from your client, you must ask questions. Lots of questions. Think of it like playing detective, gathering clues and working to understand the players in the game.

Laura Kalbag writes, “As designers, we can’t expect other people to know the right language to describe exactly why they think something doesn’t work. We need to know the right questions that prompt a client to give constructive criticism and valuable feedback.”

They are looking to you as the professional to not only listen to their needs, but to also be able to identify and understand their unexpressed needs.

It is not the client’s job to know exactly what their logo should be or how their website should function. That’s your job. They are coming to you to share ideas, to express concerns, likes, and dislikes. They are looking to you to help guide them to a solution.

Clients will always ask you to make their logo bigger, prescribe solutions, and ask you to do things that will make you smack your forehead. You can roll your eyes at how much they don’t understand about design or you can roll up your sleeves and begin practicing your craft by helping them clarify what they need.
Mike Monteiro from his brilliant and on point book Design is a Job

First, understand the end users’ needs

It’s pretty likely that your client isn’t the main user of the website or product you are designing. Even if they are amazing at articulating exactly their tastes and preferences, it’s beside the point because they are not the target audience.

If you are fortunate enough to be on a project that dedicates resources to user research, familiarize yourself with its findings. If you do not have access to this information, ask a few questions about who the end user is and what their needs are to better understand the target audience you are actually designing for:

  • Who exactly do you anticipate will be using this website?
  • What problem is this website solving for them? Or
  • What will they accomplish by using this website?
  • What are their pain points?

Once you establish who the end user is, try to phrase your upcoming questions in a way that encourages the client to see through the eyes of the end user, not their own. User experience consultant and writer Paul Boag simplifies this on 24ways.org: “A client’s natural inclination will be to give you his personal opinion on the design. This is reinforced because you ask them what they think of the design. Instead ask them what their users will think of the design.”

It is also possible that the client thinks they understand what the end user needs, but they are only working from assumptions. This is apparent when sweeping generalizations and blanket statements are made. As Laura Kalbag says, “Throughout the design process, we need to check our hidden assumptions about our users. We should also ensure any feedback we get isn’t based upon an unfounded assumption. If the client says the users won’t like it, ask why. Uncover the assumption—maybe it’s worth testing with real users?”

Establish attainable business goals

This is a conversation that I still struggle with. A lot of companies are good at coming up with lofty business goals that can be interpreted into almost anything, and are usually difficult to measure.

The conversation may start out up in the clouds, but by talking about business goals you are helping to break down assumptions, learn about your client’s current expectations, and set their expectations going forward.

For example, if the assumption is that by redesigning their website they will generate more leads, you need to establish clear language around what that means and what success looks like to them.

Daniel Ritzenthaler suggests “Taking the Guesswork Out of Design” by using “a modified acceptance criteria exercise [to set] clear and powerful goals.”

<!-- Example goal template:

We want to X because Y so that Z.

Example goal:

We want to increase traffic by 20 percent because we need more exposure so that we can generate eight more leads per month. -->

Ritzenthaler says, “Acceptance criteria for design is a great way to [flesh] out deeper, possibly unknown, intentions that will help the designer and project owner make better decisions and dodge surprises later in the process.”

Make sure you are asking the right people

The kickoff meeting is a great place to ask questions because, more than likely, the right people will be in the room.

If you have any control over who is required to attend, make sure the meeting includes everyone who has decision-making power, is assumed to have power, or is an opinion leader inside the organization.

I find that a lot gets lost in translation when a question filters up three levels of management and then trickles back down to you. When you hear information from the source, you get the original version and you also have the chance to ask for more clarity.

If you are not sure who the key players are, here are a few preparatory questions you can ask to get that information:

  • Who initiated this project?
  • Who will have the final decision with this project?
  • Who has the ability to cancel or postpone this project?

Ask a lot of open-ended questions

Once you understand who you are designing for, what the major goals are, and who the key players are, you will be ready to start discussing the details of the actual project.

Avoid simple yes or no questions—stick with something open-ended so you will get more information. Ask any question that comes to mind that will help you better understand the issue at hand.

Ask follow-up questions if there is something that still isn’t clear to you. You may have to ask the same question a few different ways before getting a response that gives you the information you’re looking for.

Read between the lines

In one person’s mind, “add more pictures” could mean a photo gallery of thumbnails at the bottom on the page. Another person might imagine this as the giant background image that they saw on someone else’s site and they want exactly what that person has. And yet a third person is picturing replacing most of the text on the page with infographics.

Here’s an example: you are working on a web design and the client doesn’t think there are enough images on the mockup you provided. Ask:

  • What value will adding more images provide? For whom?
  • Are images available?
  • Does a photographer need to be hired?

If you find out their solution was to purchase stock photography, dig a little deeper.

  • Is stock photography genuine enough for their audience?
  • Will it convey the value they were hoping for?
  • If a visitor to the website found out it was stock photography, would that affect their perception of the company?

These are likely questions they have not yet thought through. By asking these questions, you are helping the client see the bigger picture and preserve the value of the brand or message.

Try generic questions

If you’re not sure what the right question is, you can keep it really simple by using one of the following go-to phrases:

  • Why?
  • Could you elaborate?
  • Would you describe that for me?
  • What does that look like to you?

Make sure you are clear and concise. Do not muddy up your question with “ummm,” “er,” “like,” “whatever,” or “you know.” A clear question has a better chance of getting a clear answer.

You’re going to annoy someone

Truth is, it is possible that some people may get annoyed with the questions. Don’t let this deter you. It isn’t personal. You have a job to do and clues you need to gather. Explain why it is necessary that you truly understand the problem you are all here to solve together, and explain that in the long run it will likely save a lot of time. Thank them for their understanding and cooperation (even if they are being quite the opposite of cooperative).

If a client appears frustrated or annoyed that you are asking so many questions, it may be because they thought they had it all figured out. You just made them realize that they haven’t even begun to figure it out.

What was supposed to be a “quick” web design has become a bigger project, one that requires real thought and effort. They may feel frustrated that it won’t be the quick fix they initially expected. That’s not your fault! You’re doing the client a favor in the long run by ensuring that all parties are on the same page and making the best decisions together.

Read the room

If your client comes across as agitated by speaking more loudly, constantly interrupting, or suddenly becoming very short with responses, try to assess how you are coming off in this meeting. Are you talking more loudly or interrupting? Do you think he feels like his answers are being heard?

In that scenario, taking a more laid-back approach by leaning back in your chair a little, speaking somewhat more slowly and softly, and relaxing your face may help the meeting move in a more productive direction.

Test engagement

You need your clients to be engaged to get the most information. If they are not making eye contact, not participating in the conversation, or are busy on their phones, they may not be engaged.

By simply pausing and allowing silence, you may be able reengage the client. Or test their engagement by asking a couple of questions:

  • Are we discussing what you had hoped we would?
  • Is there anything we haven’t covered that you hoped we would?

Take a break

Stepping away for a few minutes can clear the mind and calm the nerves.

A five-minute break will keep your client engaged by allowing them to check their emails, text, and get a few seconds of relief from their FOMO. Use this time to assess the situation and formulate your next questions.

Play nice

Don’t give the impression that you are trying to prove them wrong; this isn’t a pissing contest. Approach the conversation with genuine curiosity and a lot of empathy. You are both working toward the same goals here.

  • When you ask a question, really take time to listen to the response.
  • Do not interrupt.
  • Be supportive as they give their answers and thank them for giving you the additional information.
  • Don’t be afraid to use an awkward silence to your benefit. Chances are the client feels awkward, too, and will start talking, giving you even more information.

Asking great questions takes practice. Lifehack has some tips worth reading on how to be amazingly good at asking questions.

Your work reflects your level of understanding

Until we have the ability to project images with our minds (why don’t we have this yet?), or unless your client is an amazing sketch artist, asking questions and piecing the clues together is our most effective tool to understand their expectations, and help them see the bigger picture along the way.

If you leave the room without asking any questions, there is no way you can really understand what is being asked of you. You might annoy someone along the way, but your work will have so much more meaning and, in the end, your clients and their end users will see the added value in your work.



This week's sponsor: CONTENTFUL

CONTENTFUL, an API-first, developer-friendly CMS. Build custom content-rich front-end with the tools of your choice.



Communicating Animation

Consistent animation is crucial to both branding and UX. Interfaces obey laws of “design physics”; keeping animation consistent throughout an experience envelops users in an illusion of life, of reality. Animations that step out of line disrupt that flow and feel sloppy or jarring. But because animation sits squarely at the intersection of design, development, and UX, achieving consistency presents unique challenges:

  • Communication issues make it hard for siloed teams to understand and tackle animations together.
  • Inadequate deliverables prevent developers from moving forward quickly.
  • Lack of respect for and deference to fellow team members leads to lopsided implementations that privilege some voices at the expense of others. When it comes to animation, it’s important for everyone to be heard.

Including animations in our style guides and design systems is a great place to start. However, this is relatively new territory, and most animation documentation initiatives seem to be driven by either development or design. In an ideal world, developers and designers would live in harmony and collaboration, but all too often the two houses exist in isolation from each other.

Most examples of animation in documentation reflect this rift by falling into one of two categories: thematic and educational, as seen in Google’s Material Design guidelines; or granular and explicit, as displayed in Salesforce’s Lightning Design System. Designers want to provide guidance and overarching themes, as well as educational materials, in an effort to raise the profile of animation both within a company and within the larger web design and development communities. Meanwhile, developers aspire to define and dictate animation for maintainability and consistency.

illustration showing a designer and a developer, each thinking separate thoughts / asking separate questions

This contrast reflects the needs of each group. Designers want to know the underlying principles of motion design driving their application; developers want to know how to build that design to spec. These interests are not at odds with each other—rather, they form incomplete halves of a greater whole:

  • Documentation details what’s there and why.
  • Defaults offer building blocks and rules for spinning up new projects.
  • Unity provides a common language and choreography.
  • Guidance empowers future designers to make smart decisions.

As of this writing, there is no Ultimate Animation Style Guide/Pattern/Tile/Whatever example that combines all of these elements perfectly. There may never be an animation-style-guide pattern that satisfies everyone. Some organizations may need more of some of the above components than others, depending on the project and the animation or development literacy of the team. But all approaches share features that we can combine to create the Ultimate Animation Documentation for our own teams. Let’s have a look.

Deliverables

Deliverables are supposed to round off the design process, but I often find it helpful to start with what developers want and need. Some companies have designers who build prototypes in code. Developers then find it easy to go into the code and grab the variables needed to reproduce the UI animations. But not all workflows look like this, and many motion designers will rightly argue that the very act of animating code-first limits the ideation process.

That’s why, at many companies, designers create animations in After Effects or Photoshop and then hand them off to developers. The developers must then pick apart these videos and gifs to determine what is changing at what rate. This makes the burden of implementation especially heavy for the developer, giving animation a reputation for “taking too long to prioritize.”

illustration showing a designer blithely handing off deliverables to a beleaguered developer

I myself once had to spend six hours converting an animated GIF to SVG by eyeballing it. If the designer had provided me with the necessary values, I could have recreated the animation perfectly in thirty minutes, tops. We’ll look at these values—easing, timing, and properties—next. For the sake of simplicity and consistency, we should include them in our documentation and reuse them as much as possible across our systems.

Easing

illustration showing a designer blithely handing off deliverables to a beleaguered developer

Easing describes the rate at which something changes over a period of time. It has its roots in traditional studio animation, where it was called “cushioning” or “slowing.” Easings are shorthand for rates of acceleration, deceleration, and bounces. We can invoke generic easings with CSS via keywords like “ease-in” and “ease-out,” but when everyone uses the same defaults, everyone’s designs start to look and feel the same.

Easings provide an opportunity for us to set our UI apart from others in a very subtle way. We want custom easings that reinforce our brand—be it professional, fun, elegant, or even dark. And that’s what cubic-bezier curves were created for. Cubic-bezier curves are a set of numbers we can pass to CSS and JavaScript animation libraries to tell them how we want the animation to change over its allotted timeline. We can get some starting points at sites like easings.net or create our own using the browser’s developer tools.

It’s tempting to make one cubic-bezier curve to rule them all, but what we really want is an array of several curves for different purposes:

  • Human-initiated interactions feel faster and more natural if they respond immediately. A deceleration (moving from fast to slow), or ease-out, provides immediate feedback that tapers off.
  • System reactions are less alarming if their curve is accelerated, moving from slow to fast, or what we call ease-in.
  • Fades and color changes often look best with a more constant curve, but you could purposely buck that to express your aesthetic values.

Most design systems benefit by specifying at least an ease-out, an ease-in, and a fade curve.

Timing

Easings are a high-visibility return on investment. But animation can’t happen without a duration. On the Lightning Design System, I worked with Amy Lee, who also happens to be a musician. In a brilliant example of genius occurring in the overlap of disparate fields, she came up with the concept of timing scales: a set of time values that align at various combinations.

The concept is similar to modular scales in typography: all values are related, and if you combine them with a vertical rhythm, a piece exhibits overall harmony. You can generate a timing scale the same way you generate a typographic scale.

There are upper and lower limits. While the human eye can perceive images in as little as 13 milliseconds, it takes us between 70 and 700 milliseconds to move our eyes according to the Human Processor Model. 200–300 millisecond values typically become the workhorses of a timing scale, from button depresses to secondary animations. (The persistence of this time range across game and web development is especially interesting in light of recent research suggesting we experience the world in 400 millisecond “chunks.”) Shorter durations work better for color changes and fades, which the human eye picks up readily. Longer durations are better for larger fields of change, like page transitions, or motions that occur over longer distances, like a drag-and-drop interaction or menu slide-out over a large screen.

It’s a good idea to define durations in milliseconds rather than seconds. While most animation libraries can accept seconds and milliseconds, JavaScript timers and the Web Animations API take only milliseconds. Also, some people may find it easier to work with zeros than decimals (although that might be more of a tabs versus spaces argument).

Properties

diagram showing properties that describe what is being animated

Properties describe what is being animated. Currently in web animation, the most performant things to animate are opacity and transforms (scale, distance, rotation). But there will be times when we want to animate less performant things like color or—heaven forfend!—height. Browsers are working hard to improve their animation performance, so while it’s great to try to stick to transform and opacity, don’t be afraid to push technology with art where you can get away with it.

Knowing the properties we want to animate comes in handy when communicating animations with storyboards and specs and when we’re creating our project’s very own animation vocabulary.

Creating an Animation Language

We combine these three components—easing, timing, and properties—to create vocabularies of words like “pop,” “fade,” and “slide.” Many of these expressions start as friendly onomatopoeias: swoosh, zoom, plonk, boom. And sometimes colleagues will, say, hold a sound longer to indicate extended duration: “Can you make it more like voooooosh and less like voosh?” It makes sense to “pave the cowpaths” and adopt words like these when constructing our own animation vocabularies.

lettering illustration showing friendly onomatopoeias: swoosh, zoom, plonk, boom

Vocabularies are granular. You can layer these microanimations to create macroanimations—for instance, a modal that fades onto the screen then pops to grab user attention.

animated GIF showing a modal that fades onto the screen then pops to grab user attention

These words might seem arbitrary at first, but they yield huge benefits when it comes time to document our visual deliverables with text.

Communicating Visually

There are three ways to communicate animation: storyboards, animatics, and prototypes. All of them contain a visual component, but only storyboards include words. Words are one of the lowest common denominators of digital human information exchange—capable of being read out loud, indexed by search engines, translated by machines. In many cases these words are the key to conveying animation deliverables, so it makes sense to start with storyboards.

Storyboards

photograph of storyboards at Disney Studios

Disney Studios invented storyboards for working on feature-length animation films, and it wasn’t long before Hollywood started using them, too. Storyboards let disparate teams get an overview of a linear narrative. They reduce time spent on dead-end shots and help directors and writers visualize the final story, and edit it on the fly. These days, storyboards are used not only in cinema but also in game design and interaction development.

photograph showing a whiteboard with storyboards scrawled on it and covered in Post-its

These storyboards can range from very informal (on a small-team interaction-design project where everyone follows each stage of development closely) to very detailed and particular (for specifications and audits). One problem I have as a consultant is that I find it difficult to embed videos or GIFs in PDFs to hand to managers as a way of explaining where animation problems occur. So for long-term storage, I include a storyboard.

diagram showing a storyboard for a motion-design audit

This storyboard was part of a motion-design audit for a large project where I needed to leave the client with actionables to include in their next sprint.

Storyboards use words and illustrations to represent interactions and animations. Every animated interaction can be divided into a “before” shot and an “after” shot; it’s up to us to illustrate the in-between shot to demonstrate how we get from one to the other. Language helps us clarify why these changes are happening. Using words like this is a powerful thinking tool. Justifying animations verbally helps us sort necessary animations we can defend from ones that are perhaps less mission-critical.

Storyboarding software, most of which is geared toward cinema, is simultaneously insufficient and overkill for web development collaboration. Teams often have more fun and collaborate better with good old index cards and Post-its. I’ve written about a more formal approach to my storyboarding techniques, and you can download my storyboarding template to get started.

Animatics

If a picture is worth a thousand words, an animation is worth ten thousand meetings. Storyboards, sadly, can’t show us how something “feels” on the screen or under the thumb. Once again, studio animation provides a solution in the form of animatics, videos of the storyboard set to an audio track that can be screen-tested with an audience or presented to investors as proof of progress. We can also make small videos or GIFs with our wireframes and storyboards that demonstrate how they work.

Do not throw these mini videos over the fence to developers. Finalize animatics by combining them with the deliverables developers crave: easing, duration, and properties. At most, an animatic is a measuring stick against which we compare the final, implemented animation. And the two will only match 100 percent if we provide our developers with the inputs necessary to duplicate the original.

For creating animatics, AfterEffects is the software of choice in the motion design industry. Web designers may be more accustomed to creating animatic-like demos in Keynote to be clicked through in meetings. These can be recorded with screencasting software like Quicktime or Camtasia. And some visual prototyping tools like Principle export to video, achieving two things at once.

Prototypes

Animatics can be screen-tested on an audience, but screen-testing works best for passive media. The web is interactive: people interact with designs, which in turn react to them. There’s no way to test these reactions with storyboards or videos. When we want to be sure of how people will respond to a design, we want prototypes.

There are two approaches to prototypes: coded prototypes and prototyping software. Developers tend to prefer the former, often leaning on frameworks like framer.js and Zurb’s Foundation; designers prefer the latter, in the form of software like Invision App and UX Pin. Both approaches require team members to invest time in learning a new system, thus increasing the commitment factor.

Most prototyping software with animation features, like Pixate and Principle, is app-oriented. But the web is catching up with products like UXPin, and web and native prototyping powerhouse Invision has demonstrated its commitment to improving animation tooling with its purchase of Easee.

Coded prototypes, unlike storyboards, are terrible for documentation: only code-savvy team members can read them, and the files must be organized and sometimes compiled or served before inspection. An external agency would struggle to deliver a fully branded experience riffing off a pile of non-production code.

Pick two

If we rely on storyboards, animatics, or prototypes alone, we can’t hope to communicate animation clearly, effectively, or sustainably. But if we combine them, they work great: a demo next to a set of deliverables; a storyboard with a video. Such combinations work well for documentation and also sometimes for offering animation boilerplates.

Venn diagram showing how storyboards, animatics, or prototypes might be combined

Animation as a team sport

Many animation documents are created in the hopes that “if you write it, they will follow.” We hope our coworkers will read our sage advice and start preaching the animation gospel; we hope they’ll copy our animation deliverables perfectly for every button, gesture, and loading spinner.

In practice, though, it’s extremely rare for even half of a team to care as passionately about animation as the person writing the docs. While education and guidelines are fantastic in principle, they are a wasted effort if no one cares. Here are some quick ways to get our teammates on board:

  • Group documentation. Having a documentation format that everyone can contribute to—and then having people contribute even just a few words—helps them feel like this is their baby, too.
  • Team tweening exercises. I use these exercises in training to help get siloed teams collaborating. Take “before” and “after” wireframes, and give everyone index cards to brainstorm all the possible animations they could use in between those states to get from point A to point B.
illustration showing team tweening exercises
  • Cultivate and champion. Teams without motion and animation champions can’t sustain their animations over the long run. Someone has to grow the love for animation and make it second nature to think about it, same way we think about color or fonts. Otherwise, animation risks being sidelined the way accessibility and user testing often are. Many organizations assume an initial effort is sufficient to address what should become an integral part of their design process.
  • Have a coconspirator or two. We should always be on the lookout for coconspirators. One champion isn’t enough. Eventually we all move on to other projects, and a healthy system is one that can function when one of its pieces goes missing.
  • Do it anyway. Sometimes people just have to see the difference animation makes to believe it. You can ask for forgiveness later.
illustration of a happy team


A template library will need different documentation than, say, an interactive story app. What matters is clearly recording and communicating those deliverables and cultivating a concern for animation among our peers. People fear what they don’t understand, and they fear change. Education, communication, and collaboration turn that fear into enthusiasm and goodwill.

There is no one right way to document animation. But when we collaborate with our teams, together we will find the right way forward. Don’t be the lone animation wolf; find or found an animation pack. Recruit other animation wonks from different areas like UX, front-end development, data visualization, design, and marketing. Diverse views will strengthen how we approach animation and help rally more support from other corners. Together, we can all find our own “way of animation” that works best for us.



Another 10k Apart: Create a Website in 10 KB, Win Prizes!

It gives us great pleasure to announce the 2016 10k Apart competition. Create a fully functioning website in 10 KB or less! Amaze your friends! Astound the world! Compete for fabulous prizes!

Why 10k? Why now? It’s simple, really. In the 16 years since we told you about the first contest to create a functioning website in 5 KB or less, countless aspects of web design and development have changed. And, year after year, A List Apart has marked those changes, even instigating more than a few of them ourselves. But in all those years, one thing has remained constant: the need to keep our websites lean. Indeed, in the age of mobile slash responsive slash multidevice design, keeping sites lean and mean is more important than ever.

In 2000, Stewart Butterfield launched the original 5k competition to celebrate the skill, ingenuity, and innovation of designers and developers who wring every byte of performance out of the websites and applications they fashion. Ten years later, Microsoft and An Event Apart launched the first 10k Apart—adding progressive enhancement, accessibility, and responsive web design to the competition’s requirements.

And now, An Event Apart and Microsoft Edge have teamed up once more to entice you, the makers of websites, to improve your performance game yet again by competing in a new 10k Apart that’s even tougher than the last one. Golly!

Ah, but there’s gain for your pain. Besides fame and glory, you could win $10,000 in cash, tickets to An Event Apart, the complete A Book Apart series, and a copy of Aaron Gustafson’s Adaptive Web Design, 2nd Edition, which I consider the unofficial successor to Designing With Web Standards. So what are you waiting for? Hop on over to the 10k Apart website for complete rules and details.



Practical SVG

A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Chris Coyiers’s new book, Practical SVG, available now from A Book Apart.

You’ll probably want to exert some sizing control over any graphic you put on a website. Hey! You! Logo! You should be this size:

<img src="logo.png" class="logo" />
.logo {
  width: 220px;
  height: 80px;
}

And so shall it be.

But if the element you are resizing happens to be svg, the result might not be exactly what you expect. Sizing svg is a little more complicated than sizing an img. I’m not saying this to scare you. It’s almost complicated in a good way, because it gives you more control and opens up some interesting possibilities.

Keep these two concepts in mind when you’re working with the size of SVG images:

  • The viewport is simply the height and width of the element: the visible area of the SVG image. It’s often set as width and height attributes right on the SVG itself, or through CSS.
  • The viewBox is an attribute of svg that determines the coordinate system and aspect ratio. The four values are x, y, width, and height.

Say we’re working with some SVG like this:

<svg width="100" height="100" viewBox="0 0 100 100">

<!-- alternatively: viewBox="0, 0 100, 100" -->

In this case, the viewport and viewBox are in perfect harmony (Fig 6.1). The SVG will be drawn in the exact area it visually occupies.

See the Pen adqEmQ by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.1: Viewport and viewBox in perfect harmony. This happens when you apply no width or height to the svg (either via attribute or CSS), or if you do, they match the aspect ratio of the viewBox.

Now say we double the width and height, like this:

<svg width="200" height="200" viewBox="0 0 100 100">

Will the svg just draw in a 100 by 100 space in the upper left side of the 200 by 200 element? Nope. Everything inside the svg will scale up perfectly to be drawn in the new, larger space (Fig 6.2).

See the Pen VeQyQY by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.2: With the viewport enlarged and viewBox kept the same, the graphic scales up to fit the viewport.

The square aspect ratio still matches perfectly. That’s why it’s not particularly useful to think of the numbers anywhere in SVG as pixels, because they aren’t pixels; they’re just numbers on an arbitrary coordinate system.

What if the aspect ratios don’t match, though?

<svg width="300" height="75" viewBox="0 0 100 100">

What happens now, by default, is that the SVG will draw itself as large as it can, centered along the longest dimension (Fig 6.3).

See the Pen vLdpdN by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.3: The viewport is enlarged, but no longer matches the aspect ratio of the viewBox. So by default, the image is drawn as large as possible without being cut off, and centered on the long dimension.

If you want to regain some control over this behavior, there’s an attribute for the svg element that can help!

preserveAspectRatio

It looks like this:

<svg preserveAspectRatio="xMaxYMax">

The x and Y parts of that value are followed by Min, Mid, or Max. The reason SVG normally centers in the viewport is because it has a default value of xMidYMid. If you change that to xMaxYMax, it tells the SVG: Make sure you go horizontally as far to the right as you can, and vertically as far to the bottom as you can. Then be as big as you can be without cutting off.

The “without cutting off” part is another aspect of preserveAspectRatio. The default value is xMidYMid meet—note the “meet.” You can replace meet with slice to say instead: Fill the area entirely; cutting off is okay.

There are nine possible alignment values combined with meet (Fig 6.4).

Several images representing rectangle pairs, demonstrating placement variations for smiley face graphics found in each rectangle.
Fig 6.4: Examples of preserveAspectRatio values with meet.

There are also nine possible alignment values combined with slice (Fig 6.5).

Several images representing rectangle pairs, demonstrating placement variations for smiley face graphics found in each rectangle. Each also exceeds the height and width of the rectangle's frame.
Fig 6.5: Examples of preserveAspectRatio values with slice.

I made a testing tool for playing with this idea. Sara Soueidan also wrote an in-depth article on this subject, where she makes an excellent observation relating this idea to CSS. The background-size property has two keywords it can take: contain and cover. The contain value means “make sure this entire image is viewable, even if you have to shrink it,” which makes it just like meet. The cover value means “make sure this covers the entire area, even if you have to cut parts off,” which makes it just like slice.

Even the alignment part of the value has a matching CSS counterpart: background-position. The default background-position is 0 0, meaning “top left.” That’s just like xMinYMin. If you were to change that to, say, 50% 100%, that would be like xMidYMax!

Fig 6.6 has some examples to make that connection a little clearer.

preserveAspectRatio values and CSS properties
preserveAspectRatio= "xMinYmax meet" background-position: 0 100%; background-size: contain;
preserveAspectRatio= "xMidYMid meet" background-position: 50% 50%; background-size: contain;
preserveAspectRatio= "xMinYmax slice" background-position: 100% 0; background-size: cover;
preserveAspectRatio= "xMidYMid slice" background-position: 50% 100%; background-size: cover;

Fig 6.6: preserveAspectRatio values and the CSS properties they are similar to.

Remember: these aren’t interchangeable bits of code; they are just conceptually related.

What if you want to throw aspect ratio out the window and have SVG scale to the viewport, like a raster image would? Turn preserveAspectRatio off (Fig 6.7)!

<svg preserveAspectRatio="none" viewBox="0 0 100 100">

See the Pen yevpvj by Chris Coyier (@chriscoyier) on CodePen.

Fig 6.7: Example of preserveAspectRatio="none". Poor little buggers.

Amelia Bellamy-Royds wrote a comprehensive article on scaling SVG, in which she covers things like the fact that svg can essentially contain other svg with different aspect ratios and behavior, so you can make some parts of an image scale and others not, which is pretty cool and unique to SVG.

Approaches to artboard sizing

When you draw SVG in editing software, that software likely gives you some kind of artboard to draw on. That’s not a technical SVG term; it’s essentially a visual metaphor for viewBox.

Let’s say you’re working with a whole set of icons for a site. One approach is to make all artboards hug each edge of the icon (Fig 6.8).

Adobe Illustrator graphics cropped to their edges
Fig 6.8: Example of graphics in Adobe Illustrator cropped to their edges.

Here’s a quick trick to get that artboard cropping in Illustrator: select the Artboard tool and then “Fit to Artwork Bounds” from the Presets menu (Fig 6.9).

Cropped view of Adobe Illustrator menu option for resizing an artboard to the edges of a graphic
Fig 6.9: The menu option in Adobe Illustrator for resizing an artboard to the edges of a graphic.

The big advantage to this technique is alignment (Fig 6.10). If you want to align any edge of any of these icons to anything else, that’s easy to do. There is no mysterious space you need to contend with, or tweaky positional CSS.

.icon.nudge {
  position: relative;
  right: -2px; /* UGHCKKADKDKJ */
}
Icons aligned to corners of graphics
Fig 6.10: Icons aligning to edges without little bits of extra space you have to account for.

The big disadvantage to the cropping technique is relative sizing. Imagine you take the practical step of sizing your icon’s width and height, like this:

.icon {
  width: 1em;
  height: 1em;
}

A tall, skinny icon will shrink to fit in that space and potentially appear awkwardly small. Or perhaps you’re trying to have an intentionally small star shape as an icon, except the star has a squarish aspect ratio and thus grows to fill the space, appearing bigger than you want it to.

Here’s an example where two icons are sized identically as a square (Fig 6.11). The “expand” icon looks right at home, since it has a square aspect ratio to match. But the “zap it” icon has a tall and narrow aspect ratio, so it looks wimpy, like it’s floating in the same square area.

Two button samples; one example has a nicely-balanced scale of icon to text, the other has an icon that is too small for the space and size of text
Fig 6.11: Two icons sized in the same square space within a button. The top one fits nicely, but the bottom one floats awkwardly in space.

The other approach here is to make consistently sized artboards (Fig 6.12):

Several similarly-sized graphics
Fig 6.12: Example of Illustrator graphics whose artboards are equal in size.

The advantages and disadvantages are exactly inverse here. You might have alignment issues, because not all edges of the icons touch the edge of the viewBox, which can be frustrating and might require tweaking sometimes (Fig 6.13).

Graphics with icons sized to be comparable to one another
Fig 6.13: You can adjust icons’ relative sizing, but that can make alignment more difficult.

You won’t have relative sizing issues, though, because the viewBox is the same for all of them. If any particular icon looks too big or small, you can adjust the artwork to bring it more in line with the set.

Since we’re learning about sizing, now is the perfect time to bring up how SVG fits into the flexible world of responsive design.

Responsive SVG

One of the hallmarks of responsive design is fluid layout. Content—images included—is designed to fit its containers and the screen. If responsive design is new to you, Ethan Marcotte’s seminal 2010 article on the subject is a fine place to start learning about it. SVG jibes extremely well with responsive design:

  • Responsive designs are flexible. So is SVG! It renders well at any size.
  • Responsive web design is a philosophy of caring about how a website looks and behaves in any browser. Comparatively smaller SVG files and performance-responsible tactics like an SVG icon system can be a part of that.

But perhaps SVG’s most obvious connection to responsive design is the possibility to react to CSS @media queries. Media queries move, hide, or show elements with CSS based on things like the width or height of the browser window. Those elements can be anything: sidebars, navigation, ads, what have you. They can be SVG elements as well.

Imagine a logo that displays different levels of detail depending on how much space is available. That’s exactly what Joe Harrison was thinking when he created a really neat demo using well-known logos, (Fig 6.14).

Modified versions of the Disney logo, progressing to greater and greater simplification
Fig 6.14: Joe Harrison’s demo of the Disney logo at different sizes.

On the web, we’ve always had the ability to swap out images with other ones. What’s appealing here is that we aren’t swapping out images; these are all the same image. Or at least they could be. That signature “D” all by itself could be the same exact “D” used in the most complex version of the logo. Easy-cheesy in CSS.

Say we organize the SVG like so:

<svg class="disney-logo">
 <g class="magic-castle">
    <!-- paths, etc -->
  </g>
  <g class="walt">
    <!-- paths, etc -->
  </g>
  <g class="disney">
    <path class="d" />
    <!-- paths, etc -->
  </g>
</svg>

This, by the way, is pretty easy to do in Illustrator (Fig 6.15). The groups and names you create there turn into IDs in the SVG output, and you can use those IDs to do the styling. Personally, though, I prefer using classes because they aren’t unique (so you don’t accidentally end up with multiple identical IDs on the page) and because classes have a lower and more manageable level of CSS specificity. It’s easy enough to change IDs to classes with a bit of find-and-replace maneuvering in a code editor.

Adobe Illustrator interface showing vector paths and layers for Walt Disney logo
Fig 6.15: Named layers and named shapes in Adobe Illustrator.

The corresponding CSS could be something like this:

@media (max-width: 1000px) {
  .magic-castle {
    display: none;
  }
}
@media (max-width: 800px) {
  .walt {
    display: none;
  }
}
@media (max-width: 600px) {
  .disney > *:not(.d) {
    display: none;
  }
}

Mind you, this is a contrived example of hiding parts of the images at different breakpoints, but that’s exactly how you would do it, along with some likely sizing adjustments. Anything you can do with CSS is on the table here. Perhaps some animation is appropriate at some breakpoints but not at others. Perhaps you change stroke sizes to beef up or trim down icons at different sizes. Perhaps you change some fill colors to simplify adjacent shapes.

And things can get even fancier! Depending on how the SVG is used, those media queries might actually be different. SVG used as img, iframe, or object has its own viewport. That means CSS embedded inside of it reacts to media queries based on that, rather than the whole browser window viewport. That means you would write, say, width-based media queries based on the width of the image, not of the entire page.

That’s a very appealing idea: an element that arranges itself based on attributes of itself, rather than the page. Am I this wide? Do this. Am I this tall? Do this. That way, the SVG reacts to the situation it’s in rather than the arbitrary document it happens to be part of.

As I write, this is referred to as “element queries” in CSS, but it doesn’t actually exist yet in regular HTML/CSS. Once again, SVG is ahead of the curve.

Graduation into animation

Speaking of things SVG is good at, let’s move into animation next. Everything we have been building on so far has prepared us for this. Hang on tight!



This week's sponsor: HIRED

​HIRED, where companies apply to you. Get your profile in front of 4,000+ companies with one application.



Finding Opportunities in the Mistakes We Make

Roughly six years into my software development career, I had worked on interesting projects, met amazing people, and had the opportunity to travel to exotic cities. Yet I was frustrated. I was burning the candle at both ends to get things done. I didn’t look back to see if I could improve on how things were being done; I had no time. Deep down I knew it wasn’t feasible. I was working hard, not smart; I felt like I wasn’t working toward anything; I was falling behind with technology. I was burning out.

I started searching for an opportunity to facilitate my technical growth. Two years later I was based at an enterprise client who adopted agile software development methodologies, and everything changed for me. This new world exposed me to a diverse working environment and new perspectives, and encouraged me to ask even more questions than before. This is when I discovered the power of the words “reflect, inspect, and adapt.”

It wasn’t a walk in the park with unicorns and rainbows, but the experience has aided me in officially branding my career as one exciting journey of professional and self-discovery. Now ten years into my career, I realize that for most of that time I have been in survival mode. After looking back, I’d like to share how I found opportunities in the mistakes I made.

Define clear career and personal goals

Computers weren’t a household name when I was growing up in South Africa, but I was lucky to have access to my dad’s Pentium 386. I was amazed at this technology. When we got internet access, I was immediately hooked on the online world. I taught myself HTML and later built my own machine with the money I made from designing a website for the local newspaper.

When I chose my higher education path I had one goal—I wanted to make websites. I didn’t want a degree; I wanted experience. I studied at a college for two years, then excitedly entered the workforce to follow my passion.

As I entered the workforce, I wasn’t prepared for the politics: managers expecting things to be done almost immediately; clients who don’t engage and are unsure of what they want; clients who express urgency, yet wait for the last minute to provide you with everything you need; an increased workload due to colleagues who stay well inside their comfort zone. These are just some examples of the politics that initiated my frustrations.

I wondered if this is where I’d still be in five or ten years and if I would be able to sustain it. I didn’t know the answer to the former, but to the latter it was definitely no.

Coupled with turning thirty, the new perspectives I developed in the agile environment made me really evaluate my future. I realized that I didn’t have goals; I was only chasing my passion. Granted, it is fun and I gained a lot of experience in many different areas in IT, but I don’t have anything tangible to show for it now.

After much reflection, I discovered these goals for myself:

  1. Increase productivity. I minimize distractions like email, social media, and uninvited guests to improve my productivity. To make sure I am working on the right tasks, I need to have a clear understanding about what I am working on and why.
  2. Develop software that has a positive impact on people. It is important to understand business thinking and impact on users. I need to ask appropriate questions, and I need to guide and negotiate with product stakeholders.
  3. Share my knowledge. I can create an online identity (publish articles, blog), possibly speak at events, and contribute to open-source software. I can find projects on GitHub of libraries and tools that I regularly use and create a pull request.
  4. Better my craftsmanship. I can learn through code reviews and peer conversations, listen to podcasts, read up on best practices, read more craft-related reference books, and reflect on my implementation.
  5. Learn to live mindfully. To have a positive impact on people, I can make small adjustments and engage those around me to help me grow. Meditation, reflection, and motivational books are tools I could use to guide me.
  6. Showcase my career. Create a tangible timeline of projects I have worked on including screenshots, descriptions, technologies, and learnings.

These goals feel more defined to me than just making cool websites. I wish I had set some goals a little sooner but luckily — as cliché as it sounds — it’s never too late. Goals give you direction and purpose. Like me, you may have worked many late nights on personal projects that never materialized. It helps to have focus and something definite to achieve. I find what’s best of all is that I don’t feel constrained by having these goals. They represent what’s important to me now but if my values change, I can inspect and adapt my goals.

Put people before technology

For too long, I worked alone on my own codebases and wondered if I was doing things the right way. I had little to no exposure to working in teams and dealing with industry buzzwords like agile, TDD/BDD, Gang of Four, SOLID, code reviews, continuous integration/delivery, DevOps, and <insert your favorite technical jargon here>. I was in a bubble falling further behind in the fast-paced technical world. I was focused on working with technology and never realized how important it is to collaborate.

If you work in a company with a silo-based culture or one- or two-people teams, try not to accept things for what they are:

  • Get involved with your coworkers by communicating and collaborating on projects.
  • Try introducing knowledge-sharing sessions and code reviews.
  • Reflect on what worked and what didn’t and also unpack why, so that you can learn from it.
  • Approach management with suggestions on how you and your colleagues can produce more solid and effective software.
  • Attend conferences or smaller community meetups. Not only can you learn a lot through the content but you have the chance to network and learn from an array of people with different skills.

Prioritize your tasks

I often worked about twelve to sixteen hours a day on projects with short deadlines. I spent my official work hours helping colleagues with problems, immediately responding to email, attending to people with queries or friendly drop-ins, supporting projects that were in production, or fighting fires resulting from errors that usually came from miscommunication. This left me with very little time to be productive. When I finally got to work on my project, my perfectionism only increased my stress levels. Regardless, I never missed a deadline.

I thought everything was important. If I didn’t do what I was doing the world would end, right? No! The reality is that when everything is important, nothing is important.

This working behavior sets unrealistic expectations for the business, your colleagues, and yourself. It hides underlying issues that need to be addressed and resolved. If you are working at an unsustainable pace, you can’t deliver your best work plus you end up missing out on actually living your life.

The power of retrospectives

The most important ceremony (or activity) I was introduced to in the agile environment was the retrospective, which is “the process of retrospecting at the heart of Scrum (Inspect and Adapt), eXtreme Programming (fix it when it breaks) and Lean Software Development (Kaizen or Continuous Improvement)”.1

Through retrospection you are granted the opportunity to reflect on how you — and the team — did something, so that you can improve the process. Let’s run through this technique to identify some pain points using the situation I had found myself in:

  • Working unsustainable hours because there was too much to do. I helped everyone else before I worked on my own tasks, I worked on things that didn’t add much value, and I thought that all the features needed to be ready for launch. I was blind to asking for help when I needed it.
  • Dealing with too many distractions. I allowed the distractions by immediately switching context to help others because it was important to them.
  • Key-person dependency. I was the only person working on one of the projects.
  • Miscommunication resulting in errors. Communication was done via email and the stakeholders were off-site. There wasn’t quick feedback to indicate if the project was going in the right direction.

Once the pain points are identified, adjustments need to be made in order to see improvement. Large adjustments could take too long to implement or adjust to, which leads to disruptions. Smaller adjustments are better. These adjustments may or may not work in the long haul, so we can look at them as experiments.

  • To work more sustainably I need to know what I need to work on — and why — so that I can add value without wearing myself out. Perhaps I could find out what needs to be available for launch and create a prioritized list of things to do. This list could help me focus and get into the “zone.”
  • To manage client expectations, we can try open communication. This can also help me prioritize my tasks.
  • To overcome some of the distractions I could reap the benefits of being selfish by saying no (within reason). This could help me stay in the zone for longer. If anything must be expedited I can start offering trade-offs: if I do X now, can Y wait?
  • To alleviate the pressures of being the sole person able to do certain things, I could have more conversations with my manager and train a colleague so that they are aware of what is going on and someone can take over in the event that I get sick or am on vacation.
  • To reduce errors from miscommunication, perhaps we could create visibility for stakeholders. Introduce a physical workflow board and have constant feedback loops by requesting frequent reviews to demonstrate what we have done.

Experiments run for a period of time and need to be measured. This is a grey area. Measurements aren’t always accurate, but it always boils down to the pain. If the pain is the same or has increased, then the experiment needs to be adjusted or a new experiment introduced. If it has been alleviated, even slightly, then there is improvement.

Learning through experimentation

Many of the experiments mentioned above already form part of the agile Scrum framework, so let me introduce you to real-world experiments we did in our team.

Based on the way our development stories were deployed, we experienced pain with testing stories in the appropriate order. We were using Jenkins for automated deployments and each one got a number incremented from the previous one, but the testers weren’t testing the stories in any particular order. If a story was ready to be deployed, they wouldn’t know if there was another, untested story that they were unwittingly promoting to production along with it, or if the story they tried to deploy was being held back by other stories still awaiting testing.

Without waiting for a retrospective we had a conversation to highlight the pain. We chose to write the build number on a note stuck on the story card on our wall and add a comment to our digital storyboard. This created quick visibility on the chronological order of the possible deployments of our stories.

A change control process was later introduced that required details of a production deployment and a rollback plan for that change. We couldn’t quickly access the last few production build numbers, so we started writing them on stickies and put those onto a new section on our physical board. Now we didn’t have to search through email or log in to Jenkins to find these numbers. One day, we were asked when we last deployed and had to go back to email for the answer, so we started adding the date to the deployment number stickies.

These were simple experiments but they added a lot of value by saving time. We acted on alleviating pain as it happened.

Don’t be afraid to experiment if you are not in an Agile world. If you simply run to business with problems and offer no solutions then business will frown at you. The goal here is simple: identify your pain points and find simple solutions (or improvements) to try to alleviate the pain. Experiment, inspect, and adapt often.

Believe in yourself

Survival mode never did me any good. I didn’t get an award for working long hours to make deadlines. Letting my mistakes and frustrations build up over the years made me stop believing in myself.

I was stuck in a rut; technology was changing around me fast and I was burnt out and falling behind. I’d scroll through Stack Overflow and instantly feel stupid. I’d spend time looking at all the amazing websites winning awards on Awwwards and feel inadequate. I didn’t have a life as it was consumed by my obsession for work. I didn’t know what I wanted anymore, or what I wanted to aspire to.

Introspection helped me. By inspecting my behavior, I was able to make minor adjustments that I would then inspect again to see if they worked. This simple activity can show you what you are capable of and lead you to learning more about yourself and those around you. I am applying what I have learned in software in a personal capacity. I have my life back, and I feel empowered and freed.

My final thoughts

I’ve definitely made a lot of mistakes in my career. What I have shared with you is probably only a fraction of them. I don’t regret my mistakes at all; that is how I got my experience. The only regret I have is that I wish I had begun reflecting on them sooner.

When a mistake is made, an opportunity is born: learn from that mistake to do something differently next time. Take time to step out of the subjective into the objective, so that you can reflect and consider what you could do to change it. (And don’t be too hard on yourself!)

My journey has taught me to implement small experiments that can be measured and to run them for short periods of time. If something works, keep it. If not, adjust it or throw it away. By making small changes, there are fewer disruptions. If you too are in survival mode — stop and breathe now! Reflect, inspect, and adapt.

Footnotes



Resurrecting Dead Personas

Being a user-centered designer means that you deliberately seek out the stories, data, and rationale behind your users’ motivations. You endeavor to keep user concerns at the forefront of every design decision, and regularly conduct research and collect data.

But collecting facts about users isn’t the same as knowing your users. Research and data need to be regularly aggregated, analyzed, and synthesized into a format that is both understandable and accessible at critical moments. You need to turn user facts into user wisdom, and one of the most common methods for doing this is to develop user personas.

Type “how to build user personas” into your favorite search engine and you will get thousands of results outlining different templates and examples of personas. Across the tech industry, personas “put a human face on aggregated data,” and help design and product teams focus on the details that really matter. Studies have shown that companies can see 4x the return on investment in personas, which explains why some firms spend upwards of $120,000 on these design tools.

However, while it is common for design teams to spend considerable amounts of time and money developing personas, it is almost as common to see those personas abandoned and unused after a while. Everett McKay, Principal at UX Design Edge, has pointed out that user personas can fail for a number of reasons, such as:

  • They do not reflect real target users.
  • They are not developed with product goals in mind.
  • They are not embedded into team processes.

I agree with everything McKay suggests, but I would add that personas fail largely because of one common misconception: the false idea that once you build a persona, you’re done. As designers, we know that the first version of a product is never perfect, but with multiple rounds of design and research it can be made better. Personas are no different.

To recover personas that have become lifeless, here’s how you can iterate on them with periodic research and use them to achieve tangible goals. The following steps will help ensure you see value from the investment you made developing them in the first place. Let’s put your personas (back) to work and incorporate them into your design and development process.

How a persona dies

Let’s imagine you work at a company called Amazing Childcare that creates tools to help parents find childcare options for their children. Let’s also say you have the following data and statistics for AmazingChildcare.com:

  • 82% of customers are between the ages of 30 and 35, and 73% of those are female.
  • The most common concerns around finding childcare (as reported in user interviews) are cost and quality of care received.
  • AmazingChildcare.com has a homepage bounce rate of 40%.
  • Customer satisfaction survey shows an average satisfaction rating of 6.5 (out of 10).

While this data is interesting, it is hard to process and assimilate into your design practice. You still need to go through the arduous work of understanding why the majority of users are who they are, what problems they are trying to solve, and how you can better meet their needs. So, you decide to create a persona.

The persona you create is Susan, a 34-year old working mother of a two-year-old. She is interested in finding a qualified nanny that has passed a background check. Susan, like all freshly made personas, is a much more thought-provoking platform for crafting design solutions than a spreadsheet of numbers. She is someone we can imagine, remember, and empathize with.

This is the point in the story when Susan dies.

At first, the design team enjoys thinking about and designing for Susan. Having her “in the room” is thought provoking and interesting, but over time, Susan is talked about less and less. She starts to feel irrelevant to the products you’re building. You realize that Susan has “died,” leaving a lifeless, zombie Susan sitting in her place. You consider all the research and work your team put into creating Susan and wonder “what went wrong?”

The problem is that your personas remained static and unmoving while the company, Amazing Childcare, grew and changed.

Review, research, repeat

As your product and marketing strategies change over time, so do your target users. In our example, Amazing Childcare may have started with a large user base of parents looking for full-time childcare options for their toddlers, but over time, the demographic changed. Now, it’s most frequently used by parents of school-age children looking for one-time, “date night” babysitters. When this happens, your original personas—like Susan—are no longer useful for thinking through design problems. Unless you periodically validate your personas, you’ll be responding to old assumptions (based on your outdated personas) rather than who your customers really are. In other words, your real-world users changed, but Susan didn’t.

To remedy this, you should regularly conduct persona research, using a variety of methods to evaluate whether your personas still reflect:

  • The most common demographic, budget, and purchase scenarios of your users
  • The main behavior patterns of your users
  • The motivations and goals of your users.

You can conduct your persona research on a schedule, such as once a quarter, or you can opportunistically work it into the usability research you already do. Either way, you need to make a commitment to keeping your personas relevant.

If we go back to our example at Amazing Childcare, your personas would change based on the new research. Susan may still be a valid persona for your company, but your research would show that she no longer represents its core users, and should therefore no longer be your primary persona. Based on the updated research, you could develop a new persona named Beverly. Beverly is a 42-year-old mother of a 10-year-old boy and 7-year-old girl. Unlike Susan, Beverly is interested in finding an inexpensive babysitter for occasional date nights with her husband. You would use Beverly to think about the needs of the core user base, but only use Susan when you’re designing tools that directly cater to the demographic she represents.

It is natural and necessary for personas to evolve and change; personas like Susan can drift out of the limelight of “primary persona” and make room for new friends like Beverly. Your ecosystem of personas should be as dynamic as your ecosystem of users, and regular persona research will ensure that they evolve in sync.

Set goals

Personas can help you do more than think about and design for target users. They can (and should) be used to help you reach real, tangible goals. Goals that reflect ways of increasing business, creating better user experiences, or both, will help you update your personas and develop your product. Even if you are not sure what is possible to achieve with personas, you should make an attempt at setting goals. Goals (even unachievable ones) provide a means for tracking the return on investment of your efforts.

To get started, try using this format from Tamara Adlin and John Pruitt.

The Persona Lifecycle
  Goal or issue How things are today How we want things to be tomorrow Ways to measure change
Description A problem you would like your personas to solve. A description of the current state of affairs. A description of the “first step” in achieving your goal. A description of analytics, research, or other methods you can use to measure progress.

Figure 1: Tamara Adlin and John Pruitt’s Essential Persona Lifecycle format

For each goal, you will need to identify how you’ll measure progress toward that objective. You may need to create surveys and interview scripts for some, while for others, you may need analytics tools.

Here is an example of a persona goal we could set at Amazing Childcare.

Amazing Childcare Persona Goal
Goal or issue How things are today How we want things to be tomorrow Ways to measure change
Use our primary persona to drive feature development. We have just started our business and believe users like “Susan” (our primary persona) will want certain features (like nanny search and background checks) to be truly satisfied. However, the Susan persona needs to be validated and tested. We want to thoroughly research and validate our Susan persona and better understand how Amazing Childcare can meet our primary users’ needs. We can validate the Susan persona and measure customer satisfaction through a series of surveys and interviews. We will know we’ve succeeded when the next feature release increases customer satisfaction with Amazing Childcare.

Figure 2: Example persona goal for Amazing Childcare

Once you have created a set of goals for your personas, you can evaluate them as part of your regular research plan. If you find that you’re falling behind on any of your goals, you can research and recalibrate your personas based on the metrics you care about.

For instance, if we evaluated the Susan persona in the ways we’ve outlined above, the data we would uncover indicates that Susan doesn’t actually represent the majority of our users. We would then reevaluate our personas and ultimately develop our new primary persona, Beverly.

Putting personas (back) to work

While research and goal setting are good practices, in and of themselves, the real benefit of personas can be seen when you put them to use. Here are some suggestions for how to incorporate personas into your design practice:

  • Start putting the face of your target persona at the top of every sketch, wireframe, and prototype. Encourage others to do the same.
  • Put a comment in every product story or ticket that states the target persona for that feature.
  • Shake up regular design meetings by asking a few people to roleplay as your personas. Throughout the rest of the meeting, have them look at every new design through the lens of their assigned persona.
  • Conduct a workshop. Activities such as Persona Empathy Mapping reinvigorate and add detail to personas.

One of my favorite ways to utilize personas is to write scenarios in which they are the main character, then use them to explain research results. For example, let’s say we’re evaluating a new interface for the sign-up and login process on our website. Instead of presenting raw numbers (e.g., “10% of new users couldn’t find the sign-up interface”), we can present the data in a scenario, providing a way to understand a design problem that goes beyond statistics. Here is an example:

Beverly came to the Amazing Childcare website to evaluate whether the company would actually be useful in helping her find reliable babysitters for her family. She decides that she would like to try the product and wonders if there is a free trial available. She searches the content of the web page for the words “free trial” or “sign-up,” but is unsuccessful. She does not think the “login” button applies to her, since she is a new user and does not yet have an account. She does not think to click on the “login” button, so she fails to find the new-member sign-up interface.

In the example above, we’re using Beverly to describe feature requirements, usage statistics, and study results. The benefits of using personas to explain these components is that you are simultaneously making messy and complex details easier to understand, and forcing yourself to deeply consider who you’re really designing for. According to Alan Cooper, you should “[d]esign each interface for a single, primary persona.” Focusing on a persona like Beverly forces us to define the parameters of what our design should accomplish and helps us ultimately evaluate its success.

Keeping personas alive

Developing personas and keeping them alive can be difficult. Without regular care and feeding, they can waste away and your investment in them will be lost. In The User Is Always Right, Steve Mulder described it best:

“It’s very easy to create personas, then think your work is done. But just having personas doesn’t mean people will accept them. Just accepting the personas doesn’t mean people will remember them. Just remembering the personas doesn’t mean people will actually use them. Your job is to keep the personas alive so they show their worth.”

To ensure your personas are accepted, remembered, and used, you need to be the persona advocate on your team. As the persona advocate, you need to:

  • Regularly conduct persona research.
  • Set goals.
  • Make sure there is always a place for your personas at the design table.

With creativity and persistence, you can cultivate a suite of well-researched, battle-tested user personas.

While being a persona’s advocate may seem like a lot of work, it’s worth doing. Personas are more than just a document, they are an experience. Taking the time to draft a set of user personas, use them, evaluate them, research them, and refresh them, forces you to consider who your users are, what their goals are, and how your product fits into their lives.

If you’re ready to become the persona advocate on your team, here are some additional resources to help you along:

Books

Articles



Adapting to Input

Jeremy Keith once observed that our fixed-width, non-responsive designs were built on top of a consensual hallucination. We knew the web didn’t have a fixed viewport size, but we willfully ignored that reality because it made our jobs easier.

The proliferation of mobile devices forced us into the light. Responsive web design gave us the techniques to design for the rediscovered reality that the web comes in many sizes.

And yet there is another consensual hallucination—the idea that desktop equals keyboard and mouse, while phones equal touch.

It’s time to break free of our assumptions about input and form factors. It’s time to reveal the truth about input.

Four truths about input

  1. Input is exploding — The last decade has seen everything from accelerometers to GPS to 3D touch.
  2. Input is a continuum — Phones have keyboards and cursors; desktop computers have touchscreens.
  3. Input is undetectable — Browser detection of touch‚ and nearly every other input type, is unreliable.
  4. Input is transient — Knowing what input someone uses one moment tells you little about what will be used next.

Being adaptable

In the early days of mobile web we created pitfalls for ourselves such as “mobile context.” We’ve since learned that mobile context is a myth. People use their phones everywhere and for any task, “especially when it’s their only or most convenient option.”

When it comes to input, there is a danger of making a similar mistake. We think of a physical keyboard as being better suited to complex tasks than an onscreen keyboard.

But there are many people whose primary access to the internet is via mobile devices. Those same people are comfortable with virtual keyboards, and we shouldn’t ask them to switch to a physical keyboard to get the best experience.

Even for those of us who spend our days on computers, sometimes a virtual keyboard is better. Perhaps we’re on a plane that has started to descend. In that moment, being able to detach a keyboard and work on a touchscreen is the difference between continuing our task or stowing our laptop for landing.

So who are we to judge what input is better? We have no more control over the input someone uses than we do the size of their screen.

Becoming flexible

Confronting the truth about input can be overwhelming at first. But we’ve been here before. We’ve learned how to design for a continuum of screen sizes; we can learn how to adapt to input—starting with these seven design principles.

Design for multiple concurrent inputs

The idea that we’re either designing for desktop-with-a-mouse or touch-on-mobile is a false dichotomy. People often have access to multiple inputs at the same time. Someone using a Windows 10 laptop or a Chromebook Pixel may be able to use the trackpad and touchscreen concurrently.

There are many web pages that detect touch events and then make incorrect assumptions. Some see the touch events and decide to deliver a mobile experience regardless of form factor. Others have different branches of their code for touch and mouse and once you’re in one branch of the code, you cannot switch to the other.

At minimum, we need to ensure that our web pages don’t prevent people from using multiple types of input.

Ideally, we would look for ways to take advantage of multiple inputs used together to create better experiences and enable behavior that otherwise wouldn’t be possible.

Make web pages that are accessible

When someone uses a remote control’s directional pad to interact with a web page on a TV, the browser sends arrow key events behind the scenes. This is a pattern that new forms of input use repeatedly—they build on top of the existing forms of input.

Because of this, one of the best ways to ensure that your web application will be able to support new forms of input is to make sure that it is accessible.

The information provided to help assistive devices navigate web pages is also used by new types of input. In fact, many of the new forms of input had their beginnings as assistive technology. Using Cortana to navigate the web on an Xbox One is not so different than using voice to control Safari on a Mac.

Design for the largest target size by default

A mouse is more precise than our fingers for selecting items on a screen. Buttons and other controls designed for a mouse can be smaller than those designed for touch. That means something designed for a mouse may be unusable by someone using a touchscreen.

However, something designed for touch is not only usable by mouse, but is often easier to select due to Fitts’s Law, which says that “the time to acquire a target is a function of the distance to and size of the target.”

Plus, larger targets are easier for users with lower dexterity, whether that is a permanent condition or a temporary one caused by the environment. At the moment, the largest target size is touch, so this means designing touch first.

As Josh Clark once said, “when any desktop machine could have a touch interface, we have to proceed as if they all do.”

Design for modes of interaction instead of input types

Gmail’s display density settings illustrate the benefit of designing for user interaction instead of input types.

Gmail Interface

By default, Gmail uses a comfortable display density setting. If someone wants to fit more information on the screen, they can switch to the compact display density setting.

It so happens that these two settings map well to different types of input. The comfortable setting is touch-friendly. And compact is well suited for a mouse.

But Gmail doesn’t confine these options to a particular input. Someone using a touchscreen laptop could choose to use the compact settings. Doing so sacrifices the utility of the laptop’s touchscreen, but the laptop owner gets to make that choice instead of the developer making it for her.

Vimeo made a similar choice with their discontinued feature called Couch Mode. Couch Mode was optimized for the 10ft viewing experience and supported remote controls. But there was nothing that prevented someone from using it on their desktop computer. Or for that matter, using the standard Vimeo experience on their TV.

In both cases, the companies designed for use cases instead of a specific form factor or input. Or worse, designing for a specific input inferred from a form factor.

Abstract baseline input

When we’re working on responsive web designs at Cloud Four, we’ve found that the labels “mobile,” “tablet,” and “desktop” are problematic. Those labels create images in people’s minds that are often not true. Instead, we prefer “narrow,” “wide,” “tall,” and “short” to talk about the screens we’re designing for.

Similarly, words like “click” and “tap” betray assumptions about what type of input someone might use. Using more general terms such as “point” and “select” helps prevent us from inadvertently designing for a particular input.

We should also abstract baseline input in our code. Mouse and touch events are entirely different JavaScript APIs, which makes it difficult to write applications that support both without duplicating a lot of code.

The Pointer Events specification normalizes mouse, touch, and stylus events into a single API. This means for basic input, you only have to write your logic once.

Pointer events map well to existing mouse events. Instead of mousedown, use pointerdown. And if you need to tailor an interaction to a specific type of input, you can check the pointerType() and provide alternate logic—for example, to support gestures for touchscreens.

Pointer Events are a W3C standard and the jQuery team maintains a Pointer Events Polyfill for browsers that don’t yet support the standard.

Progressively enhance input

After baseline input has been wrangled, the fun begins. We need to start exploring what can be done with all the new input types available to us.

Perhaps you can find some innovative uses for the gyroscope like Warby Parker’s product page, which uses the gyroscope to turn the model’s head. And because the feature is built using progressive enhancement, it also works with mouse or touch.

Warby Parker UI

The camera can be used to scan credit cards on iOS or create a photo booth in browsers that support getUserMedia. Normal input forms can be enhanced with the accept attribute to capture images or video via the HTML Media Capture specification:

<input type="file" accept="image/*">
<input type="file" accept="video/*;capture=camcorder">
<input type="file" accept="audio/*;capture=microphone">

Make your forms easier to complete by ensuring they work with autofill. Google has found that users complete forms up to 30 percent faster when using autofill. And keep an eye on the Payment Request API, which will make collecting payment simple for customers.

Or if you really want to push the new boundaries of input, the Web Speech API can be used to enhance form fields in browsers that support it. And Physical Web beacons can be combined with Web Bluetooth to create experiences that are better than native.

Make input part of your test plans

Over the last few years, test plans have evolved to include mobile and tablet devices. But I have yet to see a test plan that includes testing for stylus support.

It makes intuitive sense that people check out faster when using autofill, but none of the ecommerce projects that I’ve worked on have verified that their checkout forms support autofill.

We need to incorporate input in our test plans. If you have a device testing lab, make input one of the criteria you use to determine what new devices to purchase. And if you don’t have a device testing lab, look for an open device testing lab near you and consider contributing to the effort.

The way of the web

Now is the time to experiment with new forms of web input. The key is to build a baseline input experience that works everywhere and then progressively enhance to take advantage of new capabilities of devices if they are available.

With input, as with viewport size, we must be adaptable. It is the way of the web.



The Itinerant Geek

This spring I spent almost a month on the road, and last year I delivered 26 presentations in eight different countries, spending almost four months traveling. While doing all of this I am also running a business. I work every day that I am on the road, most days putting in at least six hours in addition to my commitments for whichever event I am at. I can only keep up this pace because travel is not a huge stressor in my life. Here are some things I have learned about making that possible, in the hope they are useful to anyone setting off on their first long trip. Add your own travel tips in the comments.

Before you go

During the run-up to going away, I stay as organized as possible. Otherwise I would lose a lot of time just preparing for the trips. I have a Trello board set up with packing list templates. I copy a list and remove or add anything specific to that trip. Then I can just grab things without thinking about it and check them off. I also use Trello to log the status of plans for each trip; for example, do I have a hotel room and flights booked? Is the slide deck ready? Do I know how I am getting from the airport to the hotel? This way I have instant access to the state of my plans and can also share this information if needed.

It is easy to think you will always have access to your information in its original form. However, it is worth printing a copy of your itinerary to keep with you just in case you can’t get online or your phone battery runs out. For times when you don’t have physical access to something at the moment, take photos of your passport and car insurance (if it covers rentals), and upload them somewhere secure.

Your travel may require a visa. If your passport is expiring within six months of your trip, you may want to get a new one — some countries won’t issue a visa on a passport that is due to expire soon. You can in some cases obtain pre-authorization, such as through the American ESTA form for participating in its Visa Waiver Program. This might have changed since your last trip. For example, Canada has introduced an eTA system as of March 2016. I’ve traveled to Canada for ConFoo for the last four years - if I attend next year, I’ll need to remember to apply for this beforehand.

Tell your bank and credit card company that you are traveling to try and avoid their blocking your card as soon as you make a purchase in your destination.

Make sure you have travel insurance that covers not only your possessions but yourself as well. Be aware that travel insurance will not pay out if you become sick or injured due to an existing condition that you didn’t tell them about first. You will have to pay an increased premium for cover of an existing issue, but finding yourself with no cover and far from home is something you want to avoid.

Make sure that you have sufficient of any medicine that you need. Include some extra in case of an unscheduled delay in returning home. I also usually pack a few supplies of common remedies - especially if I am going somewhere that is not English speaking. I have a vivid memory of acting out an allergic reaction to a Polish pharmacist to remind me of this!

I also prepare for the work I’ll be doing on the road. In addition to preparing for the talks or workshops I might be giving, I prepare for work on Perch or for the business. I organize my to-do list to prioritize tasks that are difficult to do on the road, and make sure they are done before I go. I push tasks into the travel period that I find easier on the small screen of my laptop, or that I can complete even in a distracting environment.

When booking travel, give yourself plenty of time. If you are short of time then every delay becomes stressful, and stress is tiring. Get to the airport early. Plan longer layovers than the 70 minutes your airline believes it will take you to deplane from the first flight and make it round a labyrinthine nightmare from the 1980s to find the next one. On the way home from Nashville, my first plane was delayed due to the inbound flight having to change equipment. The three-hour layover I had chosen meant that even with almost two hours of delay I still made my transatlantic leg home in time. Travel is a lot less stressful if you allow enough time for things to go wrong.

Air travel tips

Try to fly with the same airline or group in order to build up your frequent flyer status. Even a little bit of “status” in an airline miles program will give you some perks, and often priority for upgrades and standby tickets.

If you want to take anything of significant size onto the aircraft as hand luggage, the large roller bags are often picked out to be gate-checked on busy flights. I travel with a Tom Bihn Aeronaut bag, which I can carry as a backpack. It is huge, but the gate staff never spot it and due to being soft-sided, it can squash into the overhead compartments on the smaller planes that are used for internal U.S. flights.

Have in your carry-on an overnight kit in case your checked luggage does not make it to your destination at the same time as you do. Most of the time you’ll find your bag comes in on the next flight and will be sent to your hotel, but if you need to get straight to an event it adds stress to be unable to change or brush your teeth.

If you plan to work on the flight, charge your laptop and devices whenever you can. More and more planes come with power these days - even in economy - but it can’t be relied on. I have a BatteryBox, a large external battery. It’s a bit heavy but means I can work throughout a 10-hour flight without needing to plug in.

On the subject of batteries, airlines are becoming increasingly and understandably concerned about the fire risk posed by lithium ion batteries. Make sure you keep any spare batteries in your hand luggage and remove them if your bag is gate-checked. Here is the guide issued by British Airways on the subject.

A small flat cool bag, even without an icepack, works for a good amount of time to cool food you are bringing from airside as an alternative to the strange offerings onboard. I usually pop a cold water bottle in with it. London Heathrow T5 has a Gordon Ramsay “Plane Food” restaurant that will make you a packed lunch in a small cool bag to take on the plane!

Get lounging

Airport lounges are an oasis. Something I didn’t realize when I started traveling is that many airport lounges are pay on entry rather than being reserved for people with higher class tickets or airline status. If you have a long layover then the free drinks, wifi, power, and snacks will be worth the price - and if it means you can get work done you can be making money. The LoungeBuddy app can help you locate lounges that you can access whether you have airline status or not.

There is another secret to airline lounges: they often have a hotline to the airline and can sort out your travel issues if your flight is delayed or canceled. With the delayed flight in my last trip I checked myself into the American Airlines lounge, mentioning my delay and concern for the ongoing leg of the flight. The member of staff on the desk had the flight status checked and put me on standby for another flight “just in case.” She then came to let me know - while I happily sat working in the lounge - that it all looked as if it would resolve in time for me to make my flight. Once again, far less stressful than trying to work this out myself or standing in a long line at the desk in the airport.

Looking after yourself

If you do one or two trips a year then you should just relax and enjoy them - eat all the food, drink the drinks, go to the parties and forget about your regular exercise routine. If you go to more than 20, you won’t be able to do that and also do anything else. I quickly learned how to pace myself and create routines wherever I am that help to bring a sense of normal life to hotel living.

I try as much as possible to eat the same sort of food I usually eat for the majority of the time - even if it does mean I’m eating alone rather than going out for another dinner. Hotel restaurants are used to the fussiest of international travelers and will usually be able to accommodate reasonable requests. I do a quick recce of possible food options when I arrive in a location, including places I can cobble together a healthy packed lunch if the conference food is not my thing. I’ll grab a sparkling water from the free bar rather than another beer, and I’ll make use of the hotel gym or go for a run to try and keep as much as possible to the training routine I have at home. I do enjoy some great meals and drinks with friends - I just try not to make that something that happens every night, then I really enjoy those I do get to.

I’m fortunate to not need a lot of sleep, however I try to get the same amount I would at home. I’ve also learned not to stress the time differences. If I am doing trips that involve the East and West Coast of America I will often just remain on East Coast time, getting up at 4am rather than trying to keep time-shifting back and forth. If you are time-shifting, eating at the right time for where you are and getting outside into the light can really help. The second point is not always easy given the hotel-basement nature of many conference venues. I tend to run in the morning to remind myself it is daytime, but just getting out for a short walk in the daylight before heading into the event can make a huge difference.

I take care to wash my hands after greeting all those conference-goers and spending time in airports and other places, and am a liberal user of wet wipes to clean everything from my plane tray table to the hotel remote control. Yes, I look like a germaphobe, however I would hate to have to cancel a talk because I got sick. Taking a bit of care with these things does seem to make a huge difference in terms of the number of minor illnesses I pick up.

Many of us in this industry are introverts and find constant expectation to socialize and be available tiring. I’m no exception and have learned to build alone time into my day, which helps me to be more fully present when I am spending time with other speakers and attendees. Even as a speaker at an event, when I believe it is very important for me to be available to chat to attendees and not to just vanish, this is possible. Being at a large number of events I often have seen the talks given by other speakers, or know I can catch them at the next event. So I will take some time to work or relax during a few sessions in order to make myself available to chat during the breaks.

If you are taking extended trips of two weeks or more these can be hugely disruptive to elements of your life that are important to your wellbeing. That might be in terms of being unable to attend your place of worship, meet with a therapist, or attend a support group meeting. With some thought and planning you may be able to avoid this becoming an additional source of stress - can you find a congregation in your location, use Skype to meet with your therapist, or touch base with someone from your group?

Working on the road

Once at your destination, getting set up to work comfortably makes a huge difference to how much you can get done. Being hunched over a laptop for days will leave you tired and in pain. My last trip was my first with the new and improved Roost Stand, along with an external Apple keyboard and trackpad. The Roost is amazing; it is incredibly light and allowed me to get the laptop to a really great position to work properly.

Plan your work periods in advance and be aware of what you can do with no, or limited internet connectivity. In OmniFocus I have a Context to flag up good candidates for offline work, and I also note what I need to have in order to do that work. I might need to ensure I have a copy of some documentation, or to have done a git pull on a repository before I head into the land of no wifi. I use Dash for technical documentation data sets when offline. On a ten-hour flight with no wifi you soon realize just how much stuff you look up every day!

If traveling to somewhere that is going to be horribly expensive for phone data, do some research in advance and find out how to get a local pay-as-you-go sim card. If you want to switch that in your phone, you need to have an unlocked phone (and also the tools to open your phone). My preferred method is to put the card into a mobile broadband modem, then connect my phone to that with the wifi. This means I can still receive calls on my usual number.

The possibility of breaking, losing, or having your laptop stolen increases when it isn’t safely on your desk in the office. Have good insurance, but also good backups. During conferences, we often switch off things like Dropbox or our backup service in order to preserve the wifi for everyone - don’t forget you have done this! As soon as you are able, make sure your backups run. My aim is always to be in a position where if I lost my laptop, I could walk into a store, buy a new one and be up and running within a few hours without losing my work, and especially the things I need to present.

Enjoy the world!

Don’t forget to also plan a little sightseeing in the places you go. I would hate to feel that all I ever saw of these places was the airport, hotel, and conference room. I love to book myself on a walking tour. You can discover a lot about a city in a few hours the morning before your flight out, and there are always other lone business travelers on these tours. I check Trip Advisor for reviews to find a good tour. Lonely Planet have “Top things to do in…” guides for many cities: here is the guide for Paris. I’ll pick off one item that fits into the time I have available and head out for some rapid tourism. As a runner I’m also able to see many of the sights by planning my runs around them!

Those of us to get to travel, who have the privilege of doing a job that can truly be done from anywhere, are very lucky. With a bit of planning you can enjoy travel, be part of events, and still get work done and remain healthy. By reducing stressful events you do have control over, you can be in better shape to deal with the inevitable times you do not.



Strategies for Healthier Dev

Not too long ago, I was part of a panel at the launch event for TechLadies, an initiative that encourages women to learn to code. Along the way, I mentioned a bit about my background as an athlete. As we were leaving to go home, the woman next to me jokingly asked if I was a better basketball player or a better developer. Without missing a beat, I said I was a better basketball player. After all, I’ve been playing basketball for over half my life; I’ve only been coding for two and a half years.

We’ve probably all come across the stereotype of the nerdy programmer who is all brains and no brawn. I’m a counterexample of that cliché, and I personally know developers who are avid cyclists or marathon runners—even a mountain climber (the kind who scales Mount Everest). And yet a stereotype, “a widely held but fixed and oversimplified image,” often comes into existence for a reason. Think of Douglas Coupland’s Microserfs. Think of any number of mainstream dramas featuring wan (usually white, usually male) programmers staring at screens. Many so-called knowledge workers are too sedentary. Our lives and work stand to benefit if we become less so.

Now, no one likes to suffer. And yet when it comes to exercise or training, it’s too easy for us to think that fitness is all about self-discipline—that we just need to have the willpower to persevere through the agony. But that’s not a good strategy for most people. Unless you genuinely find pleasure in pain and suffering, you have to want something badly enough to endure pain and suffering. Ask any athlete if they enjoy running extra sprints or lifting extra weights. Even Olympic medalists will tell you they don’t. They do it because they want to be the best.

My point is this: forcing yourself to do something you don’t enjoy is not sustainable. I’ll be the first to admit that I’m not a big fan of running. A little ironic coming from someone who used to play basketball full-time, maybe, but the only reason I did any running at all, ever, was because competitive basketball required me to. When I stopped training full-time, I simply couldn’t muster the energy or motivation to get up and run every day (or even every week, for that matter).

So I had to come up with a different game plan—one that required minimal effort, near-zero effort, and minor effort. You can do it, too. No excuses. Ready?

Minimal effort

I’m lazy.

I’m pretty good at talking myself out of doing things that require extra effort to get ready for. For example, going swimming requires that I pack toiletries, a fresh set of clothes, and goggles. Then I actually need to make it to the pool after work before it closes, which means I have to plan to leave the office earlier than I usually might, and so on. Guess what? Eight out of ten times, I end up telling myself to go swimming next time.

By contrast, I commute to work on my bicycle. Yes, it helps that I love to ride. I thoroughly enjoy swimming, too—just not enough to overcome my laziness. But because cycling is my main mode of transportation, I don’t even think about it as exercise. It’s just something I do as part of my day, like brushing my teeth.

The “while-you’re-at-it” technique works very well for me, and maybe it’ll work for you, too. In a nutshell: build healthy habits into things you already do. Kind of how parents hide vegetables in more palatable stuff to get their kids to eat them.

Near-zero effort

Let me list some simple activities that involve minimal effort, but have significant returns on investment. Consider these the minimum viable products (MVPs) of healthy habits.

Drink more water

Most of us have been told to drink eight glasses of water a day, but how many of us actually drink that much? The real amount of water people need on a daily basis seems debatable, but I’m going to make the bold assumption that most of us don’t drink more than one liter (or around four glasses) of water a day. And no, coffee doesn’t count.

This means that most of us operate in a mildly dehydrated state throughout the day. Studies done on both men and women have shown that mild dehydration negatively impacts one’s mood and cognitive function. Given that our work requires significant mental acuity, upping our water intake is a minimal-effort lifehack with significant benefits.

Note that people often mistake thirst for hunger. Studies have shown that we’re notoriously bad at distinguishing the two. Assuming that most of us probably don’t drink enough water throughout the day, odds are that you’re not really hungry when you reach for a snack. In fact, you’re probably thirsty. Don’t grab a can of soda, though—drink water.

Move more

A study done on the effects of sedentary behavior revealed that long periods of inactivity increase one’s risk of diabetes and heart disease. The study also mentioned that encouraging individuals simply to sit less and move more, regardless of intensity level, may improve the effectiveness of diabetes-prevention programs.

Think about how you can incorporate more movement into your routine. Try drinking water throughout the day. Not only will this reinforce the “drink more water” habit, but you’ll also find that you need to get up to go to the bathroom more often. And going to the bathroom is…movement. Note: do not refuse to go to the bathroom because you think you’re “on the brink” of solving a bug. That’s a lie you tell yourself.

Since you’re getting up and sitting down more often, you might as well sneak some exercise in while you’re at it. Instead of plonking down in your seat when you get back, lower yourself slowly over the course of five seconds until your butt touches your chair. You’re building leg muscles! Who needs a gym? The point is, all the little things you do to increase movement add up.

Don’t eat while you work

It might surprise you to know that being aware of what you put in your mouth—and when you put it there—makes a difference. I know many people, not only developers, who eat lunch at their desks, balancing a spoonful of food in one hand while continuing to type with the other. Lunch becomes something that’s shoveled into our mouths and (maybe, if we have time) swallowed. That’s no way to appreciate a meal. Make lunchtime a logical break between your coding sessions. Some folks may protest that there’s just no time to eat: we have to code 20 hours a day!

First of all, it’s impossible to be efficient that way. A study (PDF) from the University of Illinois at Urbana-Champaign has shown that taking a deliberate break can reboot focus on the task at hand. It offsets our brain’s tendency to fall into autopilot, which explains why we can’t come up with good solutions after continuously staring at a bug for hours. Tom Gibson wrote a beautiful post explaining how human beings are not linear processes. We are still operating on an industrial model where emphasis is placed on hours worked, not output achieved.

We need to aim for a healthy “Work Rate Variability” and develop models of working that stop making us ill, and instead let us do our best.
Tom Gibson

Also, by actually bothering to chew your food before swallowing, you eat more slowly. Research has shown that eating slowly leads to lower hunger ratings and increased fullness ratings. Chances are you’ll feel healthier overall and gain a fresh sense of perspective, too, by giving yourself a proper lunch break. Such is the power of minimal effort.

Use a blue-light filter at night

Personally, I’m a morning person, but most of my developer friends are night owls. Everybody functions best at different times of the day, but if you’re someone who operates better at night, I recommend installing f.lux on your desktop and mobile devices. It’s a tiny application that makes the color of your computer’s display adapt to ambient light and time of day.

Melatonin is a hormone that helps maintain the body’s circadian rhythms, which determine when we sleep and wake up. Normally, our bodies produce more melatonin when it gets dark. Scientists have found that exposure to room light in the evening suppresses melatonin during normal sleep hours. Research on the effects of blue light has shown that blue light suppresses sleep-associated delta brainwaves while stimulating alertness. Because it doesn’t make sense, given socioeconomic realities, to ask people to stop working at night, the best alternative is to reduce exposure to blue light.

Minor effort required

If you’ve already started incorporating zero-effort health habits into your life, and feel like putting in a bit more effort, this section outlines tactics that take a little more than zero effort.

Walk

When I started writing code, I found myself glued to my chair for hours on end. You know that feeling when you’re debugging something and obstinately refuse to let that bug get the better of you? But I realized that my efficiency decreased the longer I worked on something without stopping. I can’t tell you how many times I worked on a bug till I threw my hands up in frustration and went for a walk, only to have the solution come to me as I strolled outside enjoying the breeze and a change of scenery.

Walking doesn’t require any additional planning or equipment. Most of us, if we’re lucky, can do it without thinking. The health benefits accrued include a reduction of chronic diseases like stroke and heart disease. Try this: as part of your attempt to have a better lunch break, take a walk after you’ve properly chewed and swallowed your lunch. It limits the increase of blood sugar levels immediately after a meal. You’ll get fitter while you’re at it.

Stretch

I don’t know about you, but sitting for long periods of time makes my hips feel tight and my back tense up. The scientific research on the exact effects of sitting on the structural integrity of your hip flexors seems to be inconclusive, but I know how I feel. A lot of us tend to slouch in our chairs, too, which can’t be good for our overall posture.

If you find yourself craning your neck forward at your desk, with your shoulders up near your ears and back rounded forward, news flash! You have terrible posture. So what can you do about it? Well, for starters, you can refer to a handy infographic from the Washington Post that summarizes the ills of bad posture. The TL;DR: bad posture negatively affects your shoulders, neck, hips, and especially your back.

Slouching for prolonged periods causes the soft discs between our vertebrae to compress unevenly. If you take a sponge and place a weight on one side of it and leave it there for hours, the sponge will warp. And that’s exactly what happens to our discs. As someone who has suffered from a prolapsed disc, I can tell you that back trouble no fun at all.

Here’s another thing you can do: stretch at your desk. You don’t have to do all of these exercises at once—just sprinkle them throughout your work day. The improved blood circulation will be a boon for your brain, too.

Sleep

Most of us don’t get enough sleep. I hardly know anyone under the age of 12 who goes to bed before 11 p.m. Maybe that’s just the company I keep, but there are lots of reasons for not getting enough sleep these days. Some of us work late into the night; some of us game late into the night. Some of us care for children or aging parents, or have other responsibilities that keep us up late. I live in Singapore, which ranks third on the list of cities clocking the fewest hours of sleep: six hours and 32 minutes.

Sleep deprivation means more than just yawning all the time at work. Research has shown that the effects of sleep deprivation are equivalent to being drunk. Insufficient sleep affects not only your motor skills, but also your decision-making abilities (PDF) and emotional sensitivity (PDF). You become a dumb, angry troll when sleep-deprived.

Changing your sleep habits takes some effort. The general advice is to sleep and wake up at the same time each day, and to try to aim for seven and a half hours of sleep. According to Professor Richard Wiseman, a psychology professor at the University of Hertfordshire, our sleep cycles run in 90-minute intervals. Waking up in the middle of those cycles makes us groggy. Wiseman offers tips on how to sleep better.

Resistance training

By “resistance training,” I don’t mean hefting iron plates and bars at the gym (though if you like to do that, more power to you). If you enjoy the privilege of able-bodiedness, try to make vigorous physical movement part and parcel of your daily life. Ideally, you’ll have the basic strength and coordination to run and jump. And to be able to get right up without much effort after falling down. You don’t have to be an elite athlete—that’s a genetic thing—but with luck, you’ll be able to perform at least some basic movements.

Our own body weight is plenty for some rudimentary exercises. And it doesn’t matter if the heaviest weight you’re willing to lift is your laptop and you couldn’t do a push-up if your life depended on it. There are progressions for everyone. Can’t do a push-up on the ground? Do a wall push-up instead. Can’t do a basic squat? Practice sitting down on your chair very slowly. Can’t run? Take a walk. (Yes, walking is a form of resistance training). And so on.

There are two websites I recommend checking out if you’re interested in learning more. The first is Nerd Fitness by Steve Kamb. He and I share a similar philosophy: small changes add up to big results. He covers topics ranging from diet to exercise and offers lots of resources to help you on your journey. Another site I really love is GMB fitness. It teaches people how to move better, and to better understand and connect with their bodies.

Wrapping up: slow & steady

There is only one way to build new habits: consistency over time. That’s why it’s so important to do things that take minimal effort. The less effort an action requires, the more likely you are to do it consistently. Also: try not to make drastic changes to all aspects of your life at once (though that may be effective for some). Regardless of whether you mind change in your life or not, almost any change introduces stress to your system. And even constant low-grade stress is detrimental. It’s better to start small, with minor changes that you barely feel; once that becomes a habit, move on to the next change.

We spend hours maintaining our code and refactoring to make it better and more efficient. We do the same for our computers, optimizing our workflows and installing tweaks to eke out those extra seconds of performance. So it’s only right that we put a little effort into keeping our bodies reasonably healthy. Fixing health problems usually costs more than fixing bugs or machines—and often the damage is irreversible. If we want to continue to write great code and build cool products, then we should take responsibility for our health so that we can continue to do what we love for decades to come.





 
 
 
 
 

Affiliates

Dr Quincy Photoshop Tutorials
Tutorial Man Wallpaper Stock  More

Resources