A List Apart

  1. How People Perceive Lossy Image Quality: A Study

    The notion that lossy image quality is subjective is not an unreasonable hypothesis. There are many factors that play into how humans perceive quality: screen size, image scaling, and yes, even performance.

    Many research projects have tackled this subject, but I’ve recently launched a survey that attempts to understand how people perceive image quality in a slightly different way: in the context of performance.

    This image quality assessment serves up 25 different specimens, each of which is presented in a random lossy quality setting between 5 and 100, in both JPEG and WebP formats. As participants complete the survey, navigation, resource and paint timings are collected (when available) from the browser, as well as other client details such as a device’s resolution, pixel density, and many other pertinent details.

    The real work of gathering data begins. This is where you can help out. If you have five to ten minutes to spare, please head over to https://imagesurvey.site and participate. When the survey is finished, I’ll post the raw data and write and article (or two) on the findings. If further experimentation is required, that will be pursued as well. I don’t know what we’ll find out, but we’ll find out together with your input. So please participate!

    Thank you!

    Note: If you have feedback for how to improve the survey, feel free to comment! Just be aware that your feedback can’t be implemented in this run of the survey, but it could be useful in constructing any follow-up surveys.

  2. The Ten Essentials for Good API Documentation

    API documentation is the number one reference for anyone implementing your API, and it can profoundly influence the developer experience. Because it describes what services an application programming interface offers and how to use those services, your documentation will inevitably create an impression about your product—for better or for worse.

    In this two-part series I share what I’ve learned about API documentation. This part discusses the basics to help you create good API docs, while in part two, Ten Extras for Great API Documentation, I’ll show you additional ways to improve and fine-tune your documentation. 

    Know your audience

    Knowing who you address with your writing and how you can best support them will help you make decisions about the design, structure, and language of your docs. You will have to know who visits your API documentation and what they want to use it for. 

    Your API documentation will probably be visited and used by the following audiences. 


    Based on their skills, experience, and role in projects, developers will generally be the largest and most diverse group. They’ll be using your docs in different ways.

    At Pronovix, we started conducting developer portal workshops with our clients to help them learn more about what developers need and how to best support their work—and what they’re really looking for in API documentation. This is also supported by solid research, such as the findings published in Stephanie Steinhardt’s article following a two-year research program at Merseburg University of Applied Sciences.

    Newcomers: Developers lacking previous experience with your API tend to need the most support. They will take advantage of quickstart guides that encourage them to start using your API—clear, concise, step-by-step tutorials for the most important topics, and sample code and examples to help them understand how to use it in real projects. If you can make onboarding pleasant for newcomers, they will be more likely to devote themselves to learning every nuance of your API.

    External developers: Developers already working with your API will come back repeatedly to your docs and use them as reference material. They will need quick information on all the functionality your API offers, structured in an easy to understand way to help them quickly find what they need.

    Debuggers: Developers using your API will encounter errors from time to time and use your documentation to analyze the responses and errors that crop up.

    Internal developers: API providers tend to focus so much on their external audience that they forget about their own developers; internal teams working on the API will use the API documentation, as well.

    These are just the most common use cases.

    Decision makers

    Decision makers like CTOs and product managers will also check out your API documentation and evaluate your API. They need to determine whether your API will be a good fit for their project or not, so it’s crucial to your business that this group can easily and quickly find what they’re looking for.

    Other audiences

    Although not as common, journalists, technical writers, support staff, developer evangelists, and even your competition might read your API documentation. 

    Remember the purpose of documentation

    The foundation of your API documentation is a clear explanation of every call and parameter.

    As a bare minimum, you should describe in detail:

    • what each call in your API does
    • each parameter and all of their possible values, including their types, formatting, rules, and whether or not they are required.

    Context-based structure

    People won’t read your API documentation in order, and you can’t predict which part they will land on. This means, you have to provide all the information they need in context. So following the best practices of topic-based authoring, you should include all necessary and related information in the explanation of each call.

    Context.IO, for example, did a great job documenting each of their API calls separately with detailed information on parameters and their possible values, along with useful tips and links to related topics.


    In order to be able to implement your API, developers need to understand it along with the domain it refers to (e.g., ecommerce). Real world examples reduce the time they need to get familiar with your product, and provide domain knowledge at the same time.

    Add the following to the description of each call:

    • an example of how the call is made
    • an explanation of the request
    • sample responses

    Studies have shown, that some developers immediately like to delve into coding, when getting to know a new API; they start working from an example. Analysis of eye-tracking records showed that visual elements, like example code, caught the attention of developers who were scanning the page, rather than reading it line by line.  Many looked at code samples before they started reading the descriptions.

    Using the right examples is a surefire way to improving your API docs. I’ll explore ways to turn good API docs into great ones using examples in my upcoming post “Ten Extras for Great API Documentation”.

    Error messages

    When something goes wrong during development, fixing the problem without detailed documentation can become a frustrating and time-consuming process. To make this process as smooth as possible, error messages should help developers understand:

    • what the problem is;
    • whether the error stems from their code or from the use of the API;
    • and how to fix the problem.

    All possible errors—including edge cases—should be documented with error-codes or brief, human-readable information in error messages. Error messages should not only contain information related to that specific call, but also address universal topics like authentication or HTTP requests and other conditions not controlled by the API (like request timeout or unknown server error).

    This post from Box discusses best practices for server-side error handling and communication, such as returning an HTTP status code that closely matches the error condition, human-readable error messages, and machine-readable error codes.

    Quickstart guide

    Newcomers starting to implement your API face many obstacles:

    • They are at the beginning of a steep learning curve
    • They might not be familiar with the structure, domain, and ideas behind your API
    • It’s difficult for them to figure out where to start.

    If you don’t make the learning process easier for them, they can feel overwhelmed and refrain from delving into your API. 

    Many developers learn best by doing, so a quickstart guide is a great option. The guide should be short and simple, aimed at newcomers, and list the minimum number of steps required to complete a meaningful task (e.g., downloading the SDK and saving one object to the platform). Quickstart guides usually have to include information about the domain and introduce domain-related expressions and methods in more detail. It’s safest to assume that the developer has never before heard of your service.

    Stripe’s and Braintree’s quickstart guides are great examples; both provide an overview of the most likely tasks you’ll want to perform with the API, as well as link you to the relevant information. They also contain links to contact someone if you need help.


    Tutorials are step-by-step walkthroughs covering specific functionality developers can implement with your API, like SMS notifications, account verification, etc.

    Tutorials for APIs should follow the best practices for writing any kind of step-by-step help. Each step should contain all the information needed at that point—and nothing more. This way users can focus on the task at hand and won’t be overloaded with information they don’t need.

    The description of steps should be easy to follow and concise. Clarity and brevity support the learning process, and are a best practice for all kinds of documentation. Avoid jargon, if possible; users will be learning domain-related language and new technology, and jargon can instill confusion. Help them by making all descriptions as easy to understand as possible. 

    The walkthrough should be the smallest possible chunk that lets the user finish a task. If a process is too complex, think about breaking it down into smaller chunks. This makes sure that users can get the help they need without going through steps they’re not interested in.

    Screenshot of Twilio's tutorials page
    Twilio’s tutorials explain the most-likely use cases with sample apps in a wide variety of programming languages and frameworks.

    Universal topics

    To implement your API, there are some larger topics that developers will need to know about, for example:

    • Authentication. Handled differently by each type of API, authentication (e.g., OAuth) is often a complicated and error-prone process. Explain how to get credentials, how they are passed on to the server, and show how API keys work with sample code.
    • Error handling. For now, error handling hasn’t been standardized, so you should help developers understand how your API passes back error information, why an error occurs, and how to fix it.
    • HTTP requests. You may have to document HTTP-related information as well, like content types, status codes, and caching.

    Dedicate a separate section to explaining these topics, and link to this section from each related API call. This way you can make sure that developers clearly see how your API handles these topics and how API calls change behavior based on them. 

    Layout and navigation

    Layout and navigation are essential to user experience, and although there is no universal solution for all API docs, there are some best practices that help users interact with the material.

    Dynamic layout

    Most good examples of API documentation use a dynamic layout as it makes navigation easier for users than static layouts when looking for specific topics in extensive documentation. Starting with a scalable dynamic layout will also make sure you can easily expand your docs, as needed.

    Single page design

    If your API documentation isn’t huge, go with a single page design that lets users see the overall structure at first sight. Introduce the details from there. Long, single page docs also make it possible for readers to use the browser’s search functionality.

    Screenshot of Stripe's API reference page
    Stripe managed to present extensive documentation in an easy to navigate single page.

    Persistent navigation

    Keep navigation visible at all times. Users don’t want to scroll looking for a navigation bar that disappeared.

    Multi-column layout

    2- or 3-column layouts have the navigation on the left and information and examples on the right. They make comprehension easier by showing endpoints and examples in context.

    Screenshot of Clearbit's API reference page
    Clearbit’s three-column layout displays persistent navigation (table of contents) on the left, references in the middle, and code examples on the right.

    Syntax highlighter

    Improving the readability of samples with syntax highlighting makes the code easier to understand.

    Screenshot of Plaid's API documentation page
    The syntax highlighter in action on Plaid’s API documentation site.

    If you’d like to start experimenting with a layout for your docs, you might want to check out some free and open source API documentation generators.

    To learn about the pros and cons of different approaches to organizing your API docs in the context of developer portals, this is an excellent article by Nordic APIs.


    All writing that you publish should go through an editing process. This is common sense for articles and other publications, but it’s just as essential for technical documentation.

    The writers of your API docs should aim for clarity and brevity, confirm that all the necessary information is there, and that the structure is logical and topics aren’t diluted with unnecessary content. 

    Editors should proofread your documentation to catch grammar mistakes, errors, and any parts that might be hard to read or difficult to understand. They should also check the docs against your style guide for technical documentation and suggest changes, if needed.

    Once a section of documentation is ready to be published, it’s a good idea to show it to people in your target audience, especially any developers who haven’t worked on the documentation themselves. They can catch inconsistencies and provide insight into what’s missing.

    Although the editing process can feel like a burden when you have to focus on so many other aspects of your API, a couple of iterations can make a huge difference in the final copy and the impression you make.

    Keep it up-to-date

    If your API documentation is out of date, users will get frustrated by bumping into features that aren’t there anymore and new ones that lack documentation. This can quickly diminish the trust you established by putting so much work into your documentation in the first place.

    When maintaining your API docs, you should keep an eye on the following aspects:

    • Deprecated features. Remove documentation for deprecated features and explain why they were deprecated.
    • New features. Document new features before launch, and make sure there’s enough time planned for the new content to go through the editorial process.
    • Feedback. Useful feedback you get from support, or analytics should be reflected in your docs. Chances are you can’t make your docs perfect at the first try, but based on what users are saying, you can improve them continuously.

    For all this to work, you will have to build a workflow for maintaining your documentation. Think about checkpoints and processes for the above mentioned aspects, editing, and publication. It also helps if you can set up a routine for reviewing your docs regularly (e.g. quarterly).

    Following these best practices, you can build a solid foundation for your API documentation that can be continuously improved upon as you gain more insight into how users interact with them. Stay tuned for part two, where I give you some tips on how to turn good API docs into amazing ones.

  3. Project Management for Humans

    A note from the editors: We’re pleased to share an excerpt from Chapter 6 of Brett Harned's new book, Project Management for Humans, available now from Rosenfeld Media.

    I loved the game Tetris as a kid. I played the Game Boy version for hours. It’s easy to get wrapped up in the concept of little shapes coming together in a logical way to clear a goal. The pieces complement one another, yet they all naturally work in different ways. The game has stuck with me since I was a kid (and, no, I’m not a gamer). I now have it on my phone and iPad and find myself playing it when I’m on a flight or bored, waiting for something to happen (which is never these days). Whether I’m playing the game a lot or not, the idea of making tiny boxes fit in neatly and clearing out rows of work is ingrained in my brain. It’s the project manager in me.

    But here’s the thing: What project managers do on a daily basis when it comes to managing resources or staffing is similar to Tetris, and it’s a big project management challenge that we all face. The biggest difference between resourcing and Tetris? The team members we’re trying to assign tasks to aren’t blocks. They’re human beings, and they need to be treated as such.

    Your Team Are People, Too!

    Let’s move away from calling people “resources,” please. We’re really just staffing projects or assigning tasks. We’re not using people to just get things done. We’re asking them to solve challenges that are presented in our projects.

    Set the Stage for Organized Resource Planning

    The challenge of managing a team is making sure that they stay busy and working on tasks, yet are not completely overbooked. It’s a difficult balance to find, particularly when your projects require a variety of skills at different times, which seem to change all too often.

    At the most basic level, you want to set up a system for tracking your projects and your team members’ time on those projects (see Figure 6.1). A simple goal is to ensure that you can confidently commit to deadlines on projects with the knowledge that your team is actually available to do the related work. It seems like a simple goal, but it’s often a difficult one to keep up with due to changes on projects, changes in personal schedules (hey, life happens), and an influx of new work and requests. But it’s not an insurmountable challenge. In fact, a simple spreadsheet could help you, particularly if you’re managing a smaller team. At the core, you want to track these items:

    • Projects (List them all, even the non-billable ones, or the other things that aren’t projects but end up taking a lot of time—like business development.)
    • People (List every person you work with.)
    • Estimated time (Track hours, days, weeks, etc. Make your best guess—based on your timeline or calendar—on how much each person will spend on a project or a task.)
    Spreadsheet showing each person as a column header, with rows corresponding to different tasks, all totaled at the bottom.
    Figure 6.1: Use a Google Spreadsheet, Numbers, or Excel to input your project and team data.

    A couple of notes on how to use a spreadsheet to forecast team availability:

    • This should be set up on a week-by-week basis to minimize confusion (use tabs in your spreadsheet for each new week).
    • Always consider the “nonbillable” things that people must do (like stand-up meetings, internal tasks, sales, etc.).
    • The final cell contains a formula that tallies the hours for you; if the hours go over your typical limit (think of a 40-hour work week), it will turn red to notify you. You’ll want to have a good idea for just how “utilized” someone should be (32 hours/week is usually a good target).
    • You can input the actual hours logged in your time tracking system if you’d like. It could help with future estimating. (If you’re not tracking time, check in with your team on time percentages to get a gut check.)
    • Check your estimates with your team to make sure that the hours actually align with their assessment of the task (This might help with avoiding that red number!)
    • Communicate these hours to the entire team each week. Making sure that everyone “is in the know” will help on any project. Discussing it with individuals will help you understand effort, blockers, and possibly even different ways of working.


    The landscape for project management tools is changing constantly. There are a number of tools in the marketplace for helping you manage and communicate this data. If you’ve working with a team of 10 or more, you might want to abandon the spreadsheet approach for something more official, organized and supported. Bonus: Many of these tools handle more than just resourcing!

    Here’s the thing—it’s not just about numbers. The issue that makes estimating a team’s project hours difficult is that everyone works differently. There is no way to standardize the human factor here, and that’s what makes it tough. Forget the fact that no one on your team is a robot, and they all work at their own pace. Think about sick days, vacations, client delays, changes on projects, and so on. It’s a never-ending flow of shapes that must fit into the box that is a project. Be sure to have an ongoing dialogue about your staffing plans and challenges.

    Match Resource Skills to Projects

    Projects only slow down when decisions are not made. In that magical moment when things are actually going well, you want to make sure that your team can continue the pace. The only way to do that is by connecting with your team and understanding what motivates them. Here are some things to consider:

    • Interests: If you have a team member who loves beer, why not put that person on the beer design site? Maybe you have multiple people who want to be on the project, but they are all busy on other projects. These are the breaks. You’ve got to do what is right for the company and your budget. If you can put interests first, it’s awesome. It won’t always work out that way for everyone, but it’s a good first step to try.
    • Skill sets: It’s as simple as getting to know each and every team member’s work. Some people are meant to create specific types of designs or experiences. It not only has to do with interests, but it also has to do with strengths within those tasks. Sure, I may love beer, but that doesn’t mean that I am meant to design the site that caters to the audience the client is trying to reach.
    • Moving schedules: Projects will always change. One week you know you’re working against a firm deadline, and the next week that has changed due to the clients, the needs of the project, or some other reason someone conjured up. It’s tough to know when that change will happen, but when it does, how you’ll fill someone’s time with other work should be high on your mind.
    • Holidays: People always extend them. Plan for that!
    • Vacations: It’s great to know about these in advance. Be sure you know your company’s policies around vacations. You never ever want to be the PM who says “Well, you have a deadline on X date and that will conflict with your very expensive/exciting trip, so, um … no.” Ask people to request trips at least a month in advance so that you can plan ahead and make it work.
    • Illness: We’re all humans and that means we’re fine one day and bedridden the next. You’ve always got to be ready for a back-up plan. It shouldn’t fall on your client stakeholders to make up time, but sometimes it has to. Or sometimes you need to look for someone to pitch in on intermediate tasks to keep things of track while your “rock star” or “ninja” is getting better.

    Align Plans with Staffing

    When you’re working hard to keep up with staffing plans, you’ve got to have updated project plans. A small change in a plan could cause a change in staffing—even by a few hours—and throw everything else off.

    Save Yourself and Your Team from Burnout

    If you’re busy and not slowing down any time soon, you want to keep this spreadsheet (or tool) updated often. If you’re working at an agency, knowing what’s in your pipeline can also help you. Stay aligned with the person in charge of sales or assigning new projects so that you can anticipate upcoming needs and timelines. In some cases, you may even want to put some basic data in your spreadsheet or tool so that you can anticipate needs.

    Good Resourcing Can Justify More Help

    The value of tracking this data goes beyond your projects. It can help business owners make important decisions on growing a company.

    No matter what you do, be sure to communicate about staffing as much as possible. If you’re in an organization that is constantly handling change, you’ll know that it’s a tough target to hit. In fact, your numbers will often be slightly off, but you’ll find comfort in knowing that you’re doing everything you can to stay ahead of the resource crunch. At the same time, your team will appreciate that you’re doing everything you can to protect their work-life balance.

    Stakeholders Are Resources, Too

    When you’re working on a team with a project, you have to consider the stakeholders as decision makers, too. Let’s face it—no one has ever been trained to be a good client, stakeholder, or project sponsor. In addition to that, they are likely to be working on several projects with several people at one time. Life as a client can be hectic! So do everything you can to help them plan their time appropriately. In general, you should let the stakeholders know they’ll have to plan for these things:

    • Meetings: You’ll conduct a kickoff meeting, weekly status updates, deliverable reviews, etc.
    • Scheduling: You’ll need stakeholders to wrangle calendars to get folks into said meetings.
    • Gathering feedback: This sounds easy, but it is not. You will need this person to spend time with all of the stakeholders to get their feedback and collate it for you to make sure there are no conflicting opinions.
    • Chasing down decisions: There are points on every project where one person will need to make sure there is agreement and decisions can be made to keep the project moving.
    • Daily ad hoc email, phone calls: Questions and requests will pop up, and you’ll need timely responses.
    • Operations: You might need invoices to be reviewed and approved or change requests to be reviewed and discussed. The stakeholders will need to make time to operate the project from their side of things.

    This is a lot of work. And just like PM work, it is very hard to quantify or plan. If you’re in good hands, you’re working with someone who has good PM skills. If not, give them the list above along with a copy of this book. But seriously, if you can assist them with planning their time, it might be as simple as including action items or to-dos for them in a weekly email or in your status report. Just remember, they are busy and want the project to run smoothly as well. Help them make that happen.

    TL; DR

    Managing projects is hard enough, but being the person to manage who works on what and when can be even more difficult. However, if you don’t keep track of this basic information, you’ll likely find it hard to meet deadlines and wrap up projects without major issues. Here are some simple things you can do to make sure your that your team stays busy, yet not completely overbooked:

    • Set up a simple spreadsheet to forecast projects and hours per team member.
      • This data should be based on what’s included in your project scopes and timelines—be sure to double-check that.
      • You may want to check out one of the resourcing tools that are out there now.
    • Be sure to account for a number of factors that you can’t necessarily control in this process—for example, interests, skill sets, moving schedules, holidays, vacations, and so on.
    • Account for your sales process if you’re in an agency and stay ahead of new project requests.
    • Remember that you’re dealing with people here.

    Want to read more?

    This excerpt from Project Management for Humans will help you get started. Order the full copy today, as well as other excellent titles from Rosenfeld Media.

    Project Management for Humans
  4. A List Apart volunteer update

    A note from the editors: A few days ago, we announced a reimagined A List Apart, with you, our faithful readers of nearly 20 years, contributing your talents. The response from this community was humbling, thrilling, and, frankly, a bit overwhelming. If you volunteered to help A List Apart and haven’t heard back from us yet, here’s what’s up.

    To the many wonderful souls who have so far volunteered to help A List Apart, thank you very, very much for your emails! And if you haven’t heard back from us yet,  please excuse the delay. We’ve been inundated with messages from hundreds of potential volunteers across a wide spectrum of disciplines and potential task groups, and we are going through your messages slowly and carefully, responding personally to each one.

    Some of you have written asking if we might be interested in having you write for us. Gosh, A List Apart has always welcomed articles from our community. Guidelines (plus how to submit your first draft, proposal, or outline) are available at alistapart.com/about/contribute. Please check them out—we’d love to look at any topically appropriate article you care to submit. 

    But writing articles is far from the only way to support and make your mark at the new (19-year-old) ALA.

    Meet the groups!

    If you’ve expressed an interested in organizing or hosting an ALA-themed monthly meet-up, or have other ideas that can help grow community, we’ll invite you to join our newly forming COMMUNITY group. If EDUCATION AND OUTREACH is more your thing, we are starting a group for that, as well. There are other groups to come, as well—a list of our ideas appears in the original post on the topic, and there may be more groups to come.

    How these groups will work, and what they will do, is largely going to be determined by the volunteers themselves. (That’s you folks.)

    As we’re starting the work of supporting and organizing these groups on Basecamp, you can’t just add yourself to a group, as you could on, say, Slack. But that’s okay, because we want to approach this somewhat methodically, adding people a few at a time, and having little written conversations with you beforehand.

    Our fear was that if we launched a bunch of Slack channels all at once, without speaking with each of you first, hundreds of people might add themselves the first day, but then nobody would have any direction as to what might be expected—and we might not have the resources ready to provide guidance and support.

    By adding you to Basecamps a few at a time, and hopefully identifying leaders in each new group as it begins forming, we hope to provide a lightly structured environment where you can design your own adventures. It takes a little longer this way, but that’s by design. (A List Apart started in 1997 as a 16,000-member message board. Big open channels are great for letting everyone speak, but not necessarily the best way to organize fragile new projects.)

    If you are interested in contributing to those projects, or curious about a particular area, and told us so in your initial email, we will eventually get to you and assign you to the right slot. If you haven’t yet volunteered, of course, you can still do so. (See the original post for details.)

    Editors, developers, and designers

    But wait, there’s more. Developers: if you have standards-oriented front-end development experience and would like to help out on day-to-day site maintenance, occasional minor upgrades, and an eventual redesign, just add yourself to A List Apart’s Github front-end repo: github.com/alistapart/AListApart.

    Those with backend experience (particularly in ExpressionEngine and WordPress), you will hear from us as we work our way through your emails.

    Editor-in-chief Aaron Gustafson and I have also been going slowly through your mails looking for additional editorial help. We’ve already found and added a few very promising people to our volunteer editorial staff, and will introduce them to you soon. If you’re an editor and we haven’t added you yet, not to worry! It likely means we haven’t gotten to your email yet. (So. Much. Email!)

    As might be expected, a majority of those who volunteered offered their services as designers, developers, or both. The number of emails we’ve received from folks with these skills is humbling, touching, and a bit overwhelming. We have not yet begun to dig through this particular pile of mail. So if you haven’t heard from us, that’s why. (But, as I just mentioned, if you’re a developer, you can add yourself to our front-end repo. So do that, if you wish, and say hi!)

    We love you

    Hope this helps clarify what’s up. We are grateful for every single email we’ve gotten. We will eventually speak with you all. Thank you all again.



  5. Patterns and Purpose, an Excerpt from Animation at Work

    A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Rachel Nabors's new book, Animation at Work, available now from A Book Apart.

    So we can use animations to tap into users’ visual systems and give them a cognitive speed boost, terrific! But before animating every element of our designs, we must learn when and how to use this new tool: with great power comes great responsibility, and so forth. And as animation must vie with many other concerns for development and design time, it makes sense to spend our resources where they’ll go the farthest.

    This chapter sets you up with some core animation patterns and shows you how animation applies to a greater system. Then you’ll learn how to spot cognitive bottlenecks and low-hanging fruit, maximizing the impact of the animations you do invest in.

    Common Animation Patterns

    If you’ve looked at as many examples of animation on the web and in app interfaces as I have, certain patterns start to emerge. These patterns are helpful for identifying and succinctly verbalizing the purpose of an animation to others. Here are the categories I’ve found myself using the most:

    Transitions take users from place to place in the information space, or transition them out of one task into another. These tend to have massive impacts on the content on the page, replacing large portions of information.

    Supplements bring information on or off the page, but don’t change the user’s “location” or task. They generally add or update bits of additional content on the page.

    Feedback indicates causation between two or more events, often used to connect a user’s interaction with the interface’s reaction.

    Demonstrations explain how something works or expose its details by showing instead of telling.

    Decorations do not convey new information and are purely aesthetic.

    Let’s have a look at each of them and see how they impact the user’s experience.


    The web was originally designed as a series of linked documents. Clicking on a link caused the browser to wipe the screen, often causing a telltale flash of white, before painting the next page from scratch. While this made sense in the context of linked text-based documents, it makes less sense in an era where pages share many rich design elements and belong to the same domain. Not only is it wasteful of the browser’s resources to be recreating the same page layout over and over, but it also increases users’ cognitive load when they have to reorient and reevaluate the page’s content.

    Animation, specifically motion, can facilitate the user’s orientation in an information space by offloading that effort to the brain’s visual cortex. Using a transition between changes in task flow or locations in information architecture ideally reinforces where the user has been, where they are going, and where they are now in one fell swoop.

    For example, on Nike’s SB Dunk page, when a user clicks a navigation arrow, the current sneaker moves out of the way while the next sneaker moves in from the opposite direction (Fig 2.1). These transitions clearly show the user how they are navigating along a linear continuum of sneakers, helping them keep track of their place and reinforcing the spatial model of perusing a real-world row of sneakers.

    Fig 2.1: On this Nike page, transitions are used to navigate forwards and backwards along a linear continuum of sneakers. (Watch the accompanying video.)

    On another shoes site, fluevog.com, transitions move the user from task to task (Fig 2.2). After a user starts typing in the search field, the results are animated on top of a darker backdrop. This transitions the user from the browsing context to refining their search results, streamlining their focus while also reassuring them that they can get back to browsing without much effort.

    Fig 2.2: On Fluevog’s website, transitions move users from the browsing context to the searching context. (Watch the accompanying video.)


    While transitions move the user from state to state, supplemental animations bring ancillary information to the user. Think of times when information complementary to the main content of the page appears or disappears in view: alerts, dropdowns, and tooltips are all good candidates for a supplemental animation on entry and exit.

    Remember that these animations need to respect the user’s Cone of Vision: will they be looking directly at a tooltip appearing next to their cursor, or will their attention need to be directed to an alert on the side of their tablet?

    When a user adds a product to their shopping cart on glossier.com, rather than taking them to a whole new shopping cart page, the site merely updates the user as to their cart’s contents by popping it out as a sidebar (Fig 2.3c). While a transition would snap the user out of browsing mode, this supplemental animation lets the user dismiss the shopping cart and continue shopping.

    The shopping cart sidebar uses an additional supplemental animation to quickly and subtly attract the user’s eye: a progress meter gradually fills to show how much the user needs to spend to get free shipping (Fig 2.3d).

    Fig 2.3: Glossier.com uses supplemental animation to show and hide the user’s shopping cart, keeping them in the shopping context longer without forcing them into the purchasing context. (Watch the accompanying video.)

    This shopping cart process has a third animation pattern going on: the Add to Bag button gains a spinning icon when clicked, which gives the user feedback as to its loading state (Fig 2.3b). Speaking of feedback…


    Animation can give users direct feedback about their interactions. A depressed button, a swiping gesture—both link a human action to an interface’s reaction. Or the flip side: a loading spinner on a page indicates that we’re waiting on the computer. Without visual feedback, people are left wondering if they actually clicked that “pay now” button, or if the page is really loading after all.

    On the Monterey Bay Aquarium’s site, hovering over a button causes its color to fade from red to blue, indicating that the element is interactive and ready to react to user input (Fig 2.4). Button hovers are classic examples for this kind of animation, partly because the gain of giving users visual feedback on buttons is so measurable and important to business.

    Fig 2.4: On the Monterey Bay Aquarium’s site, hovering on a button triggers an animation that gives the user feedback that the element is interactive. (Watch the accompanying video.)

    Design studio Animal’s site uses a bar of color across the top of the page as well as an animated version of their logo to indicate the page’s loading and loaded states while providing interest and reinforcing their “wild” branding (Fig 2.5).

    Fig 2.5: Design studio Animal uses a progress to let users know how much of the page has loaded, and an animated logo to indicate when it’s fully loaded. (Watch the accompanying video.)


    Demonstrations are my personal favorite use of animation. They can be both entertaining and insightful. These animations put information into perspective, show what’s happening, or how something works. This makes demonstrative animations perfect partners for infographics. One thing all demonstrative animations do is tell a story, as you’ll see.

    “Processing…” pages are an opportunity to explain what’s happening to users while they wait. TurboTax makes good use of these processing pages (Fig 2.6). After users submit their US tax forms, it banishes any remaining anxiety by showing them where their information is headed and what they can expect—all while reinforcing their brand’s friendliness and accessibility. (It also helps that the animation distracts users from a rather lengthy page load with something visually engaging!)

    Fig 2.6: TurboTax both informs their users and masks long page loads by demonstrating what’s going on after the user submits their US tax forms. (Watch the accompanying video.)

    Coin famously uses demonstrative animations to explain their consolidation card’s value proposition to curious visitors as they scroll through the site (Fig 2.7)—no need to press play and sit through a video ad or wade through paragraphs of expository content. This page is the very essence of “show, don’t tell.”

    Fig 2.7: As visitors scroll through Coin’s site, the company’s value proposition plays out in front of them. (Watch the accompanying video.)


    It’s not hard to mistake decorative animations for demonstrative animations. But there is a key difference: where demonstrations bring new information into the system, decorative animations do not. They are the fats and sugars of the animation food pyramid: they make great flavor enhancers, but moderation is key.

    The best way to spot a purely decorative animation is to ask, “What can a user learn from this animation? Does this guide them or show them something they wouldn’t know otherwise?” If the answer is no, you might have a decorative animation on your hands.

    Even though they get a bad rap, decorative animations can help turn the ordinary into the extraordinary. Revisionist History’s site uses decorative animations judiciously to bring flat illustrations to life. The animations add just enough interest to allow for the visual content on the page to be more austere, letting users focus on the podcast (Fig 2.8).

    Fig 2.8: Revisionist History’s site uses decorative animations to add visual interest to non-visual media. (Watch the accompanying video.)

    Polygon.com epically used animated illustrations to create centerpieces for a series of console reviews. These decorative animations may not have added new information, but they crucially reinforced the Polygon brand. They also helped each console review stand out from the competition, which at the time sported indistinguishable photographs of the same devices.

    Fig 2.9: Polygon uses decorative animations as a showstopping feature to stand out from the competition. (Watch the accompanying video.)

    Want to read more?

    This excerpt from Animation at Work will help you get started. Order the full copy today, as well as other excellent titles from A Book Apart.

    Animation at Work by Rachel Nabors
  6. New A List Apart wants you!

    As A List Apart approaches its 20th anniversary—a milestone in independent, web-based publishing—we’re once again reimagining the magazine. We want your feedback. And most of all, we want you.

    We’re getting rid of advertisers and digging back to our roots: community-based, community-built, and determinedly non-commercial. If you want to highlight local events or innovations, expand your skills, give back, or explore any other goal or idea, we’re here to support you with networking and backing from the community.

    In recent years, we’ve seen our rich universe of diverse, creative blogs and sites implode—leaving fewer and fewer channels available to new voices. As more content centralizes into a handful of all-powerful networks, there’s a dreary sameness in perspective and presentation.

    This creeping monopolization is a sad echo of how media worked in the 20th century. It doesn’t reflect 21st century diversity and empowerment. It’s not the web’s promise. It’s not how it’s supposed to be.

    We have no beef with networks like Twitter or Facebook, or with companies like Apple and Google that currently dominate our communal digital space. We just think diversity is about expanding and speaking up—not consolidating and homogenizing.

    Define the next decade with us

    A List Apart has always been more than a publisher; we’re an ecosystem of practitioners who are passionate about our craft. We’ll keep finding and sharing great articles—we’re just taking it to the next level.

    Two ways to pitch in

    If you want to put your favorite skills to use, expand your professional experience, or have a goal or idea for A List Apart, we’re here to listen. And if you’d like to support us in some other way, we’ve made that easy, too. Currently there are two ways to pitch in:


    Use the email address at the bottom of this message to let us know if you want to create or join a team that “owns” some area you’re interested in, such as:

    • Design & development
    • Community service and local meetups/events
    • Education and entry level/advanced resources
    • Book/resource coverage and reviews
    • Editorial: Editing, acquisitions, and email
    • Social media, SEO, or marketing
    • Project management
    • Your suggestions!


    If you don’t have time to volunteer but still want to support us, you’ll be able to offer other forms of help—for instance, making a small, monthly donation via Patreon to help cover our expenses. This will also grant you membership benefits. (Details at Patreon.)

    Sharing is caring

    More about all of this will soon be revealed. Meantime, if you have feedback or questions about what we’ve shared so far, kindly fire away in the comments. (Hey, how’s that for an idea? A comments section that’s positive and not divisive.)

    As we imagine the next 20 years of web design, there’s a lot we don’t know—other than a strong hunch that accessible, semantic HTML will continue to be the bedrock of it all. But one thing we do know: the web, in its reach and its potential, is too important to be left to the mercies of a few powerful companies, however well-intended they may be.

    If you’ve a mind to do so, please help us keep our little corner of the indie web alive and well. Help the open web stay open. Help us build the future. To get involved, email us at contact@alistapart.com—or share your thoughts in the Comments section below.

    The independent content producer refuses to die!


    Jeffrey Zeldman, Publisher
    Aaron Gustafson, Editor-in-chief
    & the gang



  7. Conducting the Technical Interview

    I vividly remember my first interview as a manager. My hands were shaking as I led the candidate up the stairs to the conference room I had booked. When we got there, I went into a panic. What if I don’t ask a vital question? How do I even know what the vital questions are? What if I hire him and he’s completely unprofessional? How can I tell if he really knows JavaScript? Wait a second—does he have a prosthetic leg? Did I just take a candidate with a prosthetic leg up the stairs? Oh no, I’m failing this interview already!

    Even if you’re familiar with the basics of interviewing, technical interviews can be nerve-wracking. Whether you’re a new team lead or you’ve been in leadership for years, concerns and insecurities like the ones I had in my first interview can haunt you, and even well-established interview processes can fail to adequately screen candidates.

    Interviewing for technical positions is, in many ways, a balancing act. You look at past, present, and future; you look at soft skills and hard skills; you have to think as both a buyer and a seller; you even have to worry about company image and reputation management. There are some basic things you can do to keep that balance and best represent your company.

    Define the ideal role

    I’ll admit, for my first round of interviews, all I was looking for was someone who could tick off all the technical skills on a checklist. As I progressed in my management career, I started to learn that I never looked for the same person twice—each time I had an opening, the team had different needs, and I had to take those into account when hiring someone. Even though the job description for a front-end developer didn’t change much each time, my expectations for the ideal candidate did. That gap between the job description and the ideal role tripped me up for a long time.

    Before you start interviewing, you’ll need a solid written description of what you’re looking for in an ideal candidate, beyond what job postings typically go into. The job posting may say Senior Front End Developer, but if you need someone to be your CSS animation specialist and help define standards and best practices—whether now or in eight months—you’ll need to take that into account when hiring.

    Be future-oriented with your description: ask yourself what happens when the employee outgrows his or her role. Could this person be a supervisor, or would they even want to be? Is there an opportunity to be a technical leader or architect at your company, if that’s the route this person chooses? Could this person one day replace you? (Remember, you’re probably not getting promoted until there’s someone to take your place.) If you have no answer to the question of what happens when an employee outgrows the role, the answer is usually found at another company.

    Also ask what happens if the team continues to grow. Does this person have the aptitude to pick up new skills and responsibilities as needed? How will this person respond to change? What if you have to put this person in front of a client? At a healthy company, growth is inevitable, both in size and scope. Your definition should describe someone who can grow with you and not get left behind.

    Define not only the technical skills, but also the soft skills needed for the role you have in mind. If you need someone to take the lead on collaborating with the Creative team, you’ll need to define what would make an employee successful in that role and hire for that. This can actually be more important than the technical skill requirements. Technical skills can be easily trained—soft skills cannot.

    When you do all of this, you’ll have a list of expectations for a role that probably won’t fit in a job posting. When appropriate (don’t make promises of growth), test those waters with the people you’re interviewing. Even if you determine a person would be good as a trainer, they may not want to do that, which can be a nasty surprise if you hired the person with the intent of them growing into the role a year down the road.

    Once you know what you’re looking for, the next step is getting them to want to work for you.

    Sell the job

    The saddest interviews for me are the ones where I find that ideal candidate I envisioned and they get away. Sometimes, they just get a higher salary somewhere else; but sometimes, they decide that they don’t like the company and want to keep looking. Both are sad, but either way, getting candidates to like your company is always in your best interest.

    Remember, when you’re interviewing someone, they’re also interviewing you. Don’t ever assume that your company is the only place a candidate is interviewing. It’s true that some people walk in the door with their minds made up, but many are still deciding whether they want to work for your company—and the better the candidate, the more options they’re going to have, so the more you’re going to have to sell to win them over.

    So how do you sell a job? A salesman will tell you it starts with knowing three things really well: the product, the competition, and the customer. The product is your company: benefits, compensation, culture, type of work, amount of work, and even location. The competition is any local business that hires similar types of people, and you’ll need to know the same things about them that you do about your own company. The customer is the job applicant. Knowing each of these things well and being able to compare them is key to winning the best candidates.

    Do your research not only into your own company, but your local competitors. What are your competitive advantages? What are theirs? (If you think a ping pong table is a competitive advantage, you’ll probably need to dig a little deeper.) Sometimes it’s not about what you have so much as what the competition doesn’t. If you’re seeing a lot of interviewees from a competitor, find out why and see if you can use that factor to sell your company.

    Learn what prospective employees are looking for in a job. There will likely be some commonalities. If you’re losing top talent because you don’t offer a benefit or they don’t like your processes, you’d be wise to revisit those. Just like the technology in our industry is constantly changing, the expectations and needs of our employees are also changing. Don’t fall behind with what you offer to your employees.

    Almost every candidate will have questions about what the work environment is like. You should have a little elevator speech to sum up your answer and sell your company in a minute or less. You may actually want to lead the interview with that speech to get those questions out of the way and get the candidate excited for the position before you start finding out about them.

    Lastly, be authentic with your interviewees. Don’t try to spin a weakness as a strength, because most people will see right through that. If you don’t believe in your company enough to be totally honest about it, why should they believe in it enough to work for you? You don’t need to hand them a comprehensive list of everything that’s wrong with your company, but don’t shy away from questions along those lines, and don’t try to reframe a shortcoming as a strength. As an example, if your company has a reputation for burning some people out, that’s important, but you can talk about the type of people who do well there rather than the people who don’t. It’s better that people find that out in the interview than after three months of training.

    Hire a person, not a code machine

    In my five years as a supervisor, I only had to fire two people. Want to guess how many of those were because they lacked technical skills? Zero. In both cases, the employees didn’t work out for non-technical reasons.

    There are a number of non-technical factors to look for in a candidate: personality, fit with the team, communication skills, openness to change, leadership potential, and a host of others. (That’s the real reason you’re conducting an interview and not just asking for test results.) These details don’t magically reveal themselves in the technical portion of the interview—you need to ask about them.

    Create a list of standard questions for candidates. Questions should be open-ended and answered with a story. Examples include:

    • Tell us about a time when your good communication helped to solve a problem.
    • Tell us about a time when you disagreed with your supervisor and what you did about it.
    • Tell us about a time you successfully described a technical concept to a non-technical person.
    • How would you explain inheritance to a junior developer?
    • Tell us about a recent time you learned from a mistake.

    Order is important: ask the non-technical questions first. The technical portion of the interview can make some people nervous, and you won’t get a good gauge of who the candidate is if their thoughts are fixated on the technical questions they missed.

    Putting thought into screening for soft skills is vital. But remember that this is a technical interview—you have to put just as much thought into screening for technical talent.

    Stick to the standards

    And I’m not talking about web standards. If you’re not asking all developers the same questions, there’s a good chance you won’t get a fair comparison, which means a greater likelihood that you’ll fall back on biases like similarity or likeability.

    Develop a standard set of technical questions, and a written test. The questions should allow for some discussion, but have a clearly-defined right answer. Examples of these questions are everywhere. You’ll probably want to customize your list so that people can’t just look up the answers online before the interview, but lists like those will get you most of the way there.

    (And don’t feel like you need to come up with this list on your own. If you have technical experts at your disposal, utilize them. You’ll probably want one in the interview, too.)

    The written test can make or break an interview. It should not be easy, nor should it be mandatory to get every question right. When an applicant is writing out code by hand from memory, leniencies must be given for syntax—give points for partial answers and ideas. Remember what Stephen Wolfram, creator of the Wolfram Alpha answer engine, said on the subject: “One thing I’ve noticed is that in almost every area, the people who go furthest are not the ones with the best technical skills, but the ones who have the best strategy for figuring out what to do.” You’re trying to get a feel for the candidate’s problem-solving strategy, not their ability to memorize every minutia of coding syntax.

    There should be at least a few “fix this code” sections to see how sharp their debugging skills are. Again, you shouldn’t focus on trick questions or ridiculously obscure syntax problems—you just want to measure the candidate’s ability to think through and solve a technical problem.

    Questions should be relevant to what the job entails—if they’ll be expected to create custom CSS animations, make sure to ask about that—but they should avoid niche- or process-specific knowledge unless it’s vital to the position. Rule of thumb: if your company does something differently than the rest of the industry, don’t quiz them on it.

    Once you have the questions and test prepared, run the questions by some of your existing team members to see how they fare. If your entry-level developers get all of the questions right—probably a bad sign; if your senior developers all bomb the test—also a bad sign.

    In the questions, there should be some clear delineation between roles. What are the must-answer questions for mid-level developers? For seniors? There can be some flexibility here, but you should have a pretty good idea what a senior test looks like and what a mid-level test looks like.

    If a candidate aces your standard interview questions, you can hire them with confidence. But when the technical portion of the interview doesn’t go well, you need to know how to handle that too.

    Know when to move on

    The most awkward interview I ever conducted was with a PHP developer who freelanced and was looking for his first agency job. When we began the technical questions, I quickly realized he didn’t know as much as he thought he did. Of the 22 technical questions, he got about 2 correct. He got more and more distressed with every tough question—especially when I corrected his wrong answers—and by the end of the technical portion, he looked like he’d been punched in the stomach.

    That guy was not qualified for the job, and both of us knew it from question 3. This was pretty early on in my management career, so I just plowed through the entire list of questions, knowing he would fail them. Learn from my mistake: don’t do that.

    Let interviewees fail gracefully. Don’t interrupt them with the right answer to the question they’re struggling with, and don’t correct them if they get the answer partially right. If they get the question wrong, just move on without showing judgment. If they really can’t get a question, just tell them you’re moving on.

    If a person bombs the verbal questions, don’t make them sit through the written test (which will probably be much harder). Feel free to tell them right then and there that they’re not a good fit for your particular position and wish them well in their quest for work. If you think they could be a good fit for another position in your company, or if you’d like to see them back once they get a better grasp on the fundamentals, go ahead and let them know. But there’s no point in leading them on with a vague non-answer if the answer is definitely no.


    Screening for technical talent can be tricky. Having a holistic view of both the role and the candidate is key to making the right hiring decision. Remember to take careful notes, even if you don’t think you’ll need them. And good luck!

  8. Yes, That Web Project Should Be a PWA

    It seems like ever since Frances Berriman  coined the term “Progressive Web App” in an effort to describe a new class of website, there’s been a great deal of confusion over exactly what a Progressive Web App (PWA) is. Sure, her husband, Alex Russell, put together a handy guide to the characteristics of a PWA, and they have been the subject of reams of documentation, dozens of blog posts, and equally as many conference talks.

    Even with so much well-written, accessible content about PWAs freely available, misinformation abounds. Maybe you’ve run into one or more of these:

    • If you’re building a PWA, you need to use a JavaScript framework.
    • To build a PWA, start with a single page app.
    • PWAs only make sense for “apps” your users want to install.
    • PWAs only make sense in mobile.
    • PWAs are an Android thing.

    None of these are true, but like so much misinformation these days, each contains a shred of truth that has been contorted into a falsehood. If you’re considering building a PWA, you might use a JavaScript framework or build it as a single page app, but it’s by no means necessary. They’re an option for building a PWA just like they’re an option for any other web project. After all, every PWA is (or at least should be) a website. PWAs just have some features that empower them to do more than websites have traditionally been able to ... like install. But, similarly, installation is not the raison d’être of every PWA. And, while many of the first PWAs were focused on mobile and only worked on Android, PWAs are not limited to small screen devices anymore. They’re also more than a Google thing too; Microsoft, Mozilla, Opera, and Samsung are all on board. Apple recently declared their intent to implement Service Workers (one of the technical underpinnings of PWAs), but time will tell if they’ll support aspects like installation. No matter, as Progressive Web Apps work really well in Safari anyway!

    Sadly, misinformation like this has convinced many designers and developers (and their management teams) that PWAs aren’t appropriate for their projects. They are! Your site—every site—should be a PWA. This approach offers benefits for every project on the web, but I’ll get to that in a minute. Before I do, I want to level-set on what, exactly, makes a PWA a PWA. If you’ve been tracking PWAs closely or have already built one, you can skim or skip the next section. If you aren’t all that familiar or don’t feel like you have a good grasp on what they are, no worries, the next section is a very brief primer that will get you up to speed quickly.

    So what is a PWA?

    As I mentioned, a PWA is a website with special powers. The term “app” in the “Progressive Web App” is not indicative of the sort of content or experience users should expect with a PWA. You shouldn’t get hung up on it; “Progressive Web App” is a marketing term. PWAs have the ability to connect with the operating system (and, thereby, its users) on a deeper level through installation and APIs offering capabilities like notifications, access to the address book, and more. Not all of these APIs require installation for access, but some do. It may help to think about a PWA as being a website++.

    What makes a PWA a PWA? Not much, actually; there are only three requirements:

    1. You need to be running under HTTPS. PWAs can be granted a whole host of extra privileges in an operating system, so it’s critical that the connection to your web server be secure. If you need help with this, you should check out the free SSL service Let’s Encrypt.
    2. You need a Web App Manifest. This is a lot less scary than it sounds. It’s a JSON file with information about your site. You may even have a bare-bones one already if you’ve used a favicon generator. Make sure you reference it using a link in the head of your web pages so browsers and search spiders can find it.
    3. You need a Service Worker. This is probably the most complicated step, but there are a ton of recipe guides out there for creating Service Workers tailored to the kind of jobs you want them to do. This one, from Mozilla, is especially good.

    That’s it. Once you have those in place, your website is a Progressive Web App. At least technically. Why the qualification? Well, this is where things get a little more nuanced.

    Back in 2015, when he debuted the PWA concept, Alex Russell outlined ten characteristics PWAs shared (or at least were capable of). Most of those characteristics are, without a doubt, how we should be building for the web. Others are not as universal and would not make sense in every kind of project. I suspect that might be one of the sources of confusion for folks considering adopting the PWA approach and it’s the reason I decided to write this article.

    Quality experiences and the universal benefits of PWAs

    In the next few sections, I will discuss several web project archetypes and how adopting some of these PWA characteristics can benefit their users. After all, that’s who we’re doing this for. But before I get to that, I want to discuss the seven characteristics of PWAs that are useful in any web project.

    As I mentioned, there are some characteristics of PWAs that will absolutely provide value to your users and are well worth your time and consideration. In fact, all of them are considered best practices in web design and development.

    First off, PWAs must be safe. As I mentioned in my discussion of their technical requirements, PWAs must be running under HTTPS. Period. Thankfully, the cost of running your site under HTTPS has dropped to zero. Sure, there are legitimate challenges to converting large existing websites over, but it’s worth it for so many reasons. The primary one is that it protects your users from malicious man-in-the-middle attacks being made by ISPs, in hotels and airports, infected routers, or others with network access. HTTPS ensures that both the code and content you send to your users actually arrives intact. It’s not fool-proof, but it’s an important step in protecting your users and your data. Running HTTPS is also a prerequisite for access to many of the newer (and more sensitive) APIs including Geolocation and Service Workers and for performance-boosting technologies like HTTP/2 and Brotli compression. It’s also worth noting that many browsers are beginning to mark non-HTTPS sites “unsafe” and SSL also affects search ranking.

    I mentioned earlier that PWAs were never intended to be a mobile-only approach. PWAs are for everyone. Making your project available to more people on more devices with wildly varying operating systems, browser capabilities, system APIs, and screen sizes is only going to increase your reach and create more opportunities to be successful. This is where progressive enhancement and responsive design come in. By building responsive layouts, your designs will adapt to provide the most appropriate layout given the screen real estate you have to work with, whether dependent on the dimensions of the device or on the window size set by your user. Progressive enhancement enables your projects to adapt to an even wider array of variance, in both the execution environment (device, OS, etc.) and, more importantly, your users.

    Progressive enhancement also helps you avoid situations where users can’t access your project because they happen to use a device or browser you’re unfamiliar with or haven’t tested on. It ensures your site works on any device that can access the web, regardless of its capabilities, allowing you to use your valuable time optimizing that experience for more modern browsers and devices. It’s also a more economical approach in the long-run.

    Another quality Alex identified was that many PWAs are “app-like”. Note the like. They are not apps, but rather, provide app-like experiences that users—dare I say it?—enjoy using. The more you can do to provide a consistent, seamless, effortless user experience (which is really what “app-like” is implying here), the more likely you are to see repeat visits, increased sales, etc. It’s worth noting that this doesn’t mean you have to use JavaScript; it simply means you should think about the flow your users take through your site and take every opportunity to remove the friction from the process of them accomplishing their goals.

    If you’ve built something, you probably want folks to find it. PWAs, by definition, are easy to discover. Your site’s content should be written in such a way that it pops up organically when people search for related topics. Don’t get all spammy, but take care to author content in a thoughtful, appropriate, and straightforward way.

    Related to discoverability is that PWAs are linkable. If your users can reach a certain point in your site via natural navigation, you should do your best to ensure they can save their place by bookmarking it or when they re-launch their web browser and your site’s tab is re-launched. This also plays into how shareable your project is. You may also want to do yourself a favor and spend some time putting together some Open Graph meta tags and some JSON-LD to make your content even more shareable.

    Last, but certainly not least, there’s network independence. This is the big one that gets developers so excited. Offline capabilities and persistent storage has, to some extent, been possible for a while now; heck, Microsoft debuted client-side data storage back in 1999! Alas, while client side data stores—IndexedDB, localStorage, etc.—have definitely come of age in the last few years, true control over resource caching has been pretty abysmal. Then came Service Workers and the Cache API. These two technologies work in concert with the Fetch API to make, intercept, augment, and store resource requests made from within your site, meaning your users may still access your content, even if their network connection is interrupted.

    There are a ton of fantastic resources covering the ins and outs of Service Workers, so I’m going to skip the technical stuff and just talk about some of the neat things you can do with them:

    • Prefetch and cache resources you know your users are going to need. This can improve performance dramatically.
    • Cache every page and asset requested by your site so they don’t need to be retrieved from the server each time a new page is loaded. This improves performance on navigation as well as on return visits.
    • Define a custom “offline” page. This prevents users from seeing the browser’s generic “You’re not connected” message.
    • Look for a network connection first and provide the “live” copy of a given resource if it’s available, falling back to a previously cached “stale” version if it’s not. This can also prevent users from seeing “You’re not connected” messages.
    • Respond to requests for JPEG images with WebP (which tend to be considerably smaller) versions of those images if the browser supports them. This strategy allows you to provide alternate image sources that improve performance without having to modify your markup.

    Service Workers are capable of a whole lot more—some of which I will get into shortly—and are on track to be granted many more incredibly useful features in the not too distant future. They have already proven their worth and bring value to any project on the web. For a useful list of recipes, check out this cookbook from Mozilla or this one from the Chrome team.

    Other PWA benefits by project type

    Now that we’ve looked at the universally-beneficial qualities of PWAs, let’s shift gears. Every project is different, but there are a handful of archetypes that most web projects tend to fall into. And each of those archetypes can derive real benefits from running as a PWA.


    When I think about informational sites, I’m talking about the kinds of sites many of us in the industry refer to as “brochureware.” Vanity sites are a good example of this. Small business sites whose interactivity tops out at a contact for or a phone number link are another. Portfolios would also fall into this category as would many restaurant sites.

    In most cases, projects like these are there to serve folks wanting to know more about you, your business, a project, or something similar. In most cases, you’re not going to see a ton of repeat visits. Folks come to the site looking to find out a specific piece of information—which hopefully they can access quickly and easily—and they’re off again. They might return, but they might not, meaning the performance gains provided by a Service Worker’s offline caching could be useful, but likely won’t have quite the level of impact it would have on a site that gets frequent repeat visits. It’s also highly unlikely—though not impossible—that someone will actually install a project like this.

    Depending on the type of site you’re building, you might consider integrating some device APIs. If the site is for a brick-and-mortar business, add Geolocation support. If you have sales or specials you’d like to inform your visitors about, you might consider integrating Notifications (either Web or Push).

    Even though two of the oft-touted “major” benefits of being a PWA—install-ability and offline capability—are less applicable for informational sites, making projects like these a PWA is still beneficial. Those are just two aspects of being a PWA. Your users will thank you for building a site that works on every one of their devices, is easy to use, comes up in search, and is easily shared with their friends.


    Periodical sites encompass everything from a blog or newsletter or podcast to online comics, magazines, newspapers, and video programs. These sorts of projects are like informational projects, but are updated regularly (or semi-regularly). They also have an audience that is likely to return (ahem) periodically to read a new article, watch a new video, or listen to a new podcast episode. Since they share much of their DNA with informational sites—heck, a periodical may even be part of an informational site—all of the qualities that benefit informational sites benefit periodicals as well. There are, however, some capabilities that PWAs offer that periodicals are perfectly suited to take advantage of.

    In discussing promotions or specials, I mentioned that Push Notifications could be an option for informational sites. They should be a given for a periodical site. Push Notifications provide a mechanism for your server to send an update to any instances of your Service Worker that are installed on your users’ machines. And, assuming they’ve granted you permission, those updates can be displayed to your users even if they don’t have your PWA installed or a browser tab open to your site.

    Don’t take this as an opportunity to spam your users, as you’ll likely lose their eyeballs and business. Instead, choose appropriate times to ping them. If your site only gets updates once or twice a week, notifying them of individual posts is probably good and can provide a nice alternative for folks who don’t use a feed reader. If you have frequent updates, consider a daily or weekly roll-up. This might even be a good candidate for some A-B testing.

    You could also up your game by offering an easy in-page tool for saving an article for offline reading. Why would you want to do that rather than caching everything the user ever sees using the Service Worker? Well, given the nature of a periodical, the reuse of individual content items is likely pretty low. If you cache everything the use ever sees—especially if your content contains a lot of high resolution images—you’re gonna be filling their cache up with stuff they may never want to see again. In order to be a good web citizen, you could either clean that up regularly by keeping track of the last time a resource was accessed (which, frankly, seems like a lot of work) or you could cache just the necessary long-lived resources like your CSS and JavaScript files. Then you can put your users in control by providing a button that enables them to save an entry for later.

    Continuing our journey through Service Worker land, you could start exploring Background Sync to pull in new resources periodically. If you’re a newspaper, maybe you want to prime your users’ caches every morning with the front page and the top feature stories. If you’re a podcast, maybe you want to load in the newest episode on a regular cadence. Again, to play nicely in the sandbox, you’ll probably want to trash older articles, episodes, and so on, but this could be a great way to provide an incredibly fast experience for your users. Think about it … they launch your site and the browser already has everything it needs to render today’s issue. Magic!

    Finally, periodicals are one of those archetypes where the option to install your site begins to make sense. Some people like being able to hit an icon on their home screen or in the Start Menu to access their local newspaper. It’s not for everyone and may not be right for every periodical, but it’s an option. And offering your users the ability to install your PWA comes for free, so you may as well embrace it and make sure your Web App Manifest has been thoughtfully authored to provide a good user experience when your PWA is installed.


    Any site that facilitates the exchange of information could be considered transactional. The most common examples include online shops, banking and stock trading tools, travel booking systems, and payment portals. PWAs have, to a large extent, already proven their value in this area. A quick peek on PWA Stats revealed the following “wins”:

    • The Raphael Hotels increased website conversions by 20%, pageviews by 66%, sessions by 59%, and reduced bounce rate 51%.
    • MakeMyTrip saw a 3× increase in conversion and 160% increase in shopper sessions and first-time shoppers are 3× more likely to convert on the PWA than in native app.
    • Lancôme saw a 17% increase in conversions, a 51% increase in mobile sessions overall and a 53% increase on iOS alone.

    The kicker on that last one? iOS doesn’t even support Service Workers!

    It’s well-known that improving page performance increases conversions, so the speed improvements granted by a smart caching and offline strategy with Service Workers are incredibly important here. But there are numerous other ways PWAs can benefit transactional sites as well.

    Since I mentioned offline, I’ll add that your offline strategy should not begin and end with Service Workers. For a while now, we’ve used cookies to track transactional data shopping cart contents, but cookies have always been severely limited in terms of the amount of data they can store because they get sent along with every network request. With IndexedDB, localStorage, and sessionStorage, we have the ability to store more (and richer) data about the transaction taking place on the client side. Storing this information on the client makes it easier to recover from problems like a network loss. If a transaction fails, you will still have access to the data (which might have otherwise been lost in a failed POST) and you can either periodically try the transaction again or wait until you see the network is back before submitting it. Either way, adding real-time messaging about what’s going on and how you are working to resolve it will go a long way toward assuring your users that their data is not lost.

    If your project is highly transactional, you will definitely want to look at Background Sync as a means of keeping your users’ local data in sync with server data. For example, if you are building a banking system, synchronizing information like recent transactions and current balances will be incredibly useful to your customers. Same goes with current stock prices and balances if you’re working on a trading platform.

    In most transactional scenarios, notifications can be quite helpful. Borrowing on the scenario I mentioned earlier, notifications can be used to let someone know when their transaction has completed (after all, in a PWA you could complete the transaction during a Background Sync when your site isn’t running). Notifications come in a two flavors: Web Notifications are triggered via JavaScript in an active page, Push Notifications are sent from the server and can be delivered even when the site isn’t open. Depending on the scenario, one or the other will probably make more sense. Just be aware that Push Notifications are not as well supported as Web Notifications … yet.

    For transactional sites that are frequently accessed (and I realize “frequently” is a very relative term) the install-ability of a PWA is a huge win. Isolating your site within its own app container allows users to focus on the task at hand, without the distraction of other tabs. It also insulates the processes running your code from the process running all of the sites they have open in their browser. Additionally, it has less overhead since there’s no browser chrome running alongside it. All of these benefits work together to create a streamlined, frictionless experience for your users.

    Once installed, many operating systems will grant your project access to internal APIs. Perhaps you want to let them choose an address to ship a gift to, from their contacts. Or maybe you want to enable them to add the flights they just booked directly to their calendar. Or perhaps you want to voice-enable your app by integrating with their virtual assistant. All of those scenarios become possible in the context of a PWA, which is a huge boon for transactional websites.


    Social websites—think Twitter, Facebook, etc.—are excellent candidates for PWA-ification. In fact, Twitter has already gone that route. Social sites combine aspects of periodical and transactional websites, so they naturally inherit many of the benefits of those archetypes. Push Notifications, in particular, are incredibly important for sites like this, as re-engagement is crucial for the long-term success of your platform. Install-ability is also important in that regard.

    Performance, especially initialization speed, is going to be an important benchmark for social projects, as users will not sit around waiting for all of their feed items (and their associated imagery, videos, etc.) to load. Caching your site’s assets will help a bit, but—depending on your project goals and situation—you might consider using Background Sync to update your users’ news feeds so they are ready to go (or close to it) the next time they open it up.

    As transactional projects, social websites will also benefit from access to device and system APIs when installed. Most social networks, for example, request permission to peruse your Contacts to look for friends and colleagues that are also using the service. If you go that route, it’s imperative that you don’t abuse the privilege by trying to trick your users into spamming their friends with info about your service. If we don’t respect our users and their private information, we run the risk of losing access to it (and them) altogether.


    When we talk about “web apps,” often online software is what naturally comes to mind. Some examples include email clients, accounting tools, project management suites, version control systems, and photo editors. In many ways, these are software in the traditional sense, they just exist on the web instead of being installed locally ... until now.

    Through the magic of PWAs, these software-as-a-service projects can become full-fledged desktop (and mobile) applications. This enables teams that have gone all-in on web technologies to continue (or even increase) their investment in that area without sacrificing the convenience of install-ability on native platforms. Sure, there are absolutely some solid reasons why you might want to customize a native experience for your software, but for the vast majority of cases the web offers everything necessary to run your application ... that’s why it’s on the web in the first place.

    Offline data stores, background synchronization, and file system access help to elevate the experience for your users, making this archetype the most obvious beneficiary from Progressive Web Apps.


    Some projects are, frankly, too sprawling to fall neatly into one archetype or another. I’m thinking of schools, large corporations, mammoth financial institutions. These projects are often an amalgam of many or all of the archetypes I’ve covered here. As such, all of the benefits accrued to those archetypes apply, in context of course.

    When looking at a large institutional project, it can be difficult to figure out how to assemble an overarching strategy for turning it into a PWA. The good news is that you don’t necessarily have to. You can carve up your project into many individual PWAs that can exist independently.

    Take, for example, an online learning system. You could create a PWA for the learning system itself, but you could also carve off each individual course as its own, installable PWA, with its own cache, notifications, etc. The reason you can do this is that Service Workers and Web App Manifests can be scoped. You can scope them to a specific hostname or you could even scope them to a specific path within your URL structure. While obviously more complicated, if you think of each of those courses as having a course template and you think of a Web App Manifest and Service Worker being part of that template, it becomes easier to wrap your head around.

    It’s your turn

    Progressive Web Apps may seem overly technical or beyond the needs of your project, but they’re really not. They’re just a shorthand for quality web experiences—experiences that can absolutely make a difference in our users’ lives. If you hadn’t considered building a PWA before, I hope this article has changed your mind. And if you’re already neck-deep in Service Workers, perhaps it’s given you some ideas for new ways to approach the projects you’re working on.

  9. User Interfaces for Variable Fonts

    The tools we design with have a unique effect on the way we work, constraining and empowering us while we explore, examine and create. Variable fonts give us a new, wide open typographic space with which to work. Instead of prescribing value to individual UI elements in a vacuum, we should take a hybrid and calculated approach to variable font interfaces. How do we structure our design tools to adapt to the new advantages variable fonts provide us with?

    Despite being ahead of their time, variable font precursors—Multiple Master and GX—didn’t see widespread adoption for several reasons—one key reason being the lack of effective user interfaces that could communicate their creative utility to designers.

    Since their introduction, variable fonts have moved forward quickly, landing with various degrees of experimental support across major browsers. With this comes the exciting ability for fonts to responsively adapt to different layouts and context. While responsive design has become more standard, effective variable font user interfaces have yet to be adopted.

    A number of approaches can make variable fonts (which can house effectively any number of variations) easier to understand and use. Through design exploration and looking at prexisting examples we can see how each UI element has different benefits and drawbacks. We find that few patterns should be applied to every case.

    Enabling Variable Fonts

    Within our design tools, variable fonts present a unique challenge, allowing users to select and change different properties of the typeface that are exposed by the typeface designer. These changes occur along an interpolation axis—or a line that reflects variation values of a font:

    Previewing Dunbar, a variable font with two axes by CJ Dunn within Fontview. AxisPraxis and Typeshift (my own design tool) are some other great places to check out variable fonts!

    A variable font can have any number of axes, but these can generally be reduced down to a few commonly used axes mostly likely to be used for Responsive Design. These default axes are called registered axes in the spec. Each one has a different set of use cases:

    • Font Weight – (wght): For adapting font weight to the container size, the weight of other elements, changes to hierarchy and screen resolution
    • Font Width – (wdth): For fitting the width of the typeface to the width of a container
    • Font Italicization – (ital): For changing how italicised the type is
    • Font Slant – (slnt): For changing how oblique the type is
    • Font Optical size(opsz): For adapting to container size, font size and adjusting hierarchy and typographic color

    These axes take advantage of much of the layout-based adaption variable fonts provide. Some of these concepts are best illustrated in Erik Van Blokland’s responsive lettering project:

    Erik Van Blokland's responsive lettering project

    Along with some of the amazingly beautiful Type and Media work to date:

    Responsive lettering project type and media work

    In these examples, the glyphs’ optical size, weight and width shift at the same time as you resize the window. While a large portion of variable font axes directly correlate to layout, any number of arbitrary, non registered axes can also be created by the type designer. These can be for any type of change to the typeface in addition to interacting with the layout. David Berlow’s Decovar ornamental typeface is an example of this at one extreme.

    David Berlow's Decovar ornamental typeface

    Decovar sports a wide number of settings for adjusting the font’s decorative terminals and skeleton of the font. The limit here is the type designer’s imagination.

    New Spaces

    Variable fonts carry with them a broad range of possibilities and can open up entire designspaces of creative options to type, graphic and web designers. These aren’t human readable at first—they exist as mathematical representations. However, there are proposed approaches to help us visualize and manipulate variable fonts. By exploring user interface patterns, we can better understand how to illuminate the exciting spaces within a variable font. At its foundation, this involves making variable fonts aware of their context.

    Mapping UI: Context

    Before looking at UI, it’s worth noting that variable font axes can be directly linked to a wide range of inputs. These can be any combination of sensor readings to controller inputs and environmental signals. Certain registered axes however, make the most sense for responsive design and HTML/CSS/JS. A font’s width and weight axes are directly related to the container a set line of type can fit into. Variable fonts are able to adapt to the size of their containers—either filling them completely or at a specific set proportion.

    A progression of work over the years has led to fonts adapting to fit their container. Paravel’s FitText and Zach Leatherman’s BigText were early examples of scaling text to fit a responsive container. Nick Sherman and Chris Lewis’s Font To Width swapped the width and weight version of the actual font to adapt to the container. Much of Erik Van Blokland’s previous work and responsive lettering project crystalized the idea of interpolation for adjusting type to width, height and optical variations within responsive design. Laurence Penney’s AxisPraxis demonstration links weight and width to the size of the container itself, allowing people manipulate the textbox instead of the type directly. All these strategies point to type set in relation to its container.

    Optical size variations can also be linked to font size, allowing important characteristics to shine at display sizes while minimizing details to ensure the font remains robust at small sizes. In 2013, Nick (with David Jonathan Ross, Frank Grießhammer, and Florian Hardwig) showcased this feature in Adobe InDesign.

    Automatic Optical Sizing in InDesign

    This functionality outlined in inDesign is now available for variable fonts, allowing optical sizes to adapt in tandem with a user’s font size. Through techniques like these variable fonts can to adhere to layout / container dimensions, font size, and user context.

    Often times however, a font itself needs to drive design and layout (in the case of most design tools like Sketch and Illustrator). In this case, we need UI to directly control the variable font. Interfaces rely on affordances to communicate to people how they work. UI and UX patterns carry a variety of assumptions people have built up over the years by interacting with similar controls—both physical and digital. We can break down some of these patterns and look at their advantages and disadvantages.

    Mapping UI: Single Axis Controls

    Single axis variable fonts are the most straightforward and only require one control. Toggles, sliders and knobs are all well suited for handling single axes. The most elemental of these—toggles, can be used to limit options for the sake of clarity.


    Toggles denote “on” or “off” or a single selection:

    A toggle UI for jumping between two points on an axis
    A toggle UI for jumping between two points on an axis

    A toggle’s simplicity can reduce choices to options people care about—like toggling serifs on or off (where intermediate values are less important). Single toggle based selection menus have existed since the earliest desktop publishing interfaces.

    Aldus Pagemaker (released in July 1985) with a font selection menu options for Bold and Italic fonts
    Aldus Pagemaker (released in July 1985) with a font selection menu option for Bold and Italic fonts


    Typically knobs communicate an amount of something added to a whole.

    Knobs are less common in digital interfaces but can be found in software plugins for Digital Audio Workstations. Knobs have the advantage of being compact while having a longer control surface to house values in a given square area. Another interesting property of knobs is that they can be periodic—allowing values to wrap entirely around the knob control. Underware’s Zeitung Flex introduced knobs as a method for controlling variable fonts.

    Because the visible control surface isn’t straight, digital knobs have more of a learning curve (pun intended). Most knob controls alleviate this by allowing people to brush up and down to rotate the knob after it’s active or has been selected. Unless they’re large enough, knobs can also be hard to use with touch interactions.


    Typically horizontal sliders communicate a balance or equilibrium between a range of two values.

    Horizontal sliders are a common UI pattern across the web and native applications. iOS makes frequent use of this interface element:

    Digital sliders have the advantage of working similarly to the way physical sliders do and are easy to learn. Sliders map well to a range of two different values on opposite ends of a spectrum—users just pick a middle value. Because of this, sliders are intuitive for both touch and mouse controls—actions happen in a single, linear motion.

    Typically vertical sliders communicate the amount of a specific value, sometimes in context with other values.

    Vertical sliders are typically seen in audio applications where it’s most important to horizontally scan and compare the levels of neighboring controls. Most digital audio workstations use them for volume levels.

    The Ableton Live DAW. Note how the row of volume sliders can provide context for each other. Equalizers and other effects often use a similar UI pattern

    Overall, sliders take up more space, but provide a clear and precise method for picking a specific value.

    Any UI element can be overused (sliders and knobs alike) and misapplied. Ultimately, application of single axis controls should be considerate of the design tool and variable font itself. One key consideration is how the interface scales to account for additional font axes. Slider interfaces have an advantage in this category by being able to unfold naturally to support a two-axis control pattern.

    Mapping UI: 2-Axis Controls

    It’s common for variable fonts to have two or more axes. In these cases, a two-axis pattern can work best to avoid an overload of UI elements and give a designer better visibility.


    Pads typically communicate a field of options.

    Control pads  allow people to adjust two variable font axes at the same time. This pattern has been used in both audio hardware and software to control parameters along an X and Y axis.

    Some audio hardware and software tools have pads with an X and Y axis for changing two parameters simultaneously

    Control pads are less common in digital interfaces but hold familiarity through analogous design tool patterns like color pickers, which also provide people with a field of options.

    X/Y control pads help reveal a larger portion of a font’s design space. They lack the directness of sliders and knobs, but provide a way for people to easily traverse through combinations of font variations.

    The utility of having each axis map to a single control or direction quickly diminishes as the number of axes increases. At this point, we find effectiveness shift from manipulation to visualization.

    Mapping UI: Multi Axis Controls and Visualizations

    Fonts with three or more axes (variable fonts can have virtually any number of axes) are best served with different control and visualization approaches. Each axis can be represented mathematically as a feature or dimension. Fonts with a single axis map to a slider or knob while two axis fonts can take advantage of a pad UI. Three axis variable fonts can have their axes mapped to a cube.

    Reverse Noordzij Cube Demo by DJR

    At three axes, things shift away from UI towards more of a visualization approach, as effective digital omnidirectional controls are rare. Three and up, or N-dimensional font designspaces aren’t intuitive when mapped to physical space, so the best way think of them is as the amount of ingredients in a recipe. Take a cake recipe for example:

    • 1 cup white sugar
    • 1/2 cup butter
    • 2 eggs
    • 2 teaspoons vanilla extract
    • 1 1/2 cups all-purpose flour
    • 1 3/4 teaspoons baking powder
    • 1/2 cup milk

    Each one of these ingredients represents a different feature of the cake. When combined with heat, they work together to create the final cake. Variable font axes or features work the same way:

    • 100% Font Width
    • 25% Font Weight
    • 5% Font Optical Size
    • 10% Font Serifs
    • 75% Font X-Height

    People can adjust the axis postion (or amount of each ingredient) of a variable font, all of which have an effect on the final appearance of the typeface. Certain axes, like font width and stroke contrast may work together in parallel, while others, like x-height and font width may be more independent from each other.

    Designing type with +3 Variations

    At a certain level of complexity—a design tool’s focus should shift to serve more technical users. Type designers have their own category of challenges as they design, proof and test their fonts with intricate design spaces. Some variable fonts may have axes that are not exposed to users. There are other strategies for visualizing complex variable fonts like these.

    For this, we can look at the visualization of multivariate data—a topic that has already been widely studied. There’s a broad range of existing strategies, some of which can be applied to variable fonts. The following deck divides these strategies into several categories:

    • Geometric projection techniques
    • Icon-based techniques
    • Pixel-oriented techniques
    • Hierarchical techniques
    • Hybrid techniques

    By flattening axes, designers can see many aspects of a variable font at once. Star plots—an icon based technique—allow for the combination of multiple axes into a single chart.

    Each axis extends from the center, with the sum total of a given variable font’s current settings making up the polygon shape. Other font instances can also be layered on top of the visualization with the abstraction of color.

    Instances (likely masters) of a hypothetical variable font mapped on a star plot. Note the difference in the axis positions between the wide font vs. the narrow font.

    Layers allow us to view the relationships between variable font instances. We can see how certain variable properties might be correlated with each other in a design space and between masters. Similar approaches, like parallel coordinates, are better structured to show relationships between axes.

    Instances (likely masters) of a hypothetical variable font mapped to parallel coordinates. Note how the visualization reveals that there are only two possible values for optical size (distinct display and text variations). It also shows a possible correlation to a shorter x-height (as a display master may have smaller counters than a legibility minded text variation).

    Kai Chang’s talk on visualizing multiple dimensions with parallel coordinates provides a great primer on assigning data’s dimensions to visual properties and charts. Other approaches like Fontmap group things based off arbitrary features.

    These methods help us make sense of large sets of information with lots of related variables. Ultimately, they work by limiting our field of view and changing the angle through which we look at a set of variations. Instead of trying to see everything at once, we can break things down into manageable slices. Good interface controls allow us to quickly change our viewing perspective and organize axes. This UI is just as important as the visualizations themselves.

    Mapping Controls

    Variable font UI is most effective when it adapts along with the font. Thus, the more information a variable font can provide to the design program the better. Axes that are similar can be grouped together and collapsed under categories in the UI (for example, grouping axes that deal with serifs vs. font weight). Currently, there are discussions around allowing certain axes to be flagged (and ideally ordered and grouped) in order to intelligently reveal and hide advanced functionality through progressive disclosure within a design app.

    What axes are revealed and how they’re categorized come down to a combination of the type designer’s intent and the user’s personal preferences. Both of these are relative but important. Web designers / developers may want certain types of axes for adapting the font to their responsive design. Type designers may want to limit the number of available axes to ensure consistency or simplify licensing. In other cases, graphic designers may want access to powerful, creative variable fonts with a large number of axes (for example matching stroke weight and serifs to the thickness of other graphic elements). Because of this, variable font UI needs smart defaults that responsibly translate the type designer’s intention while retaining ability for designers to make modifications.

    In this line of thinking, every axis does not need to map 1:1 to a corresponding control. Multiple variable font axes can be assigned to a single macro control. On the font/type designer’s side, this would take the form as meta axes. On the interface size, this would take the form of assignable macro controls.

    Macro controls are a common UI pattern in software synthesizer interfaces—they allow multiple parameters to be mapped to any combination of controls.

    A standard feature in software synthesizers, macros let people assign any number of parameters to a single control. Note how the Macro 1 knob can adjust settings for both Oscillators A and B. Turning the macro knob also gives us peripheral information around change over time.

    Mappable controls allow people to break up and organize a design space to fit their needs. In addition to giving users the ability to sort and power multiple controls, this method can help people discover relationships between axes. In this example, changing the font weight and optical size at the same time allow you to see and select the right balance of the two.

    Typeshift’s dropdowns allow a reshuffling of axis controls for Voto Serif. Note how switching the optical axis to the pad control helps reveal how the font weight and optical size relate with each other.

    While the axes themselves are independent of each other, the visual outcomes they produce are intertwined. Font weight and optical size are both related to each other and should be considered simultaneously when designing. This swapping of axes is comparable to reordering dimensions (see the reordering section) in the parallel coordinate charts mentioned earlier. In both cases, the interface can provide a smart, opinionated organization and flexibly surface new combinations.

    Dynamic interfaces for dynamic fonts

    Interfaces for variable fonts should adapt along with the fonts themselves.  There’s no single static UI pattern that will work as the best solution for all variable fonts. Instead of debating sliders and knobs, we should be exploring hybrid interfaces that take advantage of what each UI element has to offer. Likewise, UI should be considered in the context of our design tools with the acknowledgement that it will change how we design, influencing our choices. This gives us a unique opportunity to further typographic creativity and utility.

  10. Integrating Animation into a Design System

    Keeping animation choreography cohesive from the outset of a project can be challenging, especially for small companies. Without a dedicated motion specialist on the team, it can be difficult to prioritize guidelines and patterns early in the design process. What’s more likely to happen is that animations will be added as the product develops.

    Unsurprisingly, the ad-hoc approach can lead to inconsistencies, duplications, and rework in the long run. But it also provides space for creative explorations and discoveries of what works and what doesn’t. As useful as it is to be able to establish system foundations early, it is also ok to let the patterns emerge organically as your team experiments and finds their own voice in motion.

    Once there are enough animations, you might start thinking about how to ensure some consistency, and how to reuse existing patterns rather than recreate them from scratch every time. How do you transition a few odd animations to a cohesive system? I find it helpful to start by thinking about the purpose of animations and the feel they’re designed to evoke.

    Start with purpose and feel


    Like any other element in a design system, animations must have a purpose. To integrate animation, start by looking through your interface and noting how and why you use animations in your particular product and brand.

    For example, at FutureLearn we noticed that we primarily use animation in three ways—to indicate a state change, to add an emphasis, or to reveal extra information:

    • A state change shows that an object has changed state due to user interaction. For example, a state can change on hover or on click. Animation here is used to soften the transition between states.
    • Emphasis animations are used to draw attention to specific information or an action, for example a nudge to encourage users to progress to the next step in the course.
    • Reveal animations are used to hide and reveal extra information, such as a menu being hidden to the side, a drop down, or a popover.

    There are no “standard” categories for the purposes of animations. Some products use a lot of standalone animations, such as animated tutorials. Some use screen transitions, others don’t. Some make personality and brand part of every animation, others group them into their own category, like in the Salesforce Lightning Design System.

    Animation types in Salesforce Lightning Design System are categorized in a different way to FutureLearn
    Animation types in Salesforce Lightning Design System are categorized in a different way to FutureLearn.

    The categories are specific to your interface and brand, and to how you use animation. They shouldn’t be prescriptive. Their main value is to articulate why your team should use animation, in your specific project.


    As well as having a purpose in helping the user understand how the product works, animation also helps to express brand personality. So another aspect to consider is how animation should feel. In “Designing Interface Animation,” Val Head explains how adjectives describing brand qualities can be used for defining motion. For example, a quick soft bouncy motion can be perceived as lively and energetic, whereas steady ease-in-outs feel certain and decisive.

    Brand qualities translated to motion
    Brand feel Animation feel Effect examples
    Lively and energetic Quick and soft Soft bounce
    Soft overshoot
    Playful and friendly Elastic or springy Squash and stretch
    Bouncy easing
    Decisive and certain Balanced and stable Ease-in, Ease-out Ease-in-out
    Calm and soft Small soft movements or no movement at all Opacity, color or blur changes, scale changes

    As you look through the animation examples in your interface, list how the animation should feel, and note particularly effective examples. For example, take a look at the two animations below. While they’re both animating the entrance and exit of a popover, the animations feel different. The Marvel example on the left feels brisk through the use of bouncy easing, whereas the small movement combined with opacity and blur changes in the FutureLearn example on the right make it feel calm and subtle.

    Popover animation comparison
    Popover animation on Marvel (left) and FutureLearn (right).

    There’s probably no right and wrong way to animate a popover. As far as I know it all depends on your brand and how you choose to communicate through motion. In your interface you might begin to notice animations that have the same purpose but have entirely different feels. Take note of the ones that feel right for your brand, so that you can align the other animations to them later on.

    Audit existing animations

    Once you have a rough idea of the role animation plays in your interface and how it should feel, the next step is to standardize existing animations. Like an interface inventory, you can conduct an inventory focused specifically on animations. Start by collecting all the existing animations. They can be captured with QuickTime or another screen recording application. At the same time, keep a record of them in a Google Doc, Keynote, or an Excel file—whatever suits you.

    Based on the purpose you defined earlier, enter categories, and then add the animations to the categories as you go. As you go through the audit, you might adjust those categories or add new ones, but it can be helpful not having to start with a blank page.

    Example of initial categories for collecting animations in Google Doc
    Example of initial categories for collecting animations in Google Doc.

    For each animation add:

    • Effect: The effect might be difficult to describe at first (Should it be “grow” or “scale,” “wiggle” or “jiggle”?). Don’t worry about the right words yet, just describe what you see–you can refine that later.
    • Example: This could be a screenshot of the animated element with a link to a video clip, or an embedded gif.
    • Timing and easing: Write down the values for each example, such as 2 seconds ease.
    • Properties: Write down the exact values that change, such as color or size.
    • Feel: Finally, add the feel of the animation—is it calm or energetic, sophisticated and balanced, or surprising and playful?

    After the inventory of animations at FutureLearn, we ended up with a document with about 22 animations, grouped into four categories. Here’s the state change category.

    The 'State Change' page from FutureLearn’s animation audit, conducted in a Google Doc
    The “State Change” page from FutureLearn’s animation audit, conducted in a Google Doc.

    Define patterns of usage

    Once you’ve collected all the animations, you can define patterns of usage, based on the purpose and feel. For example, you might notice that your emphasis animations typically feel energetic and playful, and that your state change transitions are more subtle and calm.

    If these are the tones you want to strike throughout the system, try aligning all the animations to them. To do that, take the examples that work well (i.e. achieve the purpose effectively and have the right feel) and try out their properties with other animations from the same category. You’ll end with a handful of patterns.

    Animation patterns on FutureLearn, grouped by purpose and feel
    Purpose Animation effects Feel
    Interactive state change Color, 2s ease
    Opacity, in – 0.3s, out – 1.1s ease
    Scale, 0.4 ease
    Calm, soft
    Emphasis Energetic pulse, 0.3s ease-in
    Subtle pulse
    Wiggle, 0.5s ease-in-out
    Energetic, playful
    Info reveal Slide down, 0.4 swing
    Slide up, 0.7s ease
    FadeInUp, 0.3 ease
    Rotate, 0.3 ease
    Certain, decisive, balanced

    Develop vocabulary to describe effects

    Animation effects can be hard to capture in words. As Rachel Nabors noted in “Communicating Animations,” sometimes people would start with “friendly onomatopoeias: swoosh, zoom, plonk, boom,” which can be used as a starting point to construct shared animation vocabularies.

    Some effects are common and can be named after the classic animation principles (squash and stretch, anticipation, follow through, slow in and out1) or can even be borrowed from Keynote (fade in, flip, slide down, etc.), others will be specific to your product.

    Vocabulary of animations in Salesforce Lightning Design System.
    Movement types in IBM Design Language.
    Movement types in IBM Design Language.

    There might also be animation effects unique to your brand that would require a distinctive name. For example, TED’s “ripple” animation in the play button is named after the ripple effect of their intro videos.

    The ripple effect in the intro video on TED (left) mirrored in the play button interaction (right).
    The ripple effect in the intro video on TED (left) mirrored in the play button interaction (right).

    Specify building blocks

    For designers and developers, it is useful to specify the precise building blocks that they can mix and match to create the new animations. Once you have the patterns and effects, you can extract precise values—timing, easing, and properties—and turn them into palettes. The animation palettes are similar to color swatches or a typographic scale.


    Timing is crucial in animation. Getting the timing right is not so much about perfect technical consistency as making sure that the timing feels consistent. Two elements animated with the same speed can feel completely different if they are different sizes or travel different distances.

    The idea of “dynamic duration” in Material Design focuses on how fast something needs to move versus how long it should take to get there:

    Rather than using a single duration for all animations, adjust each duration to accommodate the distance travelled, an element’s velocity, and surface changes.

    Sarah Drasner, the author of SVG Animations, suggested that we should deal with timing in animation like we deal with headings in typography. Instead of having a single value, you’d start with a “base” and provide several incremental steps. So instead of h1, h2 and h3, you’d have t1, t2, t3.

    Depending on the scale of the project, the timing palette might be simple, or it might be more elaborate. Most of the animations on FutureLearn use a base timing of 0.4. If this timing doesn’t feel right, most likely your object is traveling a shorter distance (in which case use “Shorter time”) or a longer distance (in which case use “Longer time”).

    • Shorter time: 0.3s: Shorter travel distance
    • Base: 0.4s: Base timing
    • Longer time: 0.6s: Longer distance traveled

    Similar ideas used in the duration guidelines for the Carbon Design System are related to the “magnitude of change”:

    Duration guidelines in Carbon Design System
    Duration guidelines in Carbon Design System.


    Different easing values can give an animation a distinctive feel. It’s important to specify when to use each value. The easing palettes in the Marvel Styleguide provide a handy guide for when to use each value, e.g. “Springy feel. Good for drawing focus.”

    Easing palette in the Marvel Styleguide
    Easing palette in the Marvel Styleguide.

    An easing palette can also be more generic and be written as a set of guidelines, as done in the Salesforce Lightning Design System, for example:

    For FutureLearn, we kept it even more simple and just limited it to two types of easing: Ease out “for things that move” (such as scale changes and slide up/down) and Linear “for things that don’t move” (such as color or opacity change).


    In addition to timing and easing values, it is useful to specify the properties that typically change in your animations, such as:

    • Opacity
    • Color
    • Scale
    • Distance
    • Rotation
    • Blur
    • Elevation

    Again, you can specify those properties as palettes with a base number, and the incremental steps to support various use cases. For example, when specifying scaling animations at FutureLearn, we noticed that the smaller an object is, the more it needs to scale in proportion to its size, for the change to be visible. A palette for scaling objects reflects that:

    Small: ×0.025
    Large objects
    e.g. an image thumbnail

    Base: ×0.1
    Medium objects
    e.g. button

    Large: ×0.25
    Small objects
    e.g. icon

    Although there’s no perfect precision to how these properties are set up, they provide a starting point for the team and help us reduce inconsistencies in our motion language.

    Agree on the guiding principles

    If you have guiding principles, it’s easier to point to them when something doesn’t fit. Some of the principles may be specific to how your team approaches animation. For example,

    Guiding principles for motion in Salesforce Lightning Design System are kept short and simple
    Guiding principles for motion in Salesforce Lightning Design System are kept short and simple.

    If your team is not yet confident with animation, it may be worth including some of the more general principles, such as “reserve it for the most important moments of the interaction” and “don’t let it get in the way of completing a task.”

    The guiding principles section can also include rationale for using animation in your product, and the general feel of your animation and how it connects with your brand. For example, IBM Design Language uses the physical movement of machines to extract the qualities they want to convey through animations, such as precision and accuracy.

    From the powerful strike of a printing arm to the smooth slide of a typewriter carriage, each machine movement serves a purpose and every function responded to a need.
    IBM Design Language
    IBM Design Language

    In IBM’s Design Language, the rhythmic oscillation of tape reels in motion is used in a metaphorical way to support user’s waiting experience.

    Guiding principles can also include spatial metaphors, which can provide a helpful mental model to people trying to create animations. Google’s Material Design is a great example of how thinking of interface as physical “materials” can provide a common reference for designers and developers when thinking about motion in their applications.

    In Material Design, 'Material can push other material out of the way.'
    In Material Design, “Material can push other material out of the way.”

    To sum up

    When integrating animation in design systems, try viewing it in relation to three things: guiding principles, patterns of usage, and building blocks. Guiding principles provide general direction, patterns of usage specify when and how to apply the effects, and building blocks aid the creation of new animations. Even if your animations were initially created without a plan, bringing them together in a cohesive, documented system can help you update and build on what you have in an intentional and brand-supporting way.

    Further reading:
    Creating Usability with Motion: The UX in Motion Manifesto
    Web Animation Past, Present, and Future
    Designing Interface Animation
    Animation in Responsive Design


  11. Practical User Research: Creating a Culture of Learning in Large Organizations

    Enterprise companies are realizing that understanding customer needs and motivations is critical in today’s marketplace. Building and sustaining new user research programs to collect these insights can be a major struggle, however. Digital teams often feel thwarted by large organizations that are slow to change and have many competing priorities for financial investments.

    As a design consultant at Cantina, I’ve seen companies at wildly different stages of maturity related to how customer research impacts their digital work. Sometimes executives struggle to understand the value without quantifiable numbers. Other times engineering teams see customer research and usability testing as a threat to delivery dates.

    While you can’t always tackle these issues directly, the great thing about large organizations is that they’re brimming with people, tools, and work practices forming an overall culture. By understanding and utilizing each of these organizational resources, digital teams can create an environment focused on learning from customers.

    I did some work recently for a client I’ll call WorkTech, who had this same struggle aligning their digital projects with the needs of their customers. WorkTech was attempting to redesign their entire ecommerce experience with a lean budget and team. In a roughly six month engagement, two of us from Cantina were tasked with getting the project back on track with a user-centered design approach. We had to work fast and start bringing customer insights to bear while moving the project forward. Employing a pragmatic approach that looked at people, tools, and work practices with a fresh set of eyes helped us create an environment of user research that better aligned the redesign with the needs of WorkTech’s customers.

    Get comfortable talking to People in different roles

    Effective user research programs start and end with people. Recognizing relationships and the motivations held by everyone interacting with a product or service encourages goodwill and can unearth key connections and other, less tangible benefits. To create and sustain a culture of learning in your company, find a group of users to interview—get creative, if you have to—and enlist the support of teammates and stakeholders.

    Begin by taking stock of anyone connected to your product. You won’t always find a true set of end users internally, but everyone can help raise awareness of the value of user research—and they can help your team sustain forward progress. Ask yourself the following questions to find allies and research resources:

    • What departments use your product indirectly, but have connections to people in the user roles you’re targeting?
    • Is there a project sponsor who can help sell the value of research and connect you to additional staff that can assist in some capacity?
    • Are there employees in other departments whose individual goals align with getting better feedback from users?
    • Are there departments within the organization (sales, customer service) who can offer connections to customers wanting to provide candid feedback?

    Our WorkTech project didn’t have a formal research budget for recruiting users (or any other research task). What we did have going for us was a group of internal users who gave our team immediate access to an initial pool of research participants. The primary platform we were hired to help redesign was used by two groups: WorkTech employees and the customers they interacted with. Over time, our internal users were able to connect us with their external counterparts, amplifying the number of people offering feedback significantly.

    Maximize the value of every interview

    While interviewing external customers, we kept an eye on the long term success of our research program and concluded each session by asking participants:

    • If they’d be willing to join another session in the future (most were willing)
    • If they could share names of anyone else in their network (internal or external) they thought would have feedback to offer

    During each conversation, we also identified distinct areas of expertise for each user. This allowed us to better target future usability testing sessions on specific pieces of functionality.

    Using this approach, our pool of potential participants grew exponentially and we gained insight into the shared motivations of different user personas. Taking stock of such different groups of people using the platform also revealed opportunities that helped us prioritize different aspects of the overall redesign effort.

    Find helpful Tools that are already available or free

    Tools can’t create an effective user research program on their own, but they are hugely helpful during the actual execution of research. While some organizations have an appetite for purchasing dedicated “user research” platforms able to handle recruitment, scheduling, and session recordings, many others already have tools in place that bring value to the organization in different areas. If your budget is tiny (or nonexistent), you may be able to repurpose or extend the software and applications your company already uses in a way that can support talking to customers.

    Consider the following:

    • Are there current tools available in the organization (perhaps in other groups) that could be adapted for research purposes?
    • Are users already familiar with any tools or workflows you can utilize during research activities?
    • If new tools for automating specific tasks are out of budget, can your team build up repeatable templates and processes manually?

    We discovered early on at WorkTech that our internal user base had very similar toolsets because of company-wide technology purchases. Virtually all employees already had Cisco Webex installed and were familiar with remote conferencing and sharing their screen.

    WorkTech offices and customers were spread across the continental United States, so it made sense for our sessions to be remote, moderated conversations via phone and teleconference. Using Webex allowed the internal users to focus on the actual interview, avoiding the friction they might have felt attempting to use new technology.

    Leveraging pre-existing tools also meant we could expand our capabilities without incurring significant new costs. (The only other tool we introduced was a free InVision account, which allowed us to create simple prototypes of new UI concepts, conduct weekly usability tests, and document and share our findings quickly and easily.)

    Document and define templates as you go

    Many digital research tools are simply well-defined starting points—templates for the various types of communication and idea capture needed. If purchasing access to these automated tools is out of the question, using a little elbow grease can be equally effective over time.

    At WorkTech, maintaining good documentation trails minimized the time spent creating new materials for each round of research and testing. For repeatable tasks like creating scripts and writing recruitment emails, we simply saved and organized each document as we created it. This allowed us to build a library of reusable templates over time. Even though it was a bit of a manual effort, this payoff increased with every additional round of usability testing.

    Utilizing available tools eliminates another significant hurdle to getting started—time delays. In large organizations with tight purchase protocols, using repurposed and free tools can enable teams to get moving quickly. Filling in the remaining gaps with good documentation and repeatable templates covers a wide range of scenarios and doesn’t let finances act as a blocker when collecting insights from users. 

    Take a fresh look at your company’s Work Practices

    A culture of learning won’t be sustainable over the long term if the lessons learned from user research aren’t informing what is being built. Bringing research insights to bear on your product or site is where everything pays off, ensuring digital teams can focus on what delivers the highest value to customers.

    Being successful here requires a keen understanding of the common processes your organization uses to get things accomplished. By being aware of an organization’s current work practices (not some utopian version), digital teams can align what they’ve learned with practices that help ensure solutions get shipped.

    Dig into the work practices in your organization and identify ways to meet people where they are:

    • Are there centrally-located workspaces that can be used for posting insights and keeping research outcomes in front of the team?
    • Are there any regularly-scheduled meetings with diverse teams that would be an opportunity to present research findings?
    • Are there established sprint cycles or product management reviews you can align with research efforts?

    The WorkTech team collaborating with us on the project already had weekly meetings on the calendar, with an open agenda for high priority items. Knowing it would be important to get buy-in from this group, we set up our research and usability sessions each week on Tuesdays. This allowed us to establish a cadence where every Tuesday we tested prototypes, and every Wednesday we presented findings at the WorkTech team meeting. As new questions or design concepts to validate came up, the team was able to document them, pause any further debates, and move on to other topics of discussion. Everyone knew testing was a weekly occurrence, and within a few weeks even the most skeptical developer started asking us to get customer feedback on specific features they were struggling with.

    Schedule regular customer sessions even before you are “ready”

    Committing to a cadence of regular weekly sessions also allowed us to separate scheduling from test prep tasks. We didn’t wait to schedule sessions only when we desperately needed feedback. Because the time was already set aside each Tuesday, we simply had to develop questions and tests for the highest priority topic at that point in time. If something wasn’t quite ready, the next set of sessions was only a week away.

    Using these principles, we conducted 40+ sessions over the course of 12 weeks, gathering valuable insights from the two primary user groups. We were able to gather quantifiable data pointing to one design pattern over another, which minimized design debates and instilled confidence in the research program and the design. In addition to building relationships with users across the spectrum, the sessions helped us uncover several key interface issues that we were then able to design around.

    Even more valuable than the interface issues were general uses cases that came to light, where the website experience was only one component in a large ecosystem of internal processes at customers’ organizations. These insights proved valuable for our redesign project, but also provided a deeper understanding of WorkTech’s customer base, helping to prove the value of research efforts to key stakeholders.

    Knowing the schedules and team norms in your organization is critical for creating a user research program whose insights get integrated into the design and development process. The insights of a single set of sessions are important, but creating a culture surrounding user research is more valuable to the long term success of your product or site, as is a mindset of ongoing empathy toward users.

    To help grow and sustain a culture of research, though, teams have to be able to prove the value in financial terms. Paul Boag said it elegantly in the third Smashing Magazine book: “Because cost is (often a) primary reason for not testing, money has to be part of your justification for testing.”

    The long term success of your program will likely be tied to how well you can prove its ROI in business terms, even though the methods described here minimize the need to ask for money. In other words, translate the value of user research to terms any business person can understand. Find ways to quantify the work hours currently lost to feature debates and building un-validated features, and you’ll uncover business costs that can be eliminated.

    User research doesn’t have to be a big dollar, corporate initiative. By paying attention to the people, tools, and work practices within an organization, your team can demonstrate the value of user research on the ground, which will open doors to additional resources in the future.

  12. Team Conflict: Four Ways to Deflate the Discord that’s Killing Your Team

    It was supposed to be a simple web project. Our client needed a site that would allow users to create, deploy and review survey results. Aside from some APIs that weren’t done, I wasn’t very worried about the project. I was surprised that my product manager was spending so much time at the client’s office.

    Then, she explained the problem. It seemed that the leaders of product, UX and engineering didn’t speak to each other and, as a result, she had to walk from office to office getting information and decisions.

    When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders. When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders.
    When two people have a bad interaction, they can work it out or let the conflict grow, spreading it to other team members and their leaders.

    The conflicts probably started small. One bad interaction, then another, then people don’t like each other, then teams don’t work together well. The small scrape becomes a festering wound that slows things down, limits creativity and lowers morale.

    Somehow as a kid working my way through school I discovered I had a knack for getting around individuals or groups that were fighting with each other. I simply figured out who I needed to help me accomplish a task, and I learned how to convince, cajole or charm them into doing it. I went on to teach these skills to my teams.

    That sufficed for a while. But as I became a department head and an adviser to my clients, I realized it’s not enough to make it work. I needed to learn how to make it better. I needed to find a way to stop the infighting I’ve seen plague organizations my entire career. I needed to put aside my tendency to make the quick fix and have hard conversations.

    It’s messy, awkward and hard for team leaders to resolve conflict but the results are absolutely worth it. You don’t need a big training program, a touchy-feely retreat or an expensive consultant. Team members or team leads don’t have to like each other. What they have to do is find common ground, a measure of respect for one another, and a willingness to work together to benefit the project.

    Here are four ways to approach the problem.

    Start talking

    No matter how it looks at first, it’s always a people problem.
    Gerald M. Weinberg, The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully

    Resist the urge to wait for the perfect time to address team conflict. There’s no such thing. There will always be another deadline, another rollout, another challenge to be met.

    In our office, a UX designer and product manager were having trouble getting along. Rather than take responsibility, they each blamed our “process” and said we needed to clarify roles and procedures. In other words, they each wanted to be deemed “in charge” of the project. Certainly I could have taken that bullet and begun a full-on assessment of our processes and structure. By taking the blame for a bad company framework, I could have dodged some difficult conversations.  But I knew our process wasn’t the problem.

    First, I coached the product manager to be vulnerable, not an easy thing for him to do. I asked him to share his concerns and his desire to have a more productive relationship with the UX designer. The PM’s willingness to be uncomfortable and open about his concerns lifted the tension. Once he acknowledged the elephant in the room—namely that the UX designer was not happy working with him—the designer became more willing to risk being honest. Eventually, they were able to find a solution to their disagreements on the project, largely because they were willing to give each other a measure of respect.

    The worst thing I’ve seen is when leaders move people from team to team hoping that they will magically find a group of people that work well together, and work well with them. Sometimes the relocated team members have no idea that their behavior or performance isn’t acceptable. Instead of solving the problem, this just spreads the dissatisfaction.

    Instead, be clear right from the beginning that you want teams that will be open about challenges, feel safe discussing conflicts, and be accountable for solving them.

    Have a clear purpose

    Although many aspects of our collective endeavor are open for discussion, choice of mountain is not among them.
    J. Richard Hackman, Leading Teams: Setting the Stage for Great Performances

    I was working on an enterprise CMS re-design and re-platform. Our weekly review and estimation sessions were some of the most painful meetings of my career. There was no trust or shared purpose—even estimating a simple task was a big fight.

    When purpose and priorities are murky you are likely to find conflict. When the team doesn’t know what mountain they are trying to climb, they tend to focus on the parts of the project that are most relevant to them. With each team member jealously guarding his or her little ledge, it’s almost impossible to have cooperation.

    This assault on productivity is likely because the project objective is non-existent, or muddled nonsense, or so broad the team doesn’t see how it can have an impact. Or, maybe the objective is a moving target, constantly shifting.

    Size can be a factor.  I’ve seen enterprise teams with clear missions and startups with such world-changing objectives they can’t figure out how to ship something that costs less than a million dollars.

    When I’m meeting with prospects or new clients I look at three areas to see if they are having this problem:

    • What language do they use to describe each other? Disconnected teams say “UX thinks,” “The dev team” or “product wants.” Unified teams say “we.”
    • How easy or hard is task estimation? Disconnected teams fight about the level of difficulty. United teams talk about tradeoffs and argue about what’s best for the product or customers.
    • Can they easily and consistently describe their purpose? Disconnected teams don’t have a crisp and consistent answer. Unified teams nod their heads when one of their members shares a concise answer.

    If a team is disconnected, it’s likely because you haven’t given them a common goal. A single email or a fancy deck isn’t enough. Make your objectives simple and repeat them so much that the team groans every time you start.

    Plan conversations

    Words do not sit in our brains in isolation. Each word is surrounded by its own connotations, memories and associations
    Simon Lancaster, Winning Minds: Secrets From the Language of Leadership

    Years ago I was frustrated to tears by a manager who, I felt, took from me the product I spent two years building. I knew I needed to talk with him but I struggled to find a productive way to tell him why I was upset.  (Telling someone he is being a jackass is not productive.)

    A good friend in HR helped me script the conversation. It had three parts:

    • I really work well when…
    • This situation is bothering me because…
    • What I’d like to see happen is…

    Leaders have an important role to play in resolving issues. When a leader decides that their person is right and another person is wrong it turns a team problem into an organization problem. Instead we should should provide perspective, context and show how actions could be misunderstood.

    Leaders also need to quickly, clearly and strongly call about bad behavior. When I found out one of my people raised their voice at a colleague, I made it clear that wasn’t acceptable and shouldn’t happen again. He admitted that he lost his cool, apologized and then we started working on the resolving the situation.

    Require accountability

    Being responsible sometimes means pissing people off.
    General Colin Powell,former U.S. Secretary of State

    If you have a problem and you go to Holly Paul, an inspiring HR leader, you can expect that she will listen. You can also expect that she’ll work with you on a plan to resolve it. Most importantly you can expect she will make sure you are doing what you said you’d do when you said you would do it.

    Before I met Holly I would listen to problems then try to go solve them. Now I work with the person and tell them that I will be checking back with them, often putting the reminder in my calendar during the conversation so I don’t forget.

    Since I started focusing on fixing conflict, I’ve seen great changes on my team. Many of them have started for the first time dealing with the people, fixing their issues and forging much stronger relationships. Our team is stronger and having a greater influence on the organization.

    It’s messy, awkward and hard. I’ve been working on this for a long time and I still make mistakes. I still don’t always want to push when I meet resistance. This will never be easy, but it will be worth it and it’s your responsibility as a leader. For however long these people are with you, you need to make them better as individuals and a unit.

    You don’t need a big training, a touchy-feely retreat or an expensive consultant. You just need to start doing the work every day. The rest will come.

  13. Color Accessibility Workflows

    A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Geri Coady's new book, Color Accessibility Workflows, available now from A Book Apart.

    The Web Content Accessibility Guidelines (WCAG) 2.0 contain recommendations from the World Wide Web Consortium (W3C) for making the web more accessible to users with disabilities, including color blindness and other vision deficiencies.

    There are three levels of conformance defined in WCAG 2.0, from lowest to highest: A, AA, and AAA. For text and images of text, AA is the minimum level that must be met.

    AA compliance requires text and images of text to have a minimum color contrast ratio of 4.5:1. In other words, the lighter color in a pair must have four-and-a-half times as much luminance (an indicator of how bright a color will appear) as the darker color. This contrast ratio is calculated to include people with moderately low vision who don’t need to rely on contrast-enhancing assistive technology, as well as people with color deficiencies. It’s meant to compensate for the loss in contrast sensitivity often experienced by users with 20/40 vision, which is half of normal 20/20 vision.

    Level AAA compliance requires a contrast ratio of 7:1, which provides compensation for users with 20/80 vision, or a quarter of normal 20/20 vision. People who have a degree of vision loss more than 20/80 generally require assistive technologies with contrast enhancement and magnification capabilities.

    Text that acts as pure decoration, nonessential text that appears in part of a photograph, and images of company logos do not strictly need to adhere to these rules. Nonessential or decorative text is, by definition, not essential to understanding a page’s content. Logos and wordmarks may contain textual elements that are essential to broadcasting the company’s visual identity, but not to conveying important information. If necessary, the logo may be described by using an alt attribute for the benefit of a person using screen-reader software. To learn more, check out accessibility specialist Julie Grundy’s blog post on Simply Accessible, where she goes into the best practices around describing alt attributes.

    Text size plays a big role in determining how much contrast is required. Gray text with an RGB value of (150,150,150) on a pure white background passes the AA level of compliance, as long as it’s used in headlines above 18 points. Gray text with an RGB value of (110,110,110) passes the AA level at any text size, and will be AAA compliant if used as a headline above 18 points (Fig 3.1). A font displayed at 14 points may have a different level of legibility compared to another font at 14 points due to the wide diversity of type styles, so keep this in mind, especially when using very thin weights.

    Text size also plays a role when calculating compliance ratios.

    Fig 3.1: Text size also plays a role when calculating compliance ratios.

    Personally, I recommend that all body text be AAA compliant, with larger headlines and less important copy meeting AA compliance as a bare minimum. Keep in mind that these ratios refer to solid-colored text over solid-colored backgrounds, where a single color value can be measured. Overlaying text on a gradient, pattern, or photograph may require a higher contrast value or alternative placement, such as over a solid-colored strip, to provide sufficient legibility.

    These compliance ratios are often what folks mean when they claim that achieving accessible design by “ticking off boxes” can only come at the cost of stifled creativity or restricted color choices. But that simply isn’t true. Experimentation with a color-contrast checker proves that many compliance ratios are quite reasonable and easy to achieve—especially if you are aware of the rules from the beginning. It would be much more frustrating to try to shift poor color choices into something compliant later in the design process, after branding colors have already been chosen. If you fight your battles up front, you’ll find you won’t feel restricted at all.

    If all this talk of numbers seems confusing, I promise there’ll be no real math involved on your side. You can easily find out if your color pairs pass the test by using a color-contrast checker.

    Contrast checkers

    One of my favorite tools is Lea Verou’s Contrast Ratio (Fig 3.2). It gives you the option of entering a color code for a background and a color code for text, and it calculates the ratio for you.

    Lea Verou’s Contrast Ratio checker.

    Fig 3.2: Lea Verou’s Contrast Ratio checker.

    Contrast Ratio supports color names, hex color codes, RGBA values, HSLA values, and even combinations of each. Supporting RGBA and HSLA values means that Verou’s tool supports transparent colors, a handy feature. You can easily share the results of a check by copying and pasting the URL. Additionally, you can modify colors by changing the values in the URL string instead of using the page’s input fields.

    Another great tool that has the benefit of simultaneously showing whether a color combination passes both AA and AAA compliance levels is Jonathan Snook’s Colour Contrast Check (Fig 3.3).

    Jonathan Snook’s Colour Contrast Check.

    Fig 3.3: Jonathan Snook’s Colour Contrast Check.

    At the time of writing, Colour Contrast Check doesn’t support HSL alpha values, but it does display the calculated brightness difference and color difference values, which might interest you if you want a little more information.

    Color pickers

    If you need help choosing accessible colors from the start, try Color Safe. This web-based tool helps designers experiment with and choose color combinations that are immediately contrast-compliant. Enter a background color as a starting point; then choose a standard font family, font size, font weight, and target WCAG compliance level. Color Safe will return a comprehensive list of suggestions that can be used as accessible text colors (Fig 3.4).

    Color Safe searches for compliant text colors based on an existing background color.

    Fig 3.4: Color Safe searches for compliant text colors based on an existing background color.

    Adjustment tools

    When faced with color choices that fail the minimum contrast ratios, consider using something like Tanaguru Contrast Finder to help find appropriate alternatives (Fig 3.5). This incredibly useful tool takes a foreground and background color pair and then presents a range of compliant options comparable to the original colors. It’s important to note that this tool works best when the colors are already close to being compliant but just need a little push—color pairs with drastically low contrast ratios may not return any suggestions at all (Fig 3.6).

    Examples of color pairs that are not AA compliant.

    Fig 3.5: This color pair is not AA compliant.

    A selection of Tanaguru’s suggested AA-compliant alternatives.

    Fig 3.6: A selection of Tanaguru’s suggested AA-compliant alternatives.

    There’s more where that came from!

    Check out the rest of Color Accessibility Workflows at A Book Apart.

  14. The Mindfulness of a Manual Performance Audit

    As product owners or developers, we probably have a good handle on which core assets we need to make a website work. But rarely is that the whole picture. How well do we know every last thing that loads on our sites?

    An occasional web performance audit, done by hand, does make us aware of every last thing. What’s so great about that? Well, for starters, the process increases our mindfulness of what we are actually asking of our users. Furthermore, a bit of spreadsheet wizardry lets us shape our findings in a way that has more meaning for stakeholders. It allows us to speak to our web performance in terms of purpose, like so:

    Graphic of a pie chart showing performance audit results

    Want to be able to make something like that? Follow along.

    Wait, don’t we have computers for this sort of thing?

    A manual audit may seem like pointless drudgery. Why do this by hand? Can’t we automate this somehow?

    That’s the whole point. We want to achieve mindfulness—not automate everything away. When we take the time to consider each and every thing that loads on a page, we get a truer picture of our work.

    It takes a human mind to look at every asset on a page and assign it a purpose. This in turn allows us to shape our data in such a way that it means something to people who don’t know what acronyms like CSS or WOFF mean. Besides, who doesn’t like a nice pie chart?

    Here’s the process, step by step:

    1. Get your performance data in a malleable format.
    2. Extract the information necessary.
    3. Go item by item, assigning each asset request a purpose.
    4. Calculate totals, and modify data into easily understood units.
    5. Make fancy pie charts.

    The audit may take half an hour to an hour the first time you do it this way, but with practice you’ll be able to do it in a few minutes. Let’s go!

    Gathering your performance data

    To get started, figure out what URL you want to evaluate. Look at your analytics and try to determine which page type is your most popular. Don’t just default to your home page. For instance, if you have a news site, articles are probably your most popular page type. If you’re analyzing a single-page app, determine what the most commonly accessed view is.

    You need to get your network activity at that URL into a CSV/spreadsheet format. In my experience, the easiest way to do this is to use WebPagetest, whose premise is simple: give it a URL, and it will do an assessment that tries to measure perceived performance.

    Head over to WebPagetest and pop your URL in the big field on the homepage. However, before running the test, open the Advanced Settings panel. Make sure you’re only running one test, and set Repeat View to First View Only. This will ensure that you don’t have duplicate requests in your data. Now, let the test run—hit the big “Start Test” button.

    WebPagetest screenshot

    Once you have a results page, click the link in the top right corner that says “Raw object data”.

    WebPagetest screenshot showing raw object data

    A CSV file will download with your network requests set out in a spreadsheet that you can manipulate.

    Navigating & scrubbing the data

    Now, open the CSV file in your favorite spreadsheet editor: Excel, Numbers, or (my personal favorite) Google Sheets. The rest of this article will be written with Google Sheets in mind, though a similar result is certainly possible with other spreadsheet programs.

    At first it will probably seem like this file contains an unwieldy amount of information, but we’re only interested in a small amount of this data. These are the three columns we care about:

    • Host (column F)
    • URL (column G)
    • Object Size (column N)

    The other columns you can just ignore, hide, or delete. Or even better: select those three columns, copy them, and paste them into a new spreadsheet.

    Auditing each asset request

    With your pared-down spreadsheet, insert a new first column and label it “Purpose”. You can also include a Description/Comment column, if you wish.

    Screenshot of an audit spreadsheet

    Next, go down each row, line by line, and assign each asset request a purpose. I suggest something like the following:

    • Content (e.g., the core HTML document, images, media—the stuff users care about)
    • Function (e.g., functional JavaScript files that you have authored, CSS, webfonts)
    • Analytics (e.g., Google Analytics, New Relic, etc.)
    • Ads (e.g., Google DFP, any ad networks, etc.)

    Your Purpose names can be whatever you want. What matters is that your labels for each purpose are consistent—capitalization and all. They need to group neatly in order to generate the fancy charts later. (Pro tip: use data validation on this column to ensure consistency in your spreadsheet.)

    So how do you determine the purpose? Typically, the biggest clue is the “Host” column. You will, very quickly, start to recognize which hosts provide what. Your root URL will be where your document comes from, but you will also find:

    • CDN URLs like cloudfront.net, or cloudflare.com. Sometimes these have images (which are typically content); sometimes they host CSS or JavaScript files (functionality).
    • Analytics URLs like googletagservices.com, googletagmanager.com, google-analytics.com, or js-agent.newrelic.com.
    • Ad URLs like doubleclick.net or googlesyndication.com.

    If you’re ever unsure of a URL, either try it out yourself in your browser, or literally google the URL. (Hint: if you don’t recognize the URL right away, it’s most likely ad-related.)


    Just doing the steps above will likely be eye-opening for you. Stopping to consider each asset on a page, and why it’s there, will help you be mindful of every single thing the page loads.

    You may be in for some surprises the first time you do this. A few unexpected items might turn up. A script might be loaded more than once. That social widget might be a huge page weight. Requests coming from ads might be more numerous than you thought. That’s why I suggested a Description/Comment column—you can make notes there like “WTF?” and “Can we remove this?”

    Augmenting your data

    Before you can generate fancy pie charts, you’ll need to do a little more spreadsheet wrangling. Forewarned is forearmed—extreme spreadsheet nerdery lies ahead.

    First, you need to translate the request sizes to kilobytes (KB), because they are initially supplied in bytes, and no human speaks in terms of bytes. Next to the column “Object Size,” insert another column called “Object Size (KB).” Then enter a formula in the first cell, something like this:

    Audit spreadsheet detail

    Translation: you’re simply dividing the amount in the cell from the previous column (E2, in this case) by 1000. You can highlight this new cell, then drag the corner down the entire column to do the same for each row.

    Animated GIF of a spreadsheet process

    Totaling requests

    Now, to figure out how many HTTP requests are related to each Purpose, you need to do a special kind of count. Insert two more columns, one labeled “Purpose Labels” and the second “Purpose Reqs.” Under Purpose Labels, in the first row, enter this formula:

    Spreadsheet detail

    This assumes that your purpose assessment is column B. If it’s not, swap out the “B” in this example for your column name. This formula will go down column B and output a result if it’s unique. You only need to enter this in the first cell of the column. This is one reason why having consistency in the Purpose column is important.

    Now, under the second column you made (Purpose Reqs) in the first cell, enter this formula:

    Spreadsheet detail

    This formula will also go down column B, and do a count if it matches with something in column G (assuming column G is your Purpose Labels column). This is the easiest way to total how many HTTP requests fall into each purpose.

    Totaling download size by purpose

    Finally, you can now also total the data (in KB) for each purpose. Insert one more column and call it Purpose Download Size. In the first cell, insert the following formula:


    This will total the data size in column F if its purpose in column B matches G2 (i.e., your first Purpose Label from the section above). In contrast to the last two formulas, you’ll need to copy this formula and modify it for each row, making the last part (“G2”) match the row it’s on. In this case, the next one would end in “G3”.

    Animated GIF showing a spreadsheet process

    Make with the fancy charts

    With your assets grouped by purpose, data translated to KB, number of requests counted, and download size totaled, it will be pretty easy to generate some charts.

    The HTTP request chart

    To make an HTTP request chart, select the columns Purpose Label and Purpose Reqs (columns G and H in my example), and then go to Insert > Chart. Scroll down the list of possible charts, and choose a pie chart. Be sure to check the box marked “Use column G as labels.”

    Screenshot showing Google Sheets’ Chart Editor

    Under the “Customization” tab, edit the Title to say “HTTP Requests”; under “Slice,” be sure “Value” is selected (the default is “Percentage”). We do this because the number of requests is what you want to convey here.

    Screenshot showing Google Sheets’ Chart Editor

    Go ahead—tweak the colors to your liking. And ditch Arial while you’re at it.

    Download-size chart

    The download-size-by-purpose pie chart is very similar. Select the columns Purpose Label and Purpose Download Size (columns G & I in my example); then go to Insert > Chart. Scroll down the list of possible charts and choose a pie chart. Be sure to check the box marked “Use column G as labels”.

    Under the “Customization” tab, edit the Title to say “Download Size”; under “Slice,” be sure “Value” is selected as well. We do this so we can indicate the total KB for each purpose.

    Or, you can grab a ready-made template. If you want to see a completed assessment, check out the one I did on an A List Apart article. I’ve also made a blank file with a lot of the trickier spreadsheet stuff already done. Feel free to go to File > Make a Copy so you can play around with it. You just need to get your page data from WebPagetest and paste in the three columns. After that, you can start your line-by-line assessment.

    Telling the good from the bad

    If you show your data to a stakeholder, they may be surprised by how much page weight goes to things like ads or analytics. On the other hand, they might respond by asking what we should be aiming for. That question is a little harder to answer.

    Some benchmarks get bandied about—1 MB or less, a WebPagetest Score of 1000, a Google PageSpeed score of over 90, and so on. But those are very arbitrary parameters and, depending on your project, unattainable ideals.

    My suggestion? Do an assessment like this on your competitors. If you can come back to your stakeholders and show how two or three competitors stack up, and show them what you’re doing, that will go much further in championing performance.

    Remember that performance is never “done”—it can only improve. What might help your organization is doing assessments like this over time and presenting page performance as an ongoing series of bar charts. With a little effort (and luck), you should be able to demonstrate that the things your organization cares about are continually improving. If not, it will present a much more compelling case for why things need to change for the better.

    So you have some pretty charts. Now what?

    Your charts’ usefulness will vary according to the precise business needs and politics of your organization.

    For instance, let’s say you’re a developer, and a project manager asks you to add yet another ad-metrics script to your site. After completing an assessment like the one above, you might be able to come back and say, “Ads already constitute 40 percent of our page weight. Do you really want to pile on more?”

    Because you’ve ascribed purpose to your asset requests, you’ll be able to offer data like that. I once worked with a project manager who started pushing back on such requests because I was able to give them easy-to-understand data of this sort. I’m not saying it will always turn out this way, but you need to give decision makers information they can grasp.

    Remember, too, that you are in charge of the Purpose column. You can make up any purpose you want. Interested in the impact that movie files have on your site relative to everything else? Make one of your purposes “Movies.” Want to call out framework files versus files you personally author? Go for it!

    I hope that this article has made you want to consider, and reconsider, each and every thing you download on a given page. Each and every request. And, in the process of doing this, I hope you are equipped to call out by purpose every item you ask your users to download. That will allow you to talk with your stakeholders in a way that they understand, and will help you make the case for better performance choices.

    Further reading:

  15. Web Maintainability Industry Survey: How Do We Maintain?

    A note from the editors: As a community, we can learn so much from discovering what other developers are doing around the world. We encourage everyone to participate in this very brief survey created by Jens Oliver Meiert. Jens will share the results—and an updated guide to web maintainability based on the findings—in a few weeks.

    How often do we consider the maintenance and general maintainability of our websites and apps? What steps do we actively take to make and keep them maintainable? What stands in the way when we maintain our and other people’s projects?

    Many of us, as web developers, know very well how to code something. But whether we know just as well how to maintain what we—and others—have written, that is not so clear. Our bosses and clients may not always think about maintenance down the road, either.

    As an O’Reilly author and former Googler, I’ve been studying the topic of maintainability since 2008—and we have yet to gather our industry’s views on the subject. To help us all get a better picture of how we maintain and how we can maintain more effectively, I set up a brief, unassuming survey (announcement) and kindly ask for your assistance.

    The survey aims to collect specific practices and resources—in other words, your views on current practices (both useful and harmful) and everything you find helpful:

    • What helps maintenance?
    • What prevents maintenance?
    • What resources do developers turn to for improving maintainability?

    The outcome of the survey and an updated guide to web maintainability will be published in a few weeks on my website, meiert.com (and noted on my Twitter profile). Thank you for your support.

  16. Fait Accompli: Agentive Tech Is Here

    A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Chris Noessel's new book, Designing Agentive Technology, AI That Works for People, available now from Rosenfeld Media. For a limited time, ALA readers can get 20% off Chris's book by using the code 'ALADAT' on the Rosenfeld Media site.

    Similar to intelligence, agency can be thought of as a spectrum. Some things are more agentive than others. Is a hammer agentive? No. I mean if you want to be indulgently philosophical, you could propose that the metal head is acting on the nail per request by the rich gestural command the user provides to the handle. But the fact that it’s always available to the user’s hand during the task means it’s a tool—that is, part of the user’s attention and ongoing effort.

    Less philosophically, is an internet search an example of an agent? Certainly the user states a need, and the software rummages through its internal model of the internet to retrieve likely matches. This direct cause-and-effect means that it’s more like the hammer with its practically instantaneous cause-and-effect. Still a tool.

    But as you saw before, when Google lets you save that search, such that it sits out there, letting you pay attention to other things, and lets you know when new results come in, now you’re talking about something that is much more clearly acting on behalf of its user in a way that is distinct from a tool. It handles tasks so that you can use your limited attention on something else. So this part of “acting on your behalf”—that it does its thing while out of sight and out of mind—is foundational to the notion of what an agent is, why it’s new, and why it’s valuable. It can help you track something you would find tedious, like a particular moment in time, or a special kind of activity on the internet, or security events on a computer network.

    To do any of that, an agent must monitor some stream of data. It could be something as simple as the date and time, or a temperature reading from a thermometer, or it could be something unbelievably complicated, like watching for changes in the contents of the internet. It could be data that is continuous, like wind speed, or irregular, like incoming photos. As it watches this data stream, it looks for triggers and then runs over some rules and exceptions to determine if and how it should act. Most agents work indefinitely, although they could be set to run for a particular length of time or when any other condition is met. Some agents like a spam filter will just keep doing their job quietly in the background. Others will keep going until they need your attention, and some will need to tell you right away. Nearly all will let you monitor them and the data stream, so you can check up on how they’re doing and see if you need to adjust your instructions.

    So those are the basics. Agentive technology watches a datastream for triggers and then responds with narrow artificial intelligence to help its user accomplish some goal. In a phrase, it’s a persistent, background assistant.

    If those are the basics, there are a few advanced features that a sophisticated agent might have. It might infer what you want without your having to tell it explicitly. It might adapt machine learning methods to refine its predictive models. It might gently fade away in smart ways such that the user gains competence. You’ll learn about these in Part II, “Doing,” of this book, but for now it’s enough to know that agents can be much smarter than the basic definition we’ve established here.

    How Different Are Agents?

    Since most of the design and development process has been built around building good tools, it’s instructive to compare and contrast them to good agents—because they are different in significant ways.

    Table 2.1: Comparing Mental Models
    A Tool-Based Model An Agent-Based Model
    A good tool lets you do a task well. A good agent does a task for you per your preferences.
    A hammer might be the canonical model. A valet might be the canonical model.
    Design must focus on having strong affordances and real-time feedback. Design must focus on easy setup and informative touchpoints.
    When it’s working, it’s ready-to-hand, part of the body almost unconsciously doing its thing. When the agent is working, it’s out of sight. When a user must engage its touchpoints, they require conscious attention and consideration.
    The goal of the designer is often to get the user into flow (in the Mihalyi Csikszentmihalyi sense) while performing a task. The goal of the designer is to ensure that the touchpoints are clear and actionable, to help the user keep the agent on track.

    Drawing a Boundary Around Agentive Technology

    To make a concept clear, you need to assert a definition, give examples, and then describe its boundaries. Some things will not be worth considering because they are obviously in; some things will not be worth considering because they are obviously out; but the interesting stuff is at the boundary, where it’s not quite clear. What is on the edge of the concept, but specifically isn’t the thing? Reviewing these areas should help you get clear about what I mean by agentive technology and what lies beyond the scope of my consideration.

    It’s Not Assistive Technology

    Artificial narrow intelligences that help you perform a task are best described as assistants, or assistive technology. We need to think as clearly about assistive tech as we do agentive tech, but we have a solid foundation to design assistive tech. We have been working on those foundations for the last seven decades or so, and recent work with heads-up displays and conversational UI are making headway into best practices for assistants. It’s worth noting that the design of agentive systems will often entail designing assistive aspects, but they are not the same thing.

    It seems subtle at first, but consider the difference between two ways to get an international airline ticket to a favorite destination. Assistive technology would work to make all your options and the trade-offs between them apparent, helping you avoid spending too much money or winding up with a miserable, five-layover flight, as you make your selection. An agent would vigilantly watch all airline offers for the right ticket and pipe up when it had found one already within your preferences. If it was very confident and you had authorized it, it might even have made the purchase for you.

    It’s Not Conversational Agents

    “Agent” has been used traditionally in services to mean “someone who helps you.” Think of a customer service agent. The help they give you is, 99 percent of the time, synchronous. They help you in real time, in person, or on the phone, doing their best to minimize your wait. In my mind, this is much more akin to an assistant. But even that’s troubling since “assistant” has also been used to mean “that person who helps me at my job” both synchronously—as in “please take dictation”—and agentively—as in “hold all my calls until further notice.”

    These blurry usages are made even blurrier because human agents and assistants can act in both agentive and assistive ways. But since I have to pick, given the base meanings of the words, I think an assistant should assist you with a task, and an agent takes agency and does things for you. So “agent” and “agentive” are the right terms for what I’m talking about.

    Complicating that rightness is that a recent trend in interaction design is the use of conversational user interfaces, or chatbots. These are distinguished for having users work in a command line interface inside a chat framework, interacting with software that is pretty good at understanding and responding to natural language. Canonical examples feature users purchasing airline tickets (yes, like a travel agent) or movie tickets.

    Because these mimic the conversations one might have with a customer service agent, they have been called conversational agents. I think they would be better described as conversational assistants, but nobody asked me, and now it’s too late. That ship has sailed. So, when I speak of agents, I am not talking about conversational agents. Agentive technology might engage its user through a conversational UI, but they are not the same thing.

    It’s Not Robots

    No. But holy processor do we love them. From Metropolis’ Maria to BB8 and even GLaDoS, we just can’t stop talking and thinking about them in our narratives.

    A main reason I think this is the case is because they’re easy to think about. We have lots of mental equipment for dealing with humans, and robots can be thought of as a metal-and-plastic human. So between the abstraction that is an agent, and the concrete thing that is a robot, it’s easy to conflate the two. But we shouldn’t.

    Another reason is that robots promise—as do agents—“ethics-free” slave labor (please note the irony marks, and see Chapter 12 “Utopia, Dystopia, and Cat Videos” for plenty of ethical questions). In this line of thinking, agents work for us, like slaves, but we don’t have to concern ourselves about their subservience or even subjugation the same way we must consider a human, because the agents and robots are programmed to be of service. There is no suffering sentience there, no longing to be free. For example, if you told your Nest Thermostat to pursue its dreams, it should rightly reply that its dream is to keep you comfortable year round. Programming it for anything else might frustrate the user, and if it is a general artificial intelligence, be cruel to the agent.

    Of course, robots will have software running them, which if they are to be useful, will be at times agentive. But while our expectations are that the robot’s agent stays in place, coupled as we are to a body, that’s not necessarily the case with an agent. For example, my health agent may reside on my phone for the most part, but tap into my bathroom scale when I step on it, parley with the menu when I’m at a restaurant, pop onto the crosstrainer at the gym, and jump to the doctor’s augmented reality system when I’m in her office. So while a robot may house agentive technology, and an agent may sometimes occupy a given robot, these two elements are not tightly coupled.

    It’s Not Service by Software

    I actually think this is a very useful way to think about agentive tech: service delivered by smart software. If you have studied service design, then you have a good grounding in the user-centered issues around agentive design. Users often grant agency to services to act on their behalf. For example, I grant the mail service agency to deliver letters on my behalf and agree to receive letters from others. I grant my representative in government agency to legislate on my behalf. I grant the human stock portfolio manager agency to do right by my retirement. I grant the anesthesiologist agency to keep me knocked out while keeping me alive, even though I may never meet her.

    But where a service delivers its value through humans working directly with the user or delivering the value “backstage,” out of sight, an agent’s backstage is its programming and the coordination with other agents. In practice, sophisticated agents may entail human processes, but on balance, if it’s mostly software, it’s an agent rather than a service. And where a service designer can presume the basic common senses and capabilities of any human in its design, those things need to be handled much differently when we’re counting on software to deliver the same thing.

    It’s Not Automation

    If you are a distinguished, long-time student of human-computer interaction, you will note similar themes from the study of automation and what I’m describing. But where automation has as its goal the removal of the human from the system, agentive technology is explicitly in service to a human. An agent might have some automated components, but the intentions of the two fields of study are distinct.

    Hey Wait—Isn’t Every Technology an Agent?

    Hello, philosopher. You’ve been waiting to ask this question, haven’t you? A light switch, you might argue, acts as an agent, monitoring a data stream that is the position of the knife switch. And when that switch changes, it turns the light on or off, accordingly.

    Similarly, a key on a keyboard watches its momentary switch and when it is depressed, helpfully sends a signal to a small processor on the keyboard to translate the press to an ASCII code that gets delivered to the software that accumulates these codes to do something with them. And it does it all on your behalf. So are keys agents? Are all state-based machines? Is it turtles all the way down?

    Yes, if you want to be philosophical about it, that argument could be made. But I’m not sure how useful it is. A useful definition of agentive technology is less of a discrete and testable aspect of a given technology, and more of a productive way for product managers, designers, users, and citizens to think about this technology. For example, I can design a light switch when I think of it as a product, subject to industrial design decisions. But I can design a better light switch when I think of it as a problem that can be solved either manually with a switch or agentively with a motion detector or a camera with sophisticated image processing behind it. And that’s where the real power of the concept comes from. Because as we continue to evolve this skin of technology that increasingly covers both our biology and the world, we don’t want it to add to people’s burdens. We want to alleviate them and empower people to get done what needs to be done, even if we don’t want to do it. And for that, we need agents.

  17. User Research When You Can’t Talk to Your Users

    It’s not breaking news to say that the core of UX, in a vacuum, is talking to your users to gather insights and then applying that information to your designs. But it’s equally true that UX does not happen in a vacuum. So what happens when you don’t have the budget or the timeline to run user tests, card sorts, or stakeholder interviews? What should you do when your company doesn’t want you bothering the paying customers who use their software? In short, how do you do UX research when you can’t get direct access to your users?

    While the best methods for gathering user insights entail first-hand research, there are other ways to quickly glean qualitative data about your users’ wants and needs—beyond the usual lightweight guerrilla user testing options.

    For a start, companies that are new or have a smaller digital footprint can benefit from things like forums or even competitor reviews to get a better sense of the users in their industry vertical. And for more established companies, customer service logs and app reviews can be invaluable for learning what users think about specific products. Let’s check out a few techniques I like to recommend.

    App reviews

    When products have a mobile app component, I start looking at reviews posted on the App Store or Google Play. The key, in terms of user research, is to focus on the substance of what the user is saying, as opposed to the rating (i.e., one star to five stars). For instance:

    • Is the user simply disgruntled or are they asking for a tangible feature to be added to the product?
    • Is the user truly thrilled with some aspect of her experience using the app or is she just a brand loyalist?

    While reviews do tend to be rather partisan, keep in mind that users are most likely to leave feedback when motivated by an emotional reaction to the product. Emotionally-driven reviews—whether positive or negative—tend to be outliers on the bell curve, so the next step is taking all those reviews and distilling them into tangible insights. Let’s face it, when you want to improve the featureset and functionality, a general reaction to the entirety of an app doesn’t tend to be particularly actionable. Here are a few questions I always start with:

    • Are there missing features users want to see?
    • Do users seem confused by aspects of the UI?
    • Are they complaining about bugs or performance issues that are popping up and making the app unusable?
    • Do people really love a hidden feature that was put in as an afterthought with minimal prominence—something we should consider placing more front and center?
    • Does it seem like people understand how to use the app or do they need a tutorial on first open?

    Also, it’s important to remember that feedback on an iOS app may or may not be applicable to an Android app (or mobile web experience), and vice versa.

    Customer service logs

    Customer service and help center personnel are on the front lines with your users, helping them with specific struggles they encounter with the usability of your products. In other words, they’re constantly learning how users see the product and go about using it.

    Since user information can be sensitive, the first thing to try is asking whether service calls and contacts are being logged. If so, ask whether it’s possible to get access to the records for user research purposes. If there are no logs, or if you are unable to get access to them, see if a few brief stakeholder interviews with customer service team members is an option. Use the interviews to learn which types of problems and complaints they routinely field.

    Given the nature of customer service and the purpose of help centers, it’s likely that much of the feedback will be negative. Even so, these logs can still provide excellent data. In particular, the feedback can help illuminate policies and business practices that are creating a negative user experience, not to mention identify the points at which they occur during the user journey. And remember, your user experience is about more than just the design of your app and website.

    Contact form emails

    “Contact Us” forms and messages can be rich with direct input from your users. Obviously, the first things to look for are complaints about an aspect of the site itself. For example, are users struggling to find a feature or getting confused by a certain page on the site? Beyond that, the forms themselves can relate to aspects of the user journey that are problematic.

    If a brand or company does not have this feature for gathering site visitors’ opinions, it’s relatively easy to add a contact form, in terms of development effort. However, it’s important to note that if you have a contact form on your site, someone should be actively monitoring it and responding to users.

    Industry forums

    While the likes of Reddit and 4Chan have given the world of online forums some questionable connotations, the truth is that many online forums are also excellent sources of information about how digital products are operating in the wild, and how specific products and trends as a whole are influencing users. The research insights might be less obvious, but they’re easy to spot if you’re looking for them.

    A look at the Apple TV Apps section of Mac Rumors reveals that many users of the 4th generation Apple TV have a problem with the YouTube app not fading out video titles when a video is playing. Similarly, a brief review of the Delta Airlines thread on FlyerTalk shows that users have questions about everything from Economy Plus seating to the Delta and American Express credit card. Reviewing this information could help Delta retool the content strategy and information architecture of their mobile app to address questions more clearly.

    Many forums are industry specific, and therefore not applicable to every situation. There are just as many out there, however, that specialize in spanning numerous industries. Ars Technica covers virtually any sort of traditional tech product. For video games, IGN offers helpful feedback from players about everything from game length and storyline to controls. For nutrition and exercise, Bodybuilding.com’s BodySpace forum is a top online destination for users to discuss nutrition and exercise. Of course, not every forum offers in-depth discussions regarding specific apps, websites, or even companies, but each provides great sources of information about what motivates and interests consumers in that industry vertical.

    Multi-topic forums can be searched for company- or product-specific threads. Reddit (despite its aforementioned reputation) features thriving, engaged communities of actual users talking about topics of value. Quora offers an almost scholarly approach to the format, with many users possessing strong subject matter credentials to validate their expertise.

    Reviews of competitors

    Perhaps your brand or product is new in the market and there’s not yet enough data from any of these sources to be actionable. So what then? Find out what your potential users have to say about the competition. If you want to launch a car service, see what users say about Lyft and Uber on the App Store. Want to improve Jet? Read reviews of Amazon Prime. Do you work for InstaCart? Find out what users have to say about Fresh Direct.

    In summary

    There’s still no substitute for actually talking to your user base, whether that’s initial research in the form of stakeholder interviews or testing design iterations, but even when that’s not an option, there’s no excuse for not gathering feedback from your users.

    Good UX design should always be based on user insights, not assumptions about best practices or what might translate from other products and industries. So go find out what your users are saying. From Yelp! to Glassdoor to App Store Reviews, consumers are readily sharing their opinions about businesses of every size, in every industry.

  18. Focus on What You Do Best and Outsource the Rest

    With consumer expectations growing year after year, high quality web design and development services are in top demand. If you want to be the one to deliver those high-end results, then you’ll need to focus on playing to your strengths and be comfortable entrusting everything else to others.

    Like many of us, you’re probably so occupied by managing the day-to-day and maintaining the base of clients you currently have that you don’t have the time or resources to build your web design or development business out to the next level.

    Why “no pain, no gain” has no place in web design

    One of the greatest lessons I’ve learned from working as a project and content manager is that there are times when it just doesn’t make sense to take on a task or project that’s not a good fit.

    For instance:

    I’ve seen developers struggle with marketing their business when they barely have enough time to complete their own workload.

    I’ve seen web designers hire on supplemental designers (such as video designers and animators), only to lose those new hires just as quickly as they got them because they couldn’t manage the payroll aspect properly.

    I’ve even seen administrative assistants given the responsibility of loading content into a CMS and, on top of that, being asked to optimize it for search despite a lack of training.

    While I’ve seen this problem crop up with management of medium and large-sized businesses, I think it’s much more prevalent with small business owners and independent entrepreneurs. When you think about how much of your life (personally and professionally) is wrapped up in your business, it seems to make sense to think that by consolidating tasks, cutting corners, or just taking it all on yourself, you’ll save money and time.

    Here’s the problem with that sort of thinking: it’s a dangerous and highly inefficient way to conduct business when you work in web design. No matter the size of our business, we rely on proven processes and techniques to ensure that what we create is always of the highest quality. Let’s face it, we are specialists, and diluting our offering by trying to do everything isn’t fair to our clients or ourselves.

    My suggestion? Let more qualified people or tools tackle the “stuff” that forces you to slow down, lose productivity, and create something less than what your clients deserve. Sure, it’s scary to think about how much it will cost to outsource your accounting, your SEO, or anything else that isn’t in your wheelhouse. But think about how much momentum and overall quality of work you lose whenever you let that fear take over. I say: focus on what you do best, outsource the rest, and be happily surprised when you see how much your business soars as a result.

    Follow your strengths

    In a recent interview about the cost of doing business, Jeremy Goldman of the Firebrand Group argued that in order for business owners (or any entrepreneurs really) to succeed, they must be willing to accept when they’re not great at something.

    Once you accept that you’re a bad fit for some tasks, you leave yourself more time to pursue the tasks you’re good at (or want to get better at). Outsourcing may result in additional costs upfront, but if you’re handing those tasks over to someone or something that can handle them more efficiently, I’d argue that you’ll save money in the long run. First, because the outsourced party will spend less time completing a task than it would have taken you. And second, because the investment frees you up to succeed at what you do, which, in turn, is where the real revenue-generating opportunities are.

    The key to embracing this is through understanding your operations thoroughly, so you know what can be streamlined or outsourced. Start with an assessment of where your business currently is and where you want it to go. This will tell you exactly how you need to scale, and direct you toward the right forms of outsourcing and assistance.

    Before you do anything else, assess your current business model.

    • Outline your entire process, starting with customer acquisition and ending with the close of each project. Identify areas that can be consolidated, broken up, or removed altogether.
    • Conduct a review of last year’s work. Identify trends that resulted in positive outcomes. For instance, did a certain workflow always lead to a good profit margin? Or perhaps you found that certain types of clients or projects always led to positive results for you (profit wise) and for your client (conversion wise)? If you don’t have any data, you can seek out previous customers’ opinions to identify what worked and what did not.
    • Review your current pricing structure (if you have one). Determine if there are any particular areas of your operation that cost more money, or bring in less profit, than they should. Establish your ideal pipeline today. Figure out how many projects you can simultaneously work on, as well as how long each turnaround should be.

    Then, answer the following questions regarding where you expect your business to be in five years:

    • Will you offer the same services? More? Fewer? Different?
    • Will you specialize in services for a specific industry?
    • What will your role in the company be?
    • How large do you expect your client base to be?
    • How many employees would you like to have?
    • How much will your services be worth?

    Finally, make a list of what is needed to take you from where you are today to where you want to be in five years. If you’re unsure of what exactly you need, or if you want to make the process easier on yourself, keep reading.

    Tools that allow you to focus on what you do best

    Want to be more efficient? First things first then: take a closer look at the tasks that fall outside your wheelhouse. These are the ones that distract from your primary goal and that consume too much of your valuable time. By saying “no” to those tasks and finding ways to offload them to someone else, you’ll find that the costs associated with them end up being negligible after a while.

    The following recommendations are some of the more affordable, practical, and commonly outsourced and automated areas of web design I’ve been privy to. I’ve also included a number of tools you can use for each that will grow as your business does.


    There’s no doubt that technology plays a big part in the scaling of a business. That being said, most automation still requires human supervision and maintenance. While you may not be ready to hire full-time staff at the moment (or even in the near future), you’ll want to start considering what team members you’ll need in order to reach your goals.

    One of the best ways to scale your team is to employ freelance or contract workers. This enables you to:

    • Pay only for the work you need.
    • Offload some of your work for an affordable rate.
    • Test out new team members without the commitment of hiring full-time.
    • Expand your service offerings to clients on an as-needed basis.

    Recommended tools:

    • Freelance job sites like Freelancer.com, Upwork, Toptal, and Guru are always a good place to start. They cost a bit of money to use (in addition to freelancer costs), but I’m a fan of them since they offer a relatively low-risk way to test out new talent without the serious commitment of hiring.
    • You’re most likely already familiar with Envato for its theme and plugin Market as well as for its Tuts+ tutorials, but did you know they also have a freelance hiring Studio?
    • Twitter and LinkedIn have also proven to be good platforms for finding freelance talent (especially if you have a solid follower base).


    This isn’t one of the more popular avenues I’ve seen web design companies pursue in terms of outsourcing, but I still think it’s one worth mentioning. If you think about it, there are a number of items competing for your attention on a regular basis:

    • Your daily workload.
    • Clients and prospects reaching out with questions and comments. Everything related to your employees or contractors (HR, productivity, process improvement, etc.).
    • Finance management.
    • Marketing your business and services.
    • And more

    So, when do you find time to turn your attention away from the “right here, right now” stuff and look toward finding new clients so you can expand your business and make more money? If your answer is “the weekend,” then something’s wrong. Every time you add more hours to your work week, you lose money and overall efficiency.

    This is where recruiters come in handy. You find someone that’s reliable, that you trust, and then you outsource the task of finding more work to them. These experts are incredibly valuable business partners who know how to sniff out those right-fit clients without breaking a sweat, while leaving you to focus on your real work.

    Recommended tools:

    • I’d suggest you start by signing with a creative staffing agency like Vitamin T. You’ll have the flexibility of searching for and applying to work with clients, or you can work directly with one of their representatives.
    • SuperBooked aren’t recruiters, per se, but they instead help you leverage the power of your personal network to help you find clients more easily.
    • Want something more comprehensive where you have access to training, career coaching, and someone who takes care of your paperwork? Hired would be a great solution in that case!

    CRM software

    Word of mouth is a great way to get more business—especially if you have a niche or specialty. But referrals will only get you so far. You’ll eventually need to actively market your brand to prospective customers. With most of your time dedicated to the actual work that makes you money, how can you make time for cultivating relationships with potential clients?

    At some point, you’ll be able to hire a marketing team to handle all these matters. In the meantime, you’ll need customer relationship management (CRM) software to tide you over. These tools typically offer a variety of marketing and sales functions, including:

    • Lead collection and management.
    • Sales opportunity tracking.
    • Revenue pipeline predictions and planning.
    • Contact reminders.
    • Email templates.

    Eventually, you’ll need to become more active on social media and invest in paid marketing opportunities. For now, though, get yourself a tool that will help you build relationships with prospects and customers.

    Recommended tools:

    • Insightly is a fairly easy-to-use CRM platform, as is ZohoCRM (see note about that below). Both of these also integrate with the Ninja Forms plugin, which makes syncing up WordPress website forms with your CRM easier.
    • If you want a simpler solution that focuses more on collecting leads from newsletters or blog signups, I’d suggest either Constant Contact or MailChimp.


    As a web designer or developer, you know that working with a reliable content management system can do wonders for your workflow. Then you get into a platform like WordPress, Squarespace, Drupal, or Perch Runway, and you recognize it’s the extensibility of these platforms that truly make them such valuable tools.

    Using a CMS out of the box is a good start, but it’s not enough. Your business toolbox should include the most commonly used CMS tools, such as design templates as well as extensions. They were created to help users—novice, intermediate, and advanced—more easily and quickly build websites.

    If you’re reading this, then you’re aware of this already. What you might not be doing, however, is taking advantage of the plethora of memberships available. By signing up for one of these, you get instant access to a wide range of high-performance tools that help you build better websites, and in less time.

    Recommended tools:

    • Considering that 27.3 percent of the world’s websites run on WordPress, you can start there. Some of the more popular WordPress memberships are offered by Elegant Themes, StudioPress, and WooThemes.
    • WPMU DEV is also a good one to consider if you need high-performance plugins.
    • I’d also suggest you look into CodeCanyon, if you haven’t already. While they’re not necessarily a membership site, having so many high-quality plugins in one place is an attractive and convenient option.

    Managed hosting services

    As a web developer, you may not be too excited when clients ask if you offer ongoing management or maintenance for their website. Yet, you might feel a little guilty in not offering these services, since you know there’s a good likelihood your clients won’t know about adding security, optimizing speed, making backups, or keeping the core platform and tools up to date.

    If you’re not comfortable with ongoing management of your client’s website, you can still offer it as an upgrade; only, you’ll hire an expert to manage it for you. Managed hosting providers do just that. This is a great way to upsell your clients and make a decent markup without increasing your workload.

    If this is something you’d rather not get involved with just now, you can always work with a low-maintenance CMS like Squarespace that doesn’t require much in the way of ongoing management. Remember: this is your business. It’s up to you how you want to run it and what sort of services you want to offer.

    Whatever you choose, be sure you’re working with the best provider for your needs (especially if you generally work in one CMS). They should offer a variety of packages based on business type and size, too, as this will enable you to scale your services as your needs grow.

    Recommended tools:

    • For WordPress, I’d suggest you take a look at Pagely or WPEngine.
    • SiteGround offers both WordPress and Joomla managed hosting.
    • AHosting and RoseHosting both have some of the more robust CMS managed hosting offerings I’ve seen, so give them a try if you want to provide more coverage options.

    Project management software

    Although it may not seem like something you need right now, a workflow and collaboration platform should be part of your business from the very start. As a business owner, you need to have a centralized hub where you can:

    • Store documentation.
    • Generate and save templates to streamline communication with clients, ensure consistency in project output and deliverables, and provide clear guidance to team members.
    • Manage project workflows through a series of checklists.
    • Gather files.
    • Communicate with clients.
    • Collaborate with team members.
    • Track time spent on projects.

    If your business is design-focused and QA-heavy, it’s ideal that you find a project management tool that includes wireframing and/or prototyping functionality.

    Recommended tools:

    • Basecamp is one of the more popular project management tools I’ve used, but its cost makes it a better choice for agencies.
    • Asana is my personal favorite—something I use in my everyday work as well as personal scheduling. I’d suggest using this one for creating checklists, communicating with team members, and managing timelines.
    • InVision is a good pick, especially because it includes prototyping, wireframing, and collaboration, which is essential to web design work.

    Accounting software

    How much time do you currently spend drawing up contracts, writing invoices, tracking payments, and managing your taxes? As your business grows, the amount of work you do to manage these administrative areas will increase, too. Rather than spend your time focusing on the numbers, use accounting software to take most of the guesswork out of it (especially until you have a need for a full-time accountant).

    In addition, you can employ certain techniques that will help you get the tasks out of your head and into a systematized process and actionable checklist. I’d also suggest you take this assessment to determine whether you should even be handling any accounting tasks for your business in the first place. This may just be one of those responsibilities that make more sense in the hands of someone else.

    Recommended tools:

    • I’m a big fan of QuickBooks, not only because of how easy it is to use, but because it integrates with so many different programs and decreases the overall amount of work I need to do.
    • Zoho is another great tool to check out. I like this one because you can manage your finances and invoices, and also use it as a customer relationship management tool.
    • For anyone just starting out, I’d suggest giving Wave a try. It’s free to use and is a good platform to help you ease into finance management.


    At the end of the day, you need to focus on what you do best. Time spent doing anything else is an unnecessary drain on you and your business.

    If you’re looking to grow your business, it’s time to consider how you can most efficiently scale it. Review what you currently have. Then look to these tools to bring more order, control, and consistency to your operations.

  19. Widen Out: Using Your Blog to Attract New Clients

    Attracting future clients on autopilot—that’s the whole point of your website, right? Most freelancers accept the story that great work attracts leads, but I’m going to be straight with you: clients have no clue you exist. What usually tips the balance isn’t your portfolio—they see plenty of those.

    Not many people talk about failures they had promoting their products and services. We struggle and we hide it. It’s one of the reasons I hate to read marketing “success stories” and “How to drive traffic and make money!” posts—they seem hollow and vaguely manipulative. They also invariably circle around an answer we already know: The key to attracting non-referral clients is making it easy for them to discover you.

    Simple as that is, we fail for two reasons:

    • Most freelancer websites are only concerned with showing portfolio work.
    • We haven’t figured out who we want as clients, what makes them tick, or how they solve problems.

    We’re focused on showing, not serving.

    Serving hits the ground running—it answers a question, solves a problem, satisfies a curiosity. There’s a difference between saying you will and proving it with a real takeaway during the first impression. Portfolio-focused sites also don’t give Google much content to index and rank, lessening your chances of ever getting high in organic search results, much less on their radar.

    Designers are “supposed” to do certain things to find clients. Well, I did all that, for years. And I had a pretty depressing success rate, considering how much time I put into it. Then I tried one thing that single-handedly turned around my freelance career. I started blogging with clients in mind.

    Do it your way

    Let me tell you about Brian Dean.

    Brian Dean of Backlinko gets 130,000 monthly uniques. Want know how many articles he has on his blog—in total?

    30. That’s right, 30.

    Readers aren’t coming because he publishes frequently—they’re coming because he writes about what they want to know and because every piece he’s got is the best on that given subject, hands down! He keeps visitors coming back to the same posts because he’s constantly improving the material little by little to ensure it’s always the best that’s out there.

    As people come across it—web professionals, curious readers, and potential clients—it’s building up his reputation and making it easier for people to find him via search and re-shared content links.

    You don’t have to write regularly. Or much. And you don’t need an industry-rocking idea. With your expertise, you have what it takes to say something that other people consider valuable.

    The key to success is making a target, then sticking it out for a few rounds of research + content creation + promotion to start. The more posts/articles you create, the more properties you have on the Monopoly board called Google. Having a few widely shared articles also kicks off a virtuous loop where all your subsequent articles get a jump start from your existing traffic. This approach is repeatable and scaleable.

    (One quick heads-up: you can also expect your content to attract the “wrong type” of visitors, such as recruiters and people looking to hire someone for low-end, piecemeal work. It’s possible to turn these inquiries into opportunities by politely refusing their offer and asking if they know anyone who is seeking the type of work you do provide.)

    Pre-planning your content

    As you know, Google determines how high your page ranks for certain search terms based on factors like:

    1. Whether your page content is relevant to the search term
    2. How many other quality, relevant sites link to your page
    3. How well-made readers think your content is (i.e. how long do people spend reading your content).

    Translating that, your goals are to:

    • Create content that is relevant to search terms visitors use
    • Create high quality content that invites re-links and social shares
    • Ensure that time-on-site for the specific piece of content is high.

    It may feel a bit unnatural to create content around ranking well on Google, but you’re actually just creating a really valuable article that answers all possible questions a reader is most likely to have about that topic.

    Know what matters to clients

    Instead of randomly choosing a topic, it helps to be a bit strategic. After all, it’s a way to get discovered by the right people.

    First, know—and learn how to write for—your intended audience. Almost any topic about your field would interest fellow professionals. But let’s recall, who is it you want to attract, first and foremost? Clients. So how do you find out what they’re searching for?

    When I started doing this, I began by listing questions a new client typically asks, such as:

    • How much do your services cost?
    • How does your [service] process work?

    To see the types of questions business owners and entrepreneurs ask most often, take a look at community sites where they hang out (Fig. 1). Good ones include:

    Google search results showing web design topics
    Fig. 1: People frequently questions about web services, such as these found on the community site Quora.

    Based on the questions you find, you could brainstorm three topic ideas that relate to each one, or even split larger topics into separate articles. For example, instead of writing one giant piece on how much web design services cost, write about one service in each post, such as:

    • How much does a landing page cost?
    • How much does custom website cost?

    They should be written in the style of a comprehensive educational guide that teaches the visitor everything they need to know about the topic.


    • How much does logo design cost?

    This article could cover:

    • The reason rates vary so much among designers
    • The different types of designers they can hire (freelancer, agency, etc.)
    • A description of the creative process for designing a logo.

    Write a better article

    Now that you’ve settled on a topic, it’s time to create a comprehensive leave-no-stone-unturned piece of content about it.

    What’s “comprehensive”? It’s helpful to set a benchmark for yourself by researching other popular articles that have already been written about it. Use them as inspiration, then go and create an even better version. This both demonstrates your command of the topic and attracts links from relevant, high authority sites (which signals to Google that your site contains high quality content, triggering it to bump your page higher in the search results for those keywords).

    A popular tool for doing this research is Ahrefs.

    After you create an account, enter a topic you’re considering, then select “Traffic” in the Sorted by dropdown. (Fig. 2)

    The filter screen on Ahrefs helps narrow down search results
    Fig. 2: The filter screen on Ahrefs helps when narrowing down search results.

    Here are some of the highest trafficked articles on “web development cost.” (Fig. 3)

    Ahrefs search results after filters are set
    Fig. 3: Ahrefs search results after filters are set.

    Analyze each article and write down every single point that’s covered. Your goal is to be just as good when it’s your time to address each one. You’ll then brainstorm at least five original or interesting angles they didn’t mention or tackle extensively. This “value add” is your selling point when the time comes to start promoting the piece.

    Another way to dig deep is to learn more about the authors. For instance, how does their expertise differ from yours? This can help you catch things they didn’t cover. You can also pull up every article a specific author has written on a subject, such as this topic search for journalists and bloggers writing about “web development cost.” (Fig. 4)

    Fig. 4: Doing research on what other writers have published can help to determine subjects to pursue.

    Other effective ways to juice up your content

    Use compelling (and/or controversial) examples

    Buttress each major point in your article with compelling (and if possible, controversial) case studies and examples.

    For example, here’s an excellent analysis of the controversial logo design for the London 2012 Olympics (Fig. 5). It explains why (despite the negative public reaction) the versatility and instant recognizability of the logo actually make it an example of great identity work.

    Analysis of 2012 London Olympics logo
    Fig. 5: Analysis of the London 2012 Olympics logo design.

    Use visual assets with your article

    Visual assets make your article easier to read by breaking up chunks of text. For images, choose ones that instantly convey the emotion or message of a major point you make (Fig. 6). For infographics, choose ones that visually illustrate and compare data or statistics you mention in the article. A good visual asset also attracts social shares.

    Fig. 6: Selecting images that instantly convey the emotion behind the message supports the point you want to make.

    Interview someone interesting (and influential)

    Seek out people who can contribute an interesting insight or experience related to your topic. Not only does this add perspective to your article, you can ask this person to share the article with their audience (which may give you a nice traffic boost).

    Capture every question

    Before you start writing, make a list of every single possible question someone could have about this topic. Based on your research of existing articles, also include details and angles they don’t.

    For example, if you’re writing an article about logo cost, details and angles that many other articles miss are:

    • Reasons why corporate logo designs cost so much
    • The psychology behind how logos affect brand perception
    • Conversion stats before and after logo redesigns
    • Why negative public reactions don’t necessarily mean the logo design is bad.

    Add a call to action

    Avoid losing potential clients who would have contacted you later—if they hadn’t forgotten. Add something encouraging them to act right away by making it a simple click, such as a call to action (CTA) banner in every article. (Fig. 7)

    A call to action can prompt a user to take further action or engage with additional content.
    Fig. 7: Use prompts that encourage users to take action or engage with additional content.

    Promoting your article the right way

    Promoting your content may feel uncomfortable, but it’s important to reframe that in your mind. Instead of “Marketing your content,” you’re “Helping people by educating and inspiring them with your well-researched, well-written information.”

    Clients who don’t know about your site won’t magically enter your URL into their address bar—they have to discover you through some other source (other websites, search engines, social media). That’s why promotion and outreach are so important, and why it pays off to ask other sites to link to your content.

    To kick off the first wave of traffic, it helps to win a few links and social shares. From there, the new people who discover your post may also link to or share it (which in turn boosts your article’s ranking on Google).

    Let’s look at a few effective ways you can promote your content.

    Offer your actual article as a service

    This is an old timer technique that still works amazingly well—one my very good friend and coach Brian Harris wrote about on his blog. I like to alter the technique just slightly, but here’s what to do:

    Take the URL of one of the articles you found in the previous section (when you were choosing a topic to write about). Try to pick the one with the most shares.

    Go to Buzzsumo and enter the URL to the article (use the 14-day free trial they offer to do this step).

    In my case, I chose this SEO techniques article because I’m looking for clients who might be interested in my SEO consulting. (Fig. 8)

    Research a URL on Buzzsumo to help generate article ideas.
    Fig. 8: Research a URL on Buzzsumo to help generate article ideas.

    Next, click the “View Shares” button to see a list of everyone who shared the post on Twitter. You can then click on the “Followers” filter at the top left to sort by users who have a sizable audience (i.e. enough money to pay you for a service). (Fig. 9)

    Buzzsumo assists in finding potential marketing opportunities for your articles
    Fig. 9: Buzzsumo brings visibility to social sharing.

    Now you have a list of people who have already shown an interest in the topic, you could reach out to them individually and see if they’d be interested in sharing yours, as well. The following example highlights a number of points.

    Subject: Re: Brian’s article you shared
    Body Text:

    Hey AJ,

    I’ve been following you since last January when I saw you share Brian Dean’s article on SEO techniques. Great article, I truly enjoyed it!

    I couldn’t help but notice that it did not include how to convert the traffic you get from these techniques into actual leads. I’ve done SEO and lead nurturing work for 9+ years .

    I just recently published a more comprehensive post on how to do everything Brian talks about as well as lead nurture and convert the traffic into actual leads, so I wanted to run this by you since you’re interested in the topic.

    I took a look at Wordtastic <insert their company name here>—love the app. I checked and it looks like you get a decent amount of traffic.

    I came up with three ways you can improve your calls to action to get more conversions every single day (based on Brian’s advice compiled with my article above)

    Here is the link to the recommendations, a potential campaign, and some projected results once you implement this: [link to Google doc you put together that will blow their socks off]

    Would love to help you guys implement some of these strategies.


    (I’ve collected examples that seem to work really well for people; you can check out those posts here: cold email templates and business email templates.)

    Join some groups where your potential clients hang out

    I listed these community groups earlier, but it’s worth mentioning them twice:

    Don’t just join—leave meaningful comments. If you do that, most groups will start to see you as a valued contributor and won’t bat an eye if you to post something that mentions your own content once in a while, like this example from a private entrepreneur group (Fig. 10)

    An example of a member sharing their own content on a private entrepreneur group.
    Fig. 10: Be courteous and tactful when contributing to groups.

    When you do share, be sure to mention a few points you’ve covered that would be highly relevant and valuable to that community.

    For example, if you write an article about web design, a business community may be most interested in how to evaluate web designers in order to find one that’s reliable. Conversely, a marketing community may be most interested in how to design funnels that convert more visitors into subscribers and customers.

    You can also ask a question related to your article topic to kickstart a discussion, then offer to answer any questions a group member may have.

    Share your links with family and friends

    The easiest, non-intrusive way to do this is by posting it on your Facebook feed. Add a description highlighting a few points a general audience would find interesting and worth the effort of clicks and likes.

    Add interesting visuals to illustrate your points

    Add relevant illustrations and pictures throughout your article to break up the text and keep your visitors engaged. Bonus points: use relevant visuals from your own portfolio so it does double duty prettifying your article and showcasing your skills.

    Improve your search ranking with some SEO basics

    Focus on one search keyword or phrase you want your article to rank for, then use different variations of it throughout your article, especially in your article headline and section headings.

    Make sure your pages and articles load fast; you might consider caching your pages with something like CloudFlare (they offer a free plan) to speed up load time. (CloudFlare shows cached versions of your files and images so visitors don’t have to wait for them to load real-time from your servers.)

    Compile a list of relevant sites to ask for links

    Remember how you looked up the most popular articles on Topic X? If you find out which sites link to those articles, why not ask them to link to your (much improved) version, too?!

    Use a backlink checker tool such as Open Site Explorer or Ahrefs. (Fig. 11)

    Use a backlink checker tool to find out who links to topic related sites.
    Fig. 11: Use a backlink checker tool to find out who links to articles related to your topic.

    Go to each site and find the names of either the site owner or, if it’s a company, the person in charge of marketing.

    To find their email address, enter their site domain into AnyMailFinder or Email Hunter. These sites will tell you the most likely email format (for example: firstname@company.com). Based on the most common email format the site or company uses, you can “smart guess” the likely email of the person you wish to contact.

    You can send them a personalized version of this template1 to ask if they may be interested in linking to your article:

    Hey [Name],

    I was searching for some articles about [Your topic] today and I came across yours: [URL]

    I noticed that you link to [Article Title] - I just published something similar that [2 major points why it’s better]: [url of your article]

    May be worth a mention on your page.

    Either way, keep up the awesome work!

    Remember that infographic I mentioned earlier, the one you could create to accompany your article? You can also ask some of the other sites you found in the Backlinks tab to include it in one of their existing or future articles and credit you (earning you a link this way).

    Here’s the template link Luke from Pest Pro App used:

    Hey [First Name],

    I really liked your article on [relevant topic to your article]. Great stuff!

    You actually inspired me to take this a step farther and create something even deeper.

    I thought I’d reach out to you because I just published an infographic on [topic] and I thought it might interest you. It covers [list of major points, stats or facts.] It’s all based on research, and I have the sources to back it up.

    Love to see if you may find it a good addition to your article.

    Promote it in relevant Facebook groups

    If you develop websites (for example), find Facebook groups that discuss web development, have 500+ members, and show signs of recent activity. For a few weeks, post meaningful comments every once in a while and start interesting discussions to provide value to the community. If the group guidelines allow it—and if the timing is right—share your own article now and then, but make sure you ask a question in your post to spark a discussion. This will help the post stay on top of the group feed and members’ newsfeeds to bring you more traffic.

    Content creates visibility outside your network

    It’s becoming tougher and tougher to stand out these days—there’s a lot of noise online. For a lot of freelancers and part time contractors, DIY service platforms and online hiring marketplaces have become the status quo for finding gigs. The quality of clients drawn to these hubs is very mixed, unfortunately, and most come because they want to pay as little as possible for the work. It is also very challenging for freelancers who don’t already have a presence there to start gaining leads right away.

    Freelancers relying on word of mouth referrals also run into pitfalls. Nurturing those opportunities can be just as time intensive, not to mention leave you with limited control over when they actually convert into meaningful business.

    These conditions should prompt every freelancer to try something outside the box, to find uncrowded spaces for meeting and gaining clients. Strategically creating content can consistently attract the right kind of client. When a prospective client reads your article, she’ll learn something immediately useful from you and see you as a knowledgeable pro, which creates a solid start for a client-freelancer relationship.

    It’s a way for you to have something in common, something to prompt a conversation. Imagine yourself at a conference talking to a person you just met—would you rather discuss an article you wrote or dive straight into discussing your hourly rate? Of course you’ll want to show off your know-how before you talk about prices!

    Writing content to attract customers is a perfect strategy for this—it engages people and generates higher visibility for your work, both within and outside your network.

    Ok, I’ll hand this off to you now; it’s your turn to do the research and write one article in the next three weeks. That’s my challenge to you. One article in the next three weeks on your site. Are you up for the challenge?

    Post in the comments which topic you would like to write and I’ll comment back with my feedback and thoughts.

    Ready? Get set. Go.


  20. Practical CSS Grid: Adding Grid to an Existing Design

    Understanding and using CSS Grid is easier than you might expect. The day Grid support shipped in Firefox 52, I decided on the spur of the moment to convert the basic layout of my personal site to use Grid. And it was a fairly simple process—five minutes to write the grid styles, then 15-20 spent troubleshooting.

    Grid allows us to literally define column and row grid lines, and then attach elements to those lines in any order we choose. That may sound like tables, but Grid is so much more than tables ever dreamed.  It means more responsive layouts, far more accessible documents, and far cleaner markup than even floats and positioning ever afforded us.

    It’s been decades since CSS first emerged, but it’s never contained a system anything like this. And Grid is already supported in both Chrome and Firefox, with Safari coming soon (its Technology Preview releases support Grid as of this writing). A new era in digital design is dawning right now.

    The way things used to be

    Before we get to the Grid, allow me to take just a moment to explain the markup structure of meyerweb’s main pages, and the positioning-and-margins approach I’ve been using for, um, about 12 years now. Here’s how the markup is structured:

       <div id="sitemast">…</div>
       <div id="search">…</div>
       <div id="main">…</div>
       <div id="extra">…</div>
       <div id="navigate">…</div>
       <div id="footer">…</div>

    Some of those IDs are idiosyncratic holdovers from my early-2000s view of layout and naming conventions. #extra, for example, is what most of us would call #sidebar. #sitemast stands in for #masthead. And #footer is from the days before the actual <footer> element

    The divs (which should probably be sections these days, but never mind that now) are arranged the way they are so that if the CSS fails to load, or a speaking browser is used to browse the site, then the site’s masthead is first, the ability to search the site is second, and the main content of the page is third. After that, extra materials, site navigation, and the footer follow.

    All of these were stitched together into a layout by absolutely positioning the navigate and search divs. The sitemast was set to be 192px tall, and both the navigate and search divs were given top: 192px; to show up just below it. In order to leave space for them to land, top margins were applied to the main and extra divs. (Fig. 1)

    Screenshot of web page
    Fig. 1: meyerweb’s home page (foreshortened)

    Constructing the grid

    So that’s how things have been laid out since the middle of 2005, more or less. I fiddled with a flexbox layout at one point as an experiment, but never shipped it, because it felt clumsy to be using a one-dimensional layout tool to manage a two-dimensional layout. I probably should have converted the navigation bar to flexbox, but I got distracted by something else and never returned to the effort.

    Besides, Grid was coming. In the run-up to Grid support being released to the public, I was focused on learning and teaching Grid, creating test cases, and using it to build figures for publication. And then, March 7th, 2017, it shipped to the public in Firefox 52. I tweeted and posted an article and demo I’d put together the night before, and sat back in wonderment that the day had finally come to pass. After 20+ years of CSS, finally, a real layout system, a set of properties and values designed from the outset for that purpose.

    And then I decided, more or less in that moment, to convert my personal site to use Grid for its main-level layout. It took me less than five minutes to come up with the following:

    body {
       display: grid;
       grid-template-rows: 192px min-content min-content 1fr;
       grid-template-columns: 1fr 20em;
    #sitemast {
       grid-row: 1; 
       grid-column: 1 / span 2;
    #search {
       grid-row: 2; 
       grid-column: 2;
    #main {
       grid-row: 3; 
       grid-column: 1;
    #extra  {
       grid-row: 3; 
       grid-column: 2;
    #navigate {
       grid-row: 2; 
       grid-column: 1;
    #footer {
       grid-row: 4; 
       grid-column: 1;

    That’s not all I had to do, but it’s the core. Let me break it down for you.

    body {
       display: grid;
       grid-template-rows: 192px min-content min-content 1fr;
       grid-template-columns: 1fr 20em;

    This part of the CSS sets the body element to be a grid container and sets up the grid lines. When you make an element a grid container, all of its children become grid items. (If you’ve worked with flexbox, then this pattern will be familiar to you.) So with that display: grid, I turned all of the child divs into grid items.

    Next come the rows in the grid. The values in grid-template-rows actually define separation distances between grid lines (the same is true of grid-template-columns, which we’ll get to in a moment). So the value 192px min-content min-content 1fr; means: “Go 192 pixels down from the top of the grid container and drop a grid line. Then drop another two such that they provide enough vertical space for the contents of the rows they define. Finally, leave one fr (fraction) of distance between the third grid line and the bottom of the grid container.” (Fig. 2)

    Screenshot of web page
    Fig. 2: Defining the rows

    The value min-content is pretty cool. It means just what it says: “Take up the minimum amount of space needed to fit the contents.” So for the second row, the one that will contain the navigation bar and search field, it will be as tall as the taller of the two, and no taller.

    Ditto for the third row, the one containing the main and extra divs. On the homepage, the main div will be taller. On subpages, that might not always be the case. In all circumstances, the row containing those two divs will always be tall enough to contain them both.

    With the rows figured out, next come the columns. I decided to keep things simple and just set up two. If you look at meyerweb’s home page, it appears to have three columns, but that’s only true of blog posts—a substantial but minority part of the site—and the left-side “column” is more of a sidebar inside the main column.

    In the original design, the sidebar (#extra) is 18em wide, with some extra space to keep it away from the main column. But the column also has to fit the search box, which is a bit wider. After some experimentation, I settled on a width of 20em. The rest was left to flex as 1fr. (Fig. 3)

    Screenshot of web page
    Fig. 3: Defining the columns

    Now that I’ve used the fr unit twice, a few words of explanation are in order. fr stands for “fraction,” and means “a fraction of the available unconstrained space.” In this grid, there are two columns. One of them has an explicit width of 20em, which is thus constrained—there’s no room for flexibility. The rest of the column space is unconstrained—as the width of the grid container changes (say, due to changes of the browser window) the unconstrained space will change to be the container’s width minus the 20em of constrained space.

    Imagine for a moment I’d decided to split the grid into four columns, with the rightmost being 20em wide and the rest being equal, flexible widths. That would have looked like:

    grid-template-columns: 1fr 1fr 1fr 20em;

    Alternatively, I could have written it as:

    grid-template-columns: repeat(3, 1fr) 20em;

    In any event, that would have caused the unconstrained space to be divided equally among the first three columns. If the grid container were 65em wide, the last column would be 20em wide, and the other three 15em each. (3 x 15 = 45; 45 + 20 = 65.) Shrink the grid container down 50em wide, and the first three columns would shrink to 10em each.

    In my case, I wanted that first column to take all of the space not given to the constrained last column, so it got 1fr. The final result is shown in Fig. 4.

    Screenshot of web page
    Fig. 4: The complete grid

    Placing the items

    With the grid lines set up, now it’s just a matter of attaching grid items to the grid lines. This can be done automatically, using the grid-flow algorithm, but this is a case where I want to place each item in a specific place. That leads to the following:

    #sitemast {
       grid-row: 1; 
       grid-column: 1 / span 2;
    #search {
       grid-row: 2; 
       grid-column: 2;
    #main {
       grid-row: 3; 
       grid-column: 1;
    #extra {
       grid-row: 3; 
       grid-column: 2;
    #navigate {
       grid-row: 2; 
       grid-column: 1;
    #footer {
       grid-row: 4; 
       grid-column: 1;

    For each of the six divs, I simply said, “Pin your top edge to this row line, and your left edge to this column line.” I used line numbers because that’s all I gave myself—it’s possible to assign names to grid lines, but I didn’t. (But stay tuned for an example of this, later in the article!)

    So, to pick one example, I set up the #main portion to start on the third row line and the first column line. That means it will, by default, fill out the space from the first to second column lines, and from the third to fourth row lines.

    Almost all of the divs were set up in this way. The exception in this case is the #sitemast. It starts at the first column and row lines, but since I wanted it to go all the way across the grid, I set its column value to 1 / span 2. That means “Start at column line 1, and span across two columns.” I could have gotten the same result with the value 1 / 3, which means “Go from column line 1 to column line 3.” (Fig. 5)

    Screenshot of web page
    Fig. 5: The grid items’ placement

    But realize: that’s just a diagram, not the actual layout situation. Not yet, at any rate.
    Something I want to be clear about here is that while you can explicitly assign all of your grid items to specific rows and columns, you don’t have to do so. Grid has a flow model that allows grid items to be automatically assigned to the next open grid cell, depending on the flow direction. In my case, I could have gotten away with literally just these rules:

    #sitemast {
       grid-column: 1 / span 2;
    #navigate {
       grid-row: 2; 
       grid-column: 1;

    That would have ensured the masthead was two columns wide, and that the navigation div was placed in the exact grid cell I wanted. That would have left the second row’s first cell filled by navigation, and the rest of the grid cells open.

    Given that, the unassigned items would be flowed into the grid in source order. The masthead (#sitemast) would be placed in the first two-column row it could find, which turns out to be the first row. The search div would flow into the next open cell, which is row 2, column 2, because row 2, column 1 is already occupied by the navigation div. After that, the main div would flow into the first open cell: row 3, column 1. Extra would go into the next cell: row 3, column 2. And then the footer would be placed into row 4, column 1.

    The end result would be exactly what’s shown in Fig. 5. The difference would be that if I had a special page where another div was added, it could throw off the whole layout, depending on where it appeared in the HTML. By explicitly assigning my layout pieces to the places I want them, I prevent a stray element from upending everything.

    Given the styles I wrote, if a child element of the body is added to a page, it will become a grid item. If I don’t give it an explicit place in the grid, it will end up flowed into the first available grid cell. Since the lower-right cell (row 4, column 2) is unoccupied, that’s where the extra element would be placed…assuming it isn’t set to span two columns. In that case, it would end up at the bottom of the grid, in an automatically-created fifth row.

    Accommodating the past

    It’s easy enough to set up a grid, but when you drop grid items into it, they bring all of their existing styles in with them. That might not be a big deal in some cases, but in mine, it meant all of the margins and padding I’d used to keep the layout pieces apart from each other were now messing with the placement of the grid items. You can see this in Fig. 6, created using a local copy of the site.

    Screenshot of web page
    Fig. 6: Grid + legacy = yoinks

    Ouch. It was time to override the pieces of the legacy layout styles I didn’t need in Grid, but did need to keep for browsers that don’t yet understand Grid.

    So I wrapped the whole bit in an @supports block. Since I wanted to constrain the grid layout to wider displays, I put an @media block just inside @supports, and then proceeded to zero out or otherwise change the various margins and padding I didn’t need in a Grid context. Here’s how it turned out:

    @supports (display: grid) {
       @media (min-width: 60.001em) {
          body {
             display: grid;
             grid-template-rows: 192px min-content min-content 1fr;
             grid-template-columns: 1fr 20em;
          #sitemast {
             grid-row: 1; 
             grid-column: 1 / span 2;
          #search {
             grid-row: 2; 
             grid-column: 2;
             position: static; 
             padding: 0.25em 0 1em;
          #main {
             grid-row: 3; 
             grid-column: 1;
             margin-right: 0; 
             margin-top: 1.25em;
             padding-top: 0;
          .hpg #main {
             margin-top: 0; 
             padding-top: 0;
          #extra {
             grid-row: 3; 
             grid-column: 2;
             position: static; 
             top: 0;
             margin-top: 0;
             padding-top: 0.5em; 
             margin-left: auto;
          #navigate {
             grid-row: 2; 
             grid-column: 1;
             position: static; 
             margin-top: 1px; 
             padding-bottom: 0;
          #footer {
             grid-row: 4; 
             grid-column: 1;
             margin-right: 0;

    I probably could refactor that to be more efficient, but for now, I’m going to leave it as-is. It makes clear what had to be done to which grid item—which ones needed to override position so their absolute positioning didn’t interact weirdly with the grid, which margins and padding needed to be changed, and so on. Let’s look at the end result (Fig. 7).

    Screenshot of web page
    Fig. 7: Grid + @supports = yowza!

    You might be forgiven for thinking that this was much ado about not very much. Why go to all that effort just to make it look the same? The real power here, in what is admittedly a simple case, is how I no longer have to worry about overlap. The footer will always be below the main and extra divs, no matter which is taller. When I was using positioning, that was never guaranteed.

    Similarly, the navigation and search will always maintain a shared height, making sure neither will overlap with the content below them—and thanks to min-content, I don’t have to guess at how tall they might get. Grid just handles all that for me.

    And remember, the layout still functions in old browsers just as it always did, using positioning. I didn’t “break” the site for browsers that don’t understand Grid. The more capable Grid layout is there, waiting for browsers like Chrome and Firefox that understand it.

    If you want to see all this live for yourself, head over to meyerweb.com and inspect elements in Firefox 52 or later. There you’ll see a little waffle icon next to the display: grid declaration on the body element. Click it, and Firefox will draw the grid lines on the page for you to scrutinize. (You can also enable a more powerful layout tool in Nightly builds of Firefox; see my post “ Grid Inspection ” for details.)

    Naming conventions

    I mentioned earlier that it’s possible to name grid lines. I didn’t do it for my own styles because the grid I defined was so simple, but for more complicated grids, naming the lines might be useful.

    Using the stripped-down version of the styles, the one without all the legacy overrides, naming the grid lines would look something like this:

    body {
       display: grid;
       grid-template-rows: [masthead] 192px [navsearch] min-content [mainextra] min-content [footer] 1fr;
       grid-template-columns: [left] 1fr [middle] 20em [right];

    Each of those square-bracketed words is assigned as a name to the corresponding grid line. (Fig. 8)

    Screenshot of web page
    Fig. 8: Named grid lines

    Once those names are defined, you can refer to them in your grid-row and grid-column properties. For example:

    #sitemast {
       grid-row: masthead; 
       grid-column: left / span right;
    #search {
       grid-row: navsearch; 
       grid-column: middle;
    #main {
       grid-row: mainextra; 
       grid-column: left;
    #extra  {
       grid-row: mainextra; 
       grid-column: middle;
    #navigate {
       grid-row: navsearch; 
       grid-column: left;
    #footer {
       grid-row: footer; 
       grid-column: left;

    Much like class names, you can assign multiple names to a grid line by supplying a space-separated list. Try this one for size:

    grid-template-columns: [start left] 1fr [middle sidebar] 20em [right end];

    You can then refer to any one of those names in your grid-column declaration. There’s no defined limit on the number of names, but remember what comes with great power.

    In case you were wondering, you can mix grid line names and numbers, so something like grid-row: navsearch; grid-column: 2;} is completely fine. You can use any name the browser can parse, which means you can specify just about anything Unicode and your CSS file’s character encoding will allow.

    Grid and Flexbox

    A question you may have is: now that we have Grid, do I throw away Flexbox? Absolutely not! The two can and do work very well together.

    Consider the navigation bar of my design. For years, it’s been laid out using an unordered list and float: left for the list items. Simplified a bit, the CSS and markup looks like this:

    #navlinks {
      float: left; 
      width: 100%;
    #navlinks li {
      float: left; 
      list-style: none; 
      margin-left: 1px;
    <div id="navigate">
       <ul id="navlinks">
         <li><a href="…">Archives</a></li>
         <li><a href="…">CSS</a></li>
         <li><a href="…">Toolbox</a></li>
         <li><a href="…">Writing</a></li>
         <li>><a href="…">Speaking</a></li>
         <li>>><a href="…">Leftovers</a></li>

    Why not display: inline-block instead of float: left? Because that literally wasn’t an option when I wrote the CSS for the navlinks, and I never got around to updating it. (You may be sensing a theme here.)

    Now I have two much better options for arranging those links: Grid and Flexbox. I could define a grid there, which would go something like this:

    #navlinks {
      display: grid;
      grid-template-columns: repeat(6,min-content);
    #navlinks li {
      list-style: none; 
      margin-left: 1px;

    That would essentially get the same result, only in a grid, which is far more robust than either floats or inline blocks.

    On the other hand, I’d be using Grid, which is a two-dimensional layout system, for a one-dimensional piece of layout. It’s certainly possible to do this, but it feels a little like overkill, and it’s not really what Grid was designed to do. Flexbox, on the other hand, is designed for exactly these kinds of situations.

    So I might write the following instead:

    #navlinks {
      display: flex; 
      justify-content: flex-start; 
      flex-wrap: wrap;
    #navlinks li {
      list-style: none; 
      margin-left: 1px;

    Again, that would be basically the same result, but in a more robust fashion. In addition to keeping the links all lined up, the wrap value will let the links go to a second line if need be. And because the flexbox sits inside a grid item that’s part of a grid row whose height is min-content, any increase in height (due to line wrapping or whatever) will cause the entire row to become taller. That means the rows after it will move down to accommodate it.

    And now that I look at the markup again, I’ve realized I can simplify that markup without needing to touch any grid styles. Instead of wrapping a list with a div, I can drop the div and reassign its ID to the list. So the markup can become:

    <ul id="navigate">
      <li><a href="…">Archives</a></li>
      <li><a href="…">CSS</a></li>
      <li><a href="…">Toolbox</a></li>
      <li><a href="…">Writing</a></li>
      <li><a href="…">Speaking</a></li>
      <li><a href="…">Leftovers</a></li>

    After adjusting the selectors in my CSS from #navlinks to #navigate, the resulting layout will be exactly as it was before. The ul will become a grid item and a flex container. That is a thing you can do.

    The downside in my case would be dealing with any interactions between that change and my legacy layout, but it’s not a huge issue to solve. It’s just a matter of doing it.


    So what are the down sides?  Not many, but they do exist.

    Most fundamentally, there’s no way to define an overall page grid that has all items relate to it. In other words, if I say:

    body {
     display: grid;
     grid-template-columns: repeat(16, 1fr);

    …then that sets up a 16-column flexible grid for the body element only, and its child elements are the only ones that can become grid items. I can’t reach down into the document tree and assign elements to be placed on that body grid. That’s the main reason I didn’t try to put the little sidebar bits on my blog posts into a shared grid: I literally can’t, at this point, unless I resort to ugly CSS or HTML hackery.

    The capability to do such things is known as subgrid, and it hasn’t been implemented by any browsers as yet. There are questions as to exactly how it should or shouldn’t work, so there’s still plenty of hope that everything will work out in the end. It’s a disappointment that we don’t have it yet, and that lack restricts the full range of grid’s power, but hopefully only for a short while.

    In the meantime, I’m sure people will come up with ways to work around this limitation. A basic workaround in this case: I could define a grid that applies to every blog post individually, and arrange the pieces of each post on those nested grids. The CSS would look something like:

    div.post {
      display: grid;
      grid-template-columns: [meta] 10em [main] 1fr;
      grid-template-rows: [title] min-content [main] 1fr;

    With that, I could place the metadata, the title, and the post’s body text into the defined grid cells, using either grid line numbers or the grid names I set up. Something like:

    div.post h3 {
      grid-column: 2; 
      grid-row: title;
    ul.meta {
      grid-column: meta; 
      grid-row: main;
    div.post div.text {
      grid-column: main; 
      grid-row: main;

    The drawback is that the metadata is then constrained to be a specific width, instead of my being able to set a column that all metadata shares, and size it by the longest bit of content.  That’s no worse than right now, where I’m setting the floated metadata to an explicit width, so this doesn’t lose me anything. It’s just a (temporarily) missed opportunity to gain something.

    Another limitation, one that may or may not be addressed, is that you cannot directly style grid cells. Suppose I’d wanted to put a box around the #extra sidebar, completely filling out that cell. I’d have to style the div. I can’t do something like this:

    @grid-cell(2, 3) {
      background: teal; 
      border: 1px solid;

    I mean, I’m not even sure the syntax would look anything like that (probably not), and this sort of capability is only now starting to be debated by the Working Group. If you have use cases for this sort of capability, definitely share them with the world and the folks at www-style. The more real-world cases there are, the stronger the case for supporting them.

    And there will, inevitably, be bugs to fix. For example, as I was finishing this article, I discovered that in some situations, Chrome 57 can suffer from a page-blanking bug when using Grid. It appears to be caused by having absolutely-positioned elements removed from a Grid page, and can be triggered by extensions like Window Resizer and LastPass. The good news is that a fix has been accepted for Chrome 58, so it should be fixed by the end of April 2017 at the latest.

    Grid power

    I hope this exploration of applying Grid to a live site has given you a taste of what’s possible. But I want to warn you that it’s just a taste, and a minor one at that. I was only able to scratch the surface of what the Grid syntax makes possible, so if this has captured your imagination, I strongly encourage you to experiment and then to dive into the Grid specification to see what else is possible. (Grid gaps! Dense grid packing! Inline grids! Auto-filling rows and columns!)

    But even more, what I explored here was the barest wrinkle on the outer edges of a scratch on the surface of everything that Grid will make possible. Sure, it can make our existing designs more flexible, robust, and simple to maintain. That’s pretty great. It also makes possible layouts we’ve never even dreamed of, because they were impossible given the tools we had available. There are new techniques, even new art movements, waiting to be discovered. We haven’t experienced a phase shift this profound since the original move from tables to CSS. I hope you’ll be a part of exploring this new realm.


    As I said, this is at best an introduction. Want to know more? Here are some great resources to get you going: