A List Apart

  1. 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.

  2. 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.

  3. 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.

  4. 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.)

    Mindfulness

    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:

    =E2/1000
    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:

    =SORT(UNIQUE(B2:B),1,TRUE)
    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:

    =ARRAYFORMULA(COUNTIF(B2:B,G2:G))
    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:

    =SUM(FILTER($F$2:F,$B$2:B=G2))

    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:

  5. 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.

  6. 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.

  7. 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.

  8. 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.

    Freelancers

    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).

    Recruiters

    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.

    Memberships

    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.

    Summary

    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.

  9. 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.

    Example:

    • 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.

    -Dmitry

    (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.

    Footnotes

  10. 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:

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


    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>
       </ul>
    </div>
    
    

    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>
    </ul>
    
    

    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.

    Letdowns

    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.

    Resources

    As I said, this is at best an introduction. Want to know more? Here are some great resources to get you going:

     

  11. This week's sponsor: HIRED

    HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.

  12. Practical Design Discovery

    A note from the editors: We’re pleased to share an excerpt from Chapter 3 of Dan Brown's new book, Practical Design Discovery, available now from A Book Apart.

    One of the hardest design problems I ever worked on was for a company that helps IT groups manage risk. Their product focused on open-source components—inexpensive and widely supported by an enormous community, but often vulnerable to security flaws.

    What made this design problem hard was the complexity of the product’s underlying structure, a triangle of interrelated abstract concepts. To work through the problem, we created a series of sketches that helped us understand it.

    The outcome ended up being a relatively simple prototype, a model of the overall structure of the application. Though we were chartered to create a detailed design, our client later admitted that they knew we wouldn’t get there, but that they highly valued our efforts to solve the underlying structure. Those efforts set the direction for everything else on the product.

    Direction-setting assertions

    Much like when we frame problems, we can make assertions that set direction and describe decisions about the design. These decisions will be pretty high-level, meaning they’ll deal with a holistic view of the site or product. Decisions about details come later, though you’ll see that some assertions get pretty specific as a way of clarifying and testing the direction.

    There are three kinds of assertions you can make about design direction:

    • Principles define what the design should or shouldn’t do. These statements are grounded in research, and may be referred to as implications when you can tie them to research.
    • Concepts establish an overall approach for the product, expressed as a central theme or idea.
    • Models describe the product in an abstract way, showing the underlying architecture, structure, flow, or approach. They offer a sense of how the product will work (without actual functionality).

    If you try to make tactical decisions too early, you may set a precedent without understanding how it influences what comes next—it’s difficult to trace low-level decisions back to a specific objective or problem statement. Why is the button blue? There’s no project objective in the world that can justify such a decision.

    Instead, you’ll make a few low-level decisions alongside your assertions, using samples to illustrate, clarify, and demonstrate the application of the high-level decisions. For example, you might arrive at the design principle that the site’s tone should be friendly without being too casual or informal. You would demonstrate that through sample screen designs and content, showing messaging that says “Thanks!” instead of the too-formal “Thank you very much” or too-casual “You rock!”

    Exploring the big decisions through examples might encourage you to reconsider them, or to find places in the product experience that need variation. Perhaps the color palette is insufficient for everything you need, or the authoritative voice isn’t appropriate for certain pages.

    By venturing a solution, you’re not just asking, “Will this work?” You’re also asking, “Do I have enough knowledge to know whether this will work?” That is, steps toward solving the problem may trigger additional insights, or questions, about the problem. Great discovery entails providing just enough shape and definition so the team can get aligned behind them as direction for the product.

    Principles and implications

    Principles are rules that help designers evaluate their decisions about the design. They provide guidance in the form of absolute statements about what the design should or should not do. That said, no set of principles can be exhaustive. They read, sometimes, as commandments: rules that may be applicable to many different kinds of design decisions, and therefore open to interpretation.

    There’s no industry standard on how to write design principles, so you won’t be violating some ordinance if you use pictograms or write a dialogue. But principles are usually just one sentence, often written in the imperative:

    Do more with less (Microsoft Design Principles)

    Design for the customer and instill confidence (Intuit)

    Use data to make and improve decisions (Principles for 21st Century Government, Code for America)

    I like these, but they don’t feel specific to the product or company. Principles are most powerful when they’re directly relevant. These use more elaborate phrases that closely relate to the product:

    More than boxes on a screen (Google Calendar)

    Transitional interfaces are easier to learn and more pleasant to use (MapBox)

    Time matters, so build for people on the go (Windows User Experience Design Principles)

    Sometimes, you’ll find principles rendered as one- or two-word noun phrases, as if to complete the expression, “The Principle of ______.”:

    More Contrast (10 Principles of Codeacademy.com)

    Consistency (First Principles of Interaction Design, Bruce Tognazzini)

    Principles are sometimes followed by deeper descriptions and examples. My favorite variation of this comes from the Windows User Experience Design Principles. These principles include questions for designers to ask themselves about design decisions:

    1. Personalization, not customization
      • Does the feature allow users to express an element of themselves?
      • Have you made the distinction between personalization and customization?
      • Does the personalization have to be a new feature, or can it make use of existing features and information (such as the user’s location, background picture, or tile)?

    Regardless of the approach you take in framing the principles, use consistent language and structures, if only to make them easier to remember and use. If you lead with a verb, always lead with a verb. If you write a pithy phrase or a complete sentence to express the principle, always do that. If you write single-word principles, well, there’s a special place in purgatory for you.

    In my practice, I phrase principles as direct consequences of what we learned in research. I call them implications, and I prefer them because they fit into the narrative: “We learned that users often lose their place in the system. The implication is that the UI should prioritize clarifying context.”

    Implications answer the question, “So what?” You’ve generated a lot of data, and now need to explain why it all matters. I typically document this in a spreadsheet that identifies project questions, answers I’ve uncovered, and the resulting implications (Fig. 1).

    Table of three columns and five rows, with a list of questions in column one, answers in column two, and implications in column 3
    Fig. 1: Gathering activities generate answers to questions concerning context or requirements.

    Ultimately, principles and implications do the same thing, so I won’t belabor the distinction between them. In both cases, they make an assertion that, yes, guides the designer, but also provides a test: designers can compare an idea to the principle and determine how closely it adheres to the guide.

    There’s no standard for design principles, though there are lots of suggestions out there (the Resources section includes a few of the best). Here are my suggestions for crafting design principles.

    Be specific

    Principles should be as specific to the product as possible. “Easy to use” isn’t a meaningful principle, because it could apply to anything.

    For the project with the risk-management company I described at the beginning of this chapter, we used a number of principles. In early versions of their product, users complained that it was easy to lose their place, so they couldn’t keep track of what they were working on. This led us to the principle:

    Always display the user’s context within the system, so they know where they are and what they’re working on.

    Context became something we talked about a lot. It forced us to think carefully before moving information to a different screen, or triggering a dialog box for taking action. Because of this principle, we often asked ourselves, “Can the user tell where they are? Is loss of context here okay?”

    Question your choices

    Good principles go beyond specificity: they issue a direct challenge to designers. They force you to take a second look at your work: does the principle invalidate any of your decisions? Done right, principles should make you squirm a little.

    In the risk-management product, the complexity of its requirements inevitably produced dense, esoteric designs. Elaborate displays attempted to capture every nuance, pack in every detail. At the same time, our client had heard their users didn’t like the dense displays. We had to walk a fine line, and so we relied on this principle:

    Show just enough information to support essential decisions—no more, no less.

    The principle’s borderline self-contradiction provoked us to reconsider what stayed on each screen as users worked through the process. Did we take out too much? Is everything on this screen absolutely necessary? On one hand, we wanted users to feel confident about where they were, but on the other, we didn’t want the page overwhelmed by navigation devices irrelevant to the current task.

    We also constantly asked ourselves, “What is ‘just enough information?’” and “What are the ‘essential decisions?’” Every iteration of the design tested the meaning of these key phrases.

    Inspire your team

    Specific and provocative principles may seem like whip-cracking: Do this, and do it this way. But a good principle also inspires you, pointing you to even loftier goals. It opens up possibilities by encouraging you to explore—and providing rationale for where you end up.

    In Luke Wroblewski’s summary of a 2009 talk by Stephan Hoefnagels of Microsoft, he writes, “Goals are the mountain peaks you are trying to get to. [Design] principles are the path we use to get to the top of the mountain.”

    One of the driving principles for my client’s product rested on the insight that the product was focused on bad news: every display was about what was going wrong in the IT department that day, how bad it was, and what wasn’t getting done. Like most interactive products, though, this one was meant to be a pleasure to use. In short, we needed to balance the gloom and doom with the satisfaction that comes from understanding the nature and extent of the bad news. We relied on this principle:

    Build confidence by clearly stating risks and making the data actionable.

    We knew the goal was to help customers manage risk. This principle acted as the path to the top of the mountain by inspiring us to focus not just on reporting the bad news, but also on ensuring customers could do something about it.

    Link principles to research

    Principles grounded in research make for stronger statements. The death knell of any principle is arbitrariness: if a principle comes from the subjective preference of the Chief Something Officer or because it reflects the (dysfunctional) way the organization has always worked, designers will ignore it. Your principle can be otherwise perfect, but if its source is suspect, the team won’t take it seriously.

    The team’s participation in all discovery activities is crucial here, too. Since they helped with the research, they can also help with writing the principles. By participating in crafting principles, your team will internalize them. Seeing the principles later will trigger memories of user observations, which they can integrate into their work more readily.

    The Windows User Experience Design Principles came directly from research. In reading some of these principles, you can almost hear supporting quotes from users:

    • Reduce concepts to increase confidence
    • Small things matter, good and bad
    • Be great at “look” and “do”
    • Solve distractions, not discoverability
    • UX before knobs and questions
    • Personalization, not customization
    • Value the lifecycle of the experience
    • Time matters, so build for people on the go

    You might argue that these lack specificity. When you take into account the scope of the project, however—an entire operating system—they’re sufficiently provocative and inspirational. “Solve distractions, not discoverability” is a bold statement, offering clear opportunities to refine the design without dictating a particular solution. It opens up conversations, and steers them, too.

    Concepts and big ideas

    One of my favorite scenes in Mad Men, the television show about advertising agencies in the 1960s, is the pitch to Kodak at the end of the first season. Kodak is introducing a new product, a circular tray that makes it easy to store and show photographic slides. They call it “The Wheel,” admitting, “We know wheels aren’t seen as exciting technology.”

    Creative director Don Draper, the show’s main character, explains that this product isn’t about the technology: it’s about tapping into our memories and emotions. The agency then pulls the veil off their concept for the campaign: the carousel.

    By establishing a central concept, a team (whether in advertising or web design) has a singular source of inspiration, a template for considering ideas. And while principles can serve as guideposts, only a concept can establish a vision. With both of them in your toolkit, your team has a potentially interesting tension to draw from.

    Using a carousel to describe a slide projector creates a metaphor brimming with meaning and possibility. It shows two ways we can express a big idea:

    • How the product makes you feel: carousels evoke the joy of reliving happy memories.
    • How the product works: the spinning carousel mimics storing and displaying photographic slides from a wheel.

    Either approach can help us express the big idea behind our digital products and websites. (Though I’ve never worked on a project that gave us a central concept as elegant as the carousel, which employs both approaches!)

    How the product makes you feel

    The purpose and function of interactive products offer ripe opportunities for metaphors, but metaphor isn’t the only way to express a central concept. For one web application project, my team expressed the essence with the phrase, “Power with flexibility.” Doesn’t quite roll off the tongue like the word carousel, but it evoked the desired feeling: that the app should make users feel like they can do anything.

    We elaborated with descriptions of how people would experience unconstrained power with the product:

    Provide users up-to-date status so they feel in control

    Lower barriers to entry

    Allow different styles of creating new content

    We also described what “Power with flexibility” meant from the user’s perspective:

    • Knowledge: having the right data to shed light on immediate needs
    • Responsiveness: being able to provide answers to stakeholders immediately
    • Accomplishment: getting up to speed on a crucial tool right away
    • Control: being able to fine-tune their content to suit different needs in different situations
    • Comfort: seeing the application as an extension of one’s own thought process

    Since this essence was a succinct idea, a little elaboration helped it to resonate with both the client and the project team.

    How the product works

    Complex interactive products benefit from a central idea that describes how they work. This usually means employing a big idea to convey the underlying structure.

    Shopping cart, for example, is a popular metaphor used on ecommerce sites. You could use it even if you weren’t working on an ecommerce site. The idea of “adding stuff to the cart” is a familiar metaphor that conveys a site’s underlying structure. We even relied on this metaphor on our career-guidance site: students would “add careers to their cart” after taking an assessment.

    There are a few other tried-and-true frameworks for describing the structure of a website. For web applications, there are two common ones beyond the shopping cart:

    • Hub-and-spoke: This is perhaps the most common pattern for structuring a website or digital product. The hub-and-spoke metaphor implies that the web application has a central screen, from which users may trigger all other functions.
    • List-detail: Another typical approach consists of a list of items from which users can select for more detail—like your email inbox.

    Do you have to use one of these structures? Of course not. But if your site lends itself to one of these approaches, you have your big idea that the rest of the functionality revolves around. (That wasn’t a carousel reference. I promise.)

    For sites that focus on delivering content (rather than transactional functionality), the tried-and-true frameworks deal more with how the content is organized:

    • Topics: what the content is about, or the subject matter
    • Actions: what tasks the content supports (like researching products versus troubleshooting products)

    These aren’t the only structures for categorizing content, but they are my go-to starting points.

    None of these is a fully fledged design in and of itself. They are well-understood frameworks that serve as the backbone to a much larger design. They are big ideas that describe how the product works.

    You don’t have to rely on an abstraction or metaphor (like the carousel) to convey the big idea, but instead draw from the emerging library of understood frameworks. That they are becoming part of web design lingo is a testament to their power and flexibility.

    There’s more where that came from!

    Check out the rest of Practical Design Discovery at A Book Apart.

  13. Long-Term Design: Rewriting the Design Sales Pitch

    We run our client service businesses just like door-to-door salespeople hawking vacuum cleaners. That may seem unfair, but it’s exactly how we sell design. We’re focused on short-term wins—but we’re teaching clients to see our work as disposable.

    I want to believe we’re better than that.

    We spend our entire careers knocking on doors and shilling our services. It’s just how we do business. Even if a potential client’s old design is working just fine, we might go for the hard sell. But that’s damaging, both to us and to our clients. This practice perpetuates the idea that design is only valuable when new.

    Consider the salesperson’s pitch:

    Your [design/vacuum] is old. Other people have newer ones. You’re going to lose out if you don’t buy a new one. Your family/business might even be unsafe with your current one.

    We believe that being a designer requires cycling through clients and booking new projects. Instead of talking about dust or maneuverability around furniture legs, the designer’s pitch is more like this:

    Your current design is not allowing your brand to resonate in the marketplace. It looks dated, and your competitors all recently launched new branding. You could lose market share to competitors without a more modern design.

    Short-term engagements are bad for our clients

    We write articles in phenomenal publications like this one about how design isn’t just about aesthetics—design should be a fundamental part of how a business operates, conducts market research, and creates products and services. Design is powerful and important. So we preach the doctrine of Design Thinking. We work to improve accessibility and web standards for the good of all. We preach user advocacy.

    However, when we pitch design work to clients, so often we’re only selling the aesthetics. And, when we book the gig, we try to ship that design and get that final invoice paid so we can bring in the next client.

    We designers rarely stick around to see how well the design works. We begin each project with design thinking, but rarely maintain it. And because of that, each client goes shopping for another new design (or succumbs to the pitch of another designer) much sooner than they need to.

    Design requires time in order to deliver its full value. For example, when a new website launches, we can measure changes in analytics immediately. But that design also carries the potential for further improvements—enhancements that can be unlocked through A/B testing, analysis, and optimization.

    Unfortunately, the vast majority of sites are never optimized. They launch, sit for a year or two, then get replaced. Our clients aren’t getting the full return on their investments.

    And if you think about that even further, this “cycle of redesign” makes design less valuable. In other words, if design is only valuable when new, it isn’t very valuable in the first place.

    New, cheaper solutions are encroaching upon our profession, such as logo-designing software, theming algorithms, and drag & drop design tools. We fear we are being replaced by these alternatives or that the perceived value of design is decreasing. And in the next breath, we tell our clients “Let’s make a fresh, new design for you.”

    We can’t blame clients for trying affordable new options; we’re the ones who taught them to value “new” design in the first place.

    Cycling through clients is less lucrative

    Finding a constant stream of new clients takes a lot of effort and is a constant challenge for many designers and agencies. Freelancers spend countless hours crawling job boards and submitting their portfolios in hopes of getting hired. Agencies spend considerable resources responding to RFPs, and many employ sales staff and account managers.

    When designers enter more senior-level positions, they eventually face the frustration that more time is spent selling, meaning less time to design.

    Sales isn’t bad and will always be necessary to some degree. That said, when we spend more time on sales than we need to, compensation suffers. Naturally, reducing the time and effort on sales so we can do more design work would be more lucrative. To do this, we only need to stop knocking on new doors and instead continue to serve the clients we already have. We need to change how we structure our services and start supporting clients over the long term.

    Long-term work can be personally and professionally satisfying

    Designers have a certain obsession with making new designs, and you might think that working with the same client for a year sounds boring.

    I’ll admit it: making new designs is fun. I love the act of creation and the satisfaction of making something fresh and cool. However, by cycling through clients, we’re missing out on some of the most satisfying design work there is.

    Few projects are as challenging or gratifying as redesigning a responsive web app that has four tiers of navigation. That might sound horribly tedious and painful at first, but solving a difficult design problem brings incredible satisfaction.

    Further, witnessing people benefit as a direct result of your design can be powerful and rewarding—much more rewarding than the temporary thrill of making something new. You see your design taking an active role in growing a business or in improving a person’s daily work. You see other people recognizing your design’s value. That’s a great feeling.

    This is often only possible when you stick around and serve the client over the long term.

    What it’s like working with clients over the long term

    For me, the idea of a long-term structure for my design services started when a client said this:

    I’m tired of signing a contract every 6 weeks. Can I just pay you every month instead?

    Now I only do retainer work. All my current clients have been with me for more than a year.

    In the early days of running my solo consulting business, I spent a lot of time crawling job boards, writing proposals, scheduling “nice to meet you” calls, and booked only a small fraction of projects. Some weeks, I only did sales work and didn’t get to spend even a minute on design.

    Fast forward a couple of years, and I can’t even remember the last time I glanced at a job board. I don’t do sales calls. I don’t respond to RFPs, search for leads, or write long proposals every week. I do more design work than ever. And, I rarely do revisions on my work because my clients trust me. My design business is completely different now that I work with clients for the long term. I find more satisfaction in my work. I solve difficult problems and enjoy seeing my clients thrive.

    I make more money this way, too, because I get paid for more of the time I spend at work. (I don’t bill by the hour, but another way to put this is: I’ve increased billable hours and decreased non-billable hours.)

    How to set up long-term client relationships

    If you are tired of needing a constant flow of new clients and investing in the long view sounds like a plan, here’s how to start.

    Look for long-term needs. Most design projects conclude when we deliver the design and the client pays the last invoice. It seems final. But this can be terrifying for the client. Many clients don’t know how to use the tools we produce for them—they don’t know how to use a website or marketing campaign, and they struggle to determine whether it’s successful.

    By offering support and advice after the first project concludes, you not only show that you are committed to helping the client succeed and get value from the investment (which is good for the client), but you are opening the door to future projects with that client (which is good for you).

    There are many, many opportunities for continuing design work with clients who have profitable and growing businesses. Long-term work doesn’t have to consist only of small updates and maintenance; it can include supporting new business initiatives and keeping the brand and assets in line. You can position yourself as a design director and advise on strategy and brand consistency. These are extremely valuable services to our clients and protect their investment in the original project.

    Most clients don’t know how to match all of their marketing efforts to the new brand you created for them. Or, they may want to launch a new feature or product, or weave a new ad campaign into the design you’ve created. These evolutions need design support. By sticking around after the first project and showing the value of your partnership, you can position yourself to get hired repeatedly.

    To be clear, long-term work is not unpaid work. Delivering a design doesn’t mean a designer should be on the hook for free support indefinitely. Depending on the client and the kind of work you do for them, there are many possible ways to structure a long-term relationship, such as:

    • Monthly retainers
    • Additional project phases, such as conversion rate optimization (CRO) and user testing
    • Scheduling a check-in call a month after launching a new design
    • Including a written analytics report in the project fee.

    Clients might see these as attempts to increase fees and the project scope. That’s because long-term structures can be as unfamiliar to clients as they are to designers. To address those concerns, designers need to educate our clients about the benefits and value of long-term engagements. Great ways to begin the conversation include:

    • Explaining that optimization will help the client see the most return from their investment
    • Explaining that optimization will help avoid the need for a redesign later.

    Design’s “old money”: Big agencies and bigger accounts

    Long-term client service is old hat to big ad agencies; they’ve been operating like this for decades. If you read AdAge.com, you’ll see announcements about big agencies landing accounts from bigger companies to the tune of hundreds of millions of dollars. Of course, the agency doesn’t get to keep all of that—much of it goes to TV networks for ad time, and websites and print media for ad placements. But it usually means everyone gets to keep their jobs for a year.

    When a big account changes hands, it’s news. As in, the kind of news serious journalists cover.

    Agencies pour a ton of resources into landing big accounts, and, when they do, they get a year to prove their worth. Changing agencies is a major decision for big companies because it is a big investment and substantially impacts marketing success.

    While I don’t advocate replicating every aspect of the big agency model (especially not spec work), small agencies and even freelancers can offer long-term services to smaller clients in the same way. Consistent income and long-term relationships aren’t only for huge agencies that date back to the Mad Men era. Even operating on a smaller scale, the benefits to both designers and clients are the same.

    Practical freelancing concerns

    For me, personally, there was a lot to learn when I decided to try long-term engagements. That investment has paid off by providing me a more consistent freelancing income, reducing administrative and sales tasks and increasing my total income.

    That said, there are risks and complicating factors in long-term relationships.

    For freelancers, the risk of working with clients over the long term is that if you lose a client, you will have to work harder to refill your work schedule because your lead pipeline for new clients is slower. Worse, if you only work with a single client for a long period, it’s like putting all your eggs in one basket. Losing your only client is obviously a serious concern.

    Because of that risk, keeping several engagements active simultaneously is important for earning consistent income and protecting yourself if you do lose an important client.

    Additionally, long-term freelancing carries tax implications. The legal distinction between a salaried employee and a full-time contract worker, or even an independent contractor, varies in many countries, and some countries, such as the UK, are suspicious of long-term, full-time contract work because it can be used as a strategy by companies to avoid tax liability or to avoid providing legally required benefits.

    If not just for the financial stability, but also to avoid tax headaches, I recommend keeping several long-term client relationships active at once or limiting full-time engagements to shorter periods that then transition into part-time work for each client. And, of course, consult your tax advisor.

    If you’re working full-time for a client for a long period, such as six months to a year, you deserve benefits. While long-term work is stable and attractive for many reasons, don’t let it become a way for someone who is essentially an employer (as opposed to a “client”) to withhold compensation you deserve.

    Finally, writing contracts for long-term work can be complex, especially for structures like retainers. It’s always a good idea to consult a lawyer and to buy errors and omissions and general business liability insurance to protect yourself.

    Respect for designers and profit for clients

    With long-term optimization, design works better and better. And when clients see their profit increasing and that business goals are being met, they place greater trust in their designers.

    A long-term partner who works month after month to support a client’s business is vastly different from the door-to-door salesman.

    When designers behave as long-term partners, we prove the value of design and earn more respect. It also sets the stage so we can make great money while avoiding the less desirable sales work that so often invades our calendars.

  14. Big Data Visualization with Meaning

    The web is not the traditional home of data visualization. You might come across a bar chart here or there in your online journey on any given day, but they’ve never been an artifact of web history. It seems like that’s been changing.

    With the world becoming increasingly data-driven, we’re seeing more and more visualizations make their way onto our web pages and into our design briefs. They help us tell stories that better engage our users, and can even get them to take some kind of meaningful action.

    The problem is that these datasets—sometimes so large they’re literally called “big data”—can make visualization with meaning difficult. But that’s something we as designers are equipped to tackle. We just have to know what our users are hoping to gain from viewing and interacting with visualizations, and what we have to do to make their effort worthwhile.

    Data has a very strong power to persuade—powerful enough to change users’ everyday behavior, especially when data is informative, clear, and actionable. We should be putting data visualizations to work on our sites, enhancing our designs to show users how data is in service to the story they’ve come to learn about.

    Data visualization on the web can be meaningful through allowing people to discover the smaller stories that resonate with them, customizing their user experience instead of putting them on a predetermined path.

    Users attempting to interact with large and generally disconnected sets of data while navigating a site or trying to access relevant information end up facing a difficult, if not impossible, task. Our sites lose a certain measure of usability if they aren’t well-designed, even though the web is a natural medium for delivering truly interactive data. 

    As with all design, the approach we take when creating a user-minded visualization is based on the context and the constraints we have to work with. Good data visualizations—those with meaning—need to be accessible and human even though data is rarely described with those words.

    Telling a story

    The key to designing visualizations is to focus on something in the dataset that is relatable to and resonates with your users. I stumbled upon this while creating a visualization from the publicly available Open Food Facts dataset, which contains crowd-sourced information on food products from all over the world.

    Although the dataset covers an extensive range of information (even down to packaging materials and number of additives), I chose to focus on comparing average sugar consumption among different countries (Fig. 1) because I was personally concerned about that topic. It turned out to be a concern for others as well and became the most popular project for the dataset on Kaggle.

    Bar graph depicting quantities of sugar consumption by country
    Fig. 1: Average national sugar consumption

    Even though I didn’t make extensive use of the dataset in my rough and ugly visualization, what I chose to focus on told a story that resonated with people because most were from the countries listed or had a growing general awareness of high sugar consumption and its effect on health. In retrospect, what’s more personal and important than your health?

    Selecting data points that strengthen a story with a positive result (whether that’s eating less sugar or reducing large-scale chemical emissions) can be great, but it’s important to present a story that is as unbiased as possible and to make ethical decisions about which parts of the data we want to use while telling the story.

    But what exactly is a story in the context of a data visualization? We can’t kick it off with “once upon a time,” so we have to approach the idea in a different way.

    Whitney Quesenbery and Kevin Brooks provide these definitions of a story in their book Storytelling for User Experience:

    • Stories describe the context of a situation
    • Stories can illustrate problems
    • Stories can be used to help people remember
    • Stories can be used to persuade and entertain.

    And I would add to the list:

    • Stories can make you question the state of a situation.

    Addressing some or all of these attributes is a particular challenge for big datasets because the sheer amount of information can make finding a narrative difficult. But big or not, the principles remain the same. Visualizing any kind of data-driven story that resonates can have a powerful influence on users’ decisions.

    It also stirs other questions the user might ask.

    For instance, why do certain countries consume higher quantities of sugar? Are they the ones we expected? The information could challenge an assumption or two someone may have had prior to seeing the results. Just remember that visualization can be a stepping stone to further discovery, increasing the user’s knowledge and possibly affecting their everyday choices going forward.

    If you’re trying to embed meaning into a large visualization through the story of a dataset’s subsection, it’s important to:

    • Discover what your users care about in the dataset. Make it relevant to their personal needs, desires, and interests.
    • Focus on that subsection ruthlessly. Get rid of anything that doesn’t further the story your visualization is telling.
    • Take care to make ethical, unbiased decisions about which data points you use to create visualizations that might influence your users.
    • Be careful not to give people all the answers; allow them to ask their own questions and make their own discoveries about the data.

    This approach allows you to create something that not only resonates at a personal level, but also presents meaning in a way that encourages and allows users to take action.

    But we already have a story

    Though large, some big datasets already revolve around a single story. An interesting way of dealing with this particular issue is to simultaneously display different aspects of such a dataset, allowing the user to discover that meaning. This is called the “small multiples” technique. (Fig. 2)

    Assorted graphs visually illustrating data as seen from memory view, code view, and process view
    Fig. 2: Memory stall visualizations from the Rivet project at Stanford.

    The cluster of visualizations above, for example, deals with the “story” of memory stall issues on a computer. What I find interesting about the cluster is that the heading of every visualization starts with some variation of “memory stall time.” Despite being separate visualizations, they are linked by the single story they tell and they’re presenting it from simultaneous, distinct perspectives.

    It’s possible for perspectives to look completely different from one another if they visualize different kinds of data. For instance, bar charts and area charts can harmoniously coexist if the representations are appropriate for the data they’re showing. The Australian Census Explorer illustrates how this might work (Fig. 3). It allows the user to establish their own narrative through choice of topic, such as language or place.

    Screenshot of the native languages list in the Australian Census Explorer
    Fig. 3: Given freedom to explore, users inherently craft a personal narrative.

    Framing visualizations around a personal topic (like someone’s native language) affects all associated small multiples appropriately; reframing serves to personalize the data. (Fig. 4)

    Screenshot comparing two horizontal bar graphs depicting gender and age data for Australians and English-speaking Australians
    Fig. 4: Comparison of gender and age data for Australians and English-speaking Australians
    Screenshot depicting Country of Birth data, listing percentages for various countries and a global map with lines linking from Australia to each country
    Fig. 5: Country of Birth breakdown for Australian citizens
    Screenshot comparing two vertical bar graphs depicting income ranges by gender for Australians and for English-speaking Australians
    Fig. 6: Income ranges by gender for Australians and English-speaking Australians

    Storytelling through interaction

    It can be very useful with this approach to include an interaction in one design that is capable of affecting the others—something to help the user see relationships between data points they might not have considered before. This example from essay site Polygraph shows all Kickstarter projects across space, organized here by category and American city. (Fig. 7)

    Dot graphs depicting categories, number of projects, and size of projects in a selection of American cities
    Fig. 7: Well-designed data visualizations can convey multiple concepts and information in parallel

    The visualization is particularly interesting because it allows users to view the relationship of one variable (in this case, the project category) to others, such as American cities or project sizes. (Notice the prevalence of music projects in Nashville and game projects in Austin and Seattle). 

    The Lens does something similar in its visualization of the human genome (Fig. 8) by allowing users to change views by way of various filters.

    Horizontal bars aligned with their respective segments of a human genome sequence
    Fig. 8: Data can be filtered to display different views of the human genome.

    This can be even more effective for small multiples shown across time. Fig. 9 shows how this approach is used on a fund manager’s website. Changing the time period of an investment fund’s performance also shows how risk rating and the growth of an investment change during that period. By leveraging intuitive web animation, we can view snapshots of the data at precise moments in time.

    A stack of overlaid line graphs illustrating different tracking items, plus a vertical slider that reveals changes in the tracking items when moved to different points along the line
    Fig. 9: Interacting with one “small multiple” affects others, revealing relationships at distinct points of time

    If the dataset is already centered around some kind of overarching story, it can be a good idea to:

    • Display different parts of the dataset in separate visualizations simultaneously
    • Treat these separate visualizations as individuals tailored to the data they’re presenting. (Bar charts and area charts can live together in harmony if the data makes it appropriate.)
    • If there is interaction, ensure that it affects the entirety of your visualization approach so that the relationships between data points are more apparent
    • Apply well-considered web animation techniques to ensure that the interaction is intuitive.

    There are too many stories

    What do we do when a dataset doesn’t have a single, big story to tell, yet we still need to visualize everything in it?

    Although some datasets lack a specific focus (e.g., “memory stall time,” “fund performance,” or “all-Kickstarter-projects-ever”), data points may have internal relationships that reveal bite-sized stories. How do we create actionable meaning for those visualizations?

    Simply showing data as-is, even in a visualization that seems to fit, rarely works well. In Fig. 10 we see relationships between Python code packages, but in a way that’s just as messy and incoherent as the data in its natural state. The lack of focus and narrative is notable. (That said, the dataset is extremely large, so a single narrative isn’t actually possible.)

    A chart illustrating numerous types of data, with lines from type to type to show relationships
    Fig. 10: This visualization presents nothing actionable, despite the tremendous amount of data

    Since a single story isn’t possible in this situation, a better approach is to allow users to discover their own story. Your job is to facilitate that via the interaction design of the visualization.

    This browser-based design in Fig. 11 (you can explore it here) visualizes code package relationships, too (in this case, JavaScript), but gives users what they need to explore the data in a meaningful way.

    A computer-generated 3-D depiction of data relationships
    Fig. 11: Use well-designed interactions to help users work with large, multi-narrative datasets.

    Again, at first glance the visualization seems to be messy and incoherent—but look closer. Users can investigate any individual package of code, including its personal relationships (listed in the bottom left). A handy search bar has also been incorporated in the top left corner.

    What makes this particular visualization more meaningful is that the user can explore it in 3D space via keyboard and mouse. Leveraging this uniquely digital capability in the browser allows users to start discovering their own story in the enormous swarm of data, “moving” toward areas in the visualization that they find more relevant to their interests or needs. (Fig. 12)

    Detail view of specific data nodes in a computer-generated 3D depiction of data relationships
    Fig. 12: “Moving” intuitively through the data allows users to find meaning that’s personally relevant to them

    Once the user finds a package or groups of packages they’re interested in exploring, they can click on one for a specific and focused view of the package in isolation, including its relationships with other packages. A full breakdown of these relationships is posted on the left of the screen, including visual nodes linking directly to the Github page for that code package. (Fig. 13)

    Isolated close-up of a specific data note and its associated information in a computer-generated 3-D depiction of data relationships
    Fig. 13: Isolation view of a specific package.

    This visualization, like the one shown before it, uses the idea of a network in order to display the immensity of the data, but it also uses intuitive interaction and lets the user explore in order to extract personally relevant meaning. It uses the modern advantages of the web to deal with the modern problems of big datasets, much like the following visualization from OpenCorporates. (Fig. 14)

    Computer-generated display of country silhouettes sized according to the provided data and depicting lines of relationship from country to country and city to city
    Fig. 14: Look for ways to “translate” data into simple and relatable concepts and simple explanations.

    This design allows users to zero in on data they care about, choosing where they go and which breadcrumbs offer meaningful insight.

    If a dataset needs to be fully visualized but has smaller stories within it, it may be useful to:

    • Show all data, but give users the ability to create chunks or segments they wish to explore
    • Leverage the advantages of being digital. For example, explore how input devices (e.g., keyboard and mouse) can facilitate how users interact with the data.
    • Use visual metaphors that support extensive and intricate relationship associations, such as a tree or network.

    Visualization with meaning

    Data is powerful in the right hands, and something we’re skilled at presenting in our websites. But toss in words like “big data” or “data visualization” and we second-guess ourselves instead of owning it as part of our workflow. The web is actually a great place for data visualization.

    Leveraging the benefits of “digital” environments and tools, we can help users get what they need from large, complicated datasets. They are looking for insights, for meaningful information presented simply, for stories that resonate—for data stories they care about. We can help them find those stories by blending in a few new techniques on our end, such as sub-selections of data, use of small multiples to show relationships between data points, or even allowing user-driven focus on the full dataset.

  15. This week's sponsor: Hotjar

    Hotjar, see how your visitors are really using your site. Try it free.

  16. I Don’t Need Help

    We have no excuse…admit it. UX may brag about intuitive and pretty, but we sure suck at helping people—this one thing that most defines, most embodies great user experience.

    Throughout history, there’s one recurring theme: people need help. For all we know, the need for assistance might have triggered the development of communication. It could have led to bonding among tribes and our existence today. In the future, it might be the only thing that staves off human extinction and promotes societal evolution.

    But if so, that begs the question: why do we find it so difficult to ask for help or offer guidance to one another? Do we prefer to figure things out for ourselves? Are we afraid that any request for assistance would be fraught with obligations to reciprocate? Are we worried that we’ll be rejected? Or that we might not get the help we need?

    People do need help. It’s a given—and a problem in the field of UX. We claim to do so much for users, but treat help as an afterthought. How come it isn’t our primary consideration?

    A glance at most websites, including those for large and small organizations, suggests that user assistance is treated as a cursory option—often relegated to a question mark symbol tacked onto a corner. The assumptions are:

    • Users won’t need help; the design is intuitive.
    • If users do want help, they’ll look for it (somewhere).
    • Once users figure out where to look, they’ll seek help when they need it.

    If the same scenario were layered on real-world interactions, it would be analogous to visiting a large museum, with maps, tours, guides, and program schedules hidden in a locker at some end far off the main entrance.

    Why offer help before it’s requested?

    Taking the guesswork out of a customer’s experience is beneficial to all involved.

    Consider that you’re walking into a new casual diner. Initially you may wonder if everything is self-service, and if you are expected to clear your own table. You could just stare at folks around the room and make your move based on what other diners are doing. Or, the franchisee could help you get up to speed right away. Ikea solves the what-do-I-do problem with a “Why should I clear my own table?” sign right at the center of its popular store restaurant. The sign solves two problems—it gives the customer needed information immediately and it promotes Ikea’s aim to cut costs.

    Designers create user interfaces through careful planning, so one popular conclusion is that if a design has been a success, no explanation—no prominent sign—is required.

    But help is often sought or needed for a variety of reasons. Help could be required to explain certain fields in a form, to define the meaning of a specific icon, to parse highly technical terms, to identify new features, to illuminate hidden gestures, or to detail policies that are obtuse.

    A user may immediately understand that a pencil icon opens an editing pop-up. If he doesn’t, he may well figure it out eventually but only after moments wasted in confusion.

    No matter how smart a design is, unless it is customized to every user’s personality, needs, working conditions, device, domain knowledge, technical expertise, and mood, it will need some explaining. A good designer empathizes with unique concerns and takes users as they are, from practiced online mavens to casual browsers. A good design includes user assistance that is given due consideration. 

    When help goes wrong

    Sometimes websites do make dedicated attempts to help. And sometimes those attempts smack of overkill.

    There are video tours expertly created to take users through each feature in the product. There are slideshows with custom fonts and colorful characters that highlight everything new and promising in the release. There are translucent overlays of clever pointers to indicate where useful action commands are located.

    Analytics and studies show that when presented with any of the above on launch of an application, a user either:

    1. Rushes through it with no interest in its content, or
    2. Closes it.

    The main issue with providing informational assistance as the first screen is that users do not care yet. They have not seen enough of the product to want to learn about its intricacies.

    Users want to get to the product as soon as possible; they’ve already read the marketing material, gone through the registration process, perhaps even read the “Terms and Conditions.”  They do not want anything else to lengthen the delay. If forced to read through preliminary content or go through tours, they do so while disengaged and hence, promptly forget all they learned.

    Some applications have book-length help manuals. Immense thought and work goes into writing and creating these documents. But they exist in a separate world, removed from the application itself, expecting the user to click away from her task at hand to read and learn. Often, they are poorly designed, making the process of finding information in the “help” website a chore.

    Can help intrude?

    Handholding, intrusive help is as frowned upon in the design world as lack of intuitiveness. Examples of this include forcing open an overlay with offers of help while the user is engaged in a task; loading screens full of product descriptions without context; or launching a product tour that must be completed before the user can access the product. This is where the need to understand the goals of the application comes in.

    Is this an enterprise application with cloud-based storage, multiple server connections, and sensitive data transfers? In that case, help should become a visible priority. What if it’s an app built with a strong gamification approach? In that case, help can probably take a passive backseat.

    Consider user behavior patterns while designing the help function. Some users prefer an uninterrupted reading experience—they like to dive deep into the subject matter, read every instruction, perhaps even download the content for offline reading. They rely on in-depth topic descriptions. On the other end of the spectrum, some users prefer to scan the text. They only seek help after they’ve made a mistake and will rarely go to a dedicated off-context help website. Short bites of support within the application work best for them.

    Instructions offered in a non-intrusive manner can enhance an experience, whether real or virtual. Hiking on a trail with clear path markers, distance indicators, wildlife cautions, and plant and foliage descriptions would be safe and informative and hence, helpful. The “x minute read” tag in Medium posts, the Slackbot messenger in Slack, and the delineations of simple steps in Google Apps Learning Center are all examples of help offered to users without distracting fanfare.

    How to help

    Simply ensuring your user assistance function is visible can be enough to provide comfort. In the same way a good interface doesn’t make users think too hard, a good help function should be easy to find and access.

    Help can be designed to be contextual or stand-alone (a mix of both works best).

    Contextual help is any form of user assistance that is embedded within the product’s screens. It prevents disruption from user’s immediate focus. It is concise and quick to read and access. It is available when the user requests or—even better—expects it.

    A few examples:

    • Tooltips that appear on hover indicating the name of an icon or button.
    • Info-tips that open after clicking an “i” or “?” next to a form or field or any part of UI worth explaining. These should have brief content that explains the purpose/meaning of the relevant element.
    • Ghost text that appears within a text field or next to the UI element to help users learn about the element.
    • A panel that functions an an overlay within the product screen, providing users with more detailed help information.
    • Quick “Getting Started” guides that merge with the interface and take users through the actions flow.
    • Tooltips indicating feature upgrades within the UI.
    • Hint text that demonstrates search protocols—such as suggested keywords that actually work in the application.

    Stand-alone help can take a more detailed approach.

    Designing the help center for an application is usually a challenge. Should information architecture match the application’s architecture? How will users approach the content? Would they want every action and interface element documented? If so, how should the content be structured for easy perusal? If they don’t, how do writers prioritize topics? How much is too much?

    Effective search functionality can help save users from getting lost in content; a prominent search box makes it simple to locate the right topic before users get overwhelmed. And if the application’s search option is internet friendly, it will appeal even more to those users who prefer using a “real” search engine (like Google or Bing).

    Documentation categorized by features or tasks allows users to filter more quickly. It is also important to identify which information warrants greater visibility—help users solve their most pressing concerns, and quickly. Customer feedback, analytics, and user research can help determine which topics your users are looking for most.

    The myth of technical proficiency

    Enterprise applications as well as consumer applications can benefit from a well thought out help system. It’s poor logic to say that an interface is designed for “technically proficient” users who therefore won’t need any help.

    A well-designed help function is more than a set of instructions in an emergency. It is thoughtful, approachable, and considerate. It knows that no quest for assistance is too small, no needed explanation is too big. It’s time we uprooted the precedents of cumbersome or “barely there” help functions. It is time to make Help helpful.

    After all, needing help is part of the human condition.

     

  17. This week's sponsor: Hired

    HIRED, where companies apply to you. Over 6,000 innovative companies are looking for you on Hired. Get Hired today.

  18. Considering How We Use HTTP/2

    A note from the editors: This article is part two of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part one, Using HTTP/2 Responsibly: Adapting for Users.

    It’s important to remember that HTTP/2-specific optimizations may become performance liabilities for HTTP/1 users. In the final part of this series, we’ll talk about the performance implications of such a strategy and how build tools can help you manage HTTP/1- and HTTP/2-specific assets.

    Our generalized example from the previous article shows how we can adapt delivery of site assets to a user’s connection. Now let’s see how this affects performance in the real world.

    Observing performance outcomes

    Developing a testing methodology

    Low speed mobile connections are quite common in the developing world. Out of curiosity, I wanted to simulate HTTP/1 and HTTP/2 scenarios with my own site on an actual low speed mobile connection.

    In a strangely fortuitous turn of events, I ran out of high speed mobile data the month I was planning to test. In lieu of extra charges, my provider simply throttles the connection speed to 2G. Perfect timing, so I tethered to my iPhone and got started.

    To gauge performance in any given scenario, you need a good testing methodology. I wanted to test three distinct scenarios:

    1. Site optimized for HTTP/2: This is the site’s default optimization strategy when served using HTTP/2. If the detected protocol is HTTP/2, a higher number of small, granular assets is served.
    2. Site not optimized for HTTP/1: This scenario occurs when HTTP/2 isn’t supported by the browser and when delivery of content isn’t adapted in accordance with those limitations. In other words, content and assets are optimized for HTTP/2 delivery, making them suboptimal for HTTP/1 users.
    3. Site optimized for HTTP/1: HTTP/2-incompatible browsers are provided with HTTP/1 optimizations after the content delivery strategy adapts to meet the browser’s limitations.

    The tool I selected for testing was sitespeed.io. sitespeed.io is a nifty command line tool—installable via Node’s package manager (npm)—that’s packed with options for automating performance testing. sitespeed.io collects various page performance metrics each time it finishes a session.

    To collect performance data in each scenario, I used the following command in the terminal window:

    sitespeed.io -b chrome -n 200 --browsertime.viewPort 320x480 -c native -d 1 -m 1 https://jeremywagner.me

    There are plenty of arguments here, but the gist is that I’m testing my site’s URL using Chrome. The test will be run 200 times for each of the three scenarios, and use a viewport size of 320x480. For a full list of sitespeed.io’s runtime options, check out their documentation.

    The test results

    We’re tracking three aspects of page performance: the total time it takes for the page to load, the amount of time it takes for the DOMContentLoaded event to fire on the client, and the amount of time it takes for the browser to begin painting the page.

    First, let’s look at total page load times for each scenario (Fig. 1).

    Stacked bar chart of “Total Page Load Times” testing results for each of the three scenarios
    Fig. 1: Total Page Load Times test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

    This graph illustrates a trend that you’ll see later on. The scenarios optimized for HTTP/1 and HTTP/2 demonstrate similar levels of performance when running on their respective versions of the protocol. The slowest scenario runs on HTTP/1, yet has been optimized for HTTP/2.

    In these graphs, we’re plotting two figures: the average and the 95th percentile (meaning load times are below this value 95% of the time). What this data tells me is that if I moved my site to HTTP/2 but didn’t optimize for HTTP/2-incompatible browsers, average page load time for that segment of users would be 10% slower 95% of the time. And 5% of the time, page loading might be 15% slower.

    For a small and uncomplicated site such as my blog, this may seem insignificant, but it really isn’t. What if my site is experiencing heavy traffic? Changing how I deliver content to be more inclusive of users with limited capabilities could be the difference between a user who sticks around or one who decides to leave after waiting too long.

    Let’s take a look at how long it takes for the DOM to be ready in each scenario (Fig. 2).

    Stacked bar chart of “DOM Content Loaded Time” testing results for each of the three scenarios
    Fig. 2: DOMContentLoaded Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

    Again, we see similar levels of performance when a site is optimized for its particular protocol. For the scenario in which the site is optimized for HTTP/2 but runs on HTTP/1, the DOMContentLoaded event fires 10% more slowly than either of the “optimal” scenarios. This occurs 95% of the time. 5% of the time, however, it could be as much as 26% slower.

    What about time to first paint? This is arguably the most important performance metric because it’s the first point the user actually sees your website. What happens to this metric when we optimize our content delivery strategy for each protocol version? (Fig. 3)

    Stacked bar chart of “First Paint Time” testing results for each of the three scenarios
    Fig. 3: First Paint Time test results indicate a significant difference in performance for HTTP/1 Unoptimized scenarios.

    The trend persists yet again. In the HTTP/1 Unoptimized scenario, paint time is 10% longer than either of the optimized scenarios 95% of the time—and nearly twice that long during the other 5%.

    A 10– 20% delay in page paint time is a serious concern. If you had the ability to speed up rendering for a significant segment of your audience, wouldn’t you?

    Another way to improve this metric for HTTP/1 users is to implement critical CSS. That’s an option for me, since my site’s CSS is 2.2KB after Brotli compression. On HTTP/2 sites, you can achieve a performance benefit similar to inlining by using the protocol’s Server Push feature.

    Now that we’ve examined the performance implications of tailoring our content delivery to the user’s HTTP protocol version, let’s learn how to automatically generate optimized assets for both segments of your users.

    Build tools can help

    You’re busy enough as it is. I get it. Maintaining two sets of assets optimized for two different types of users sounds like a huge pain. But this is where a build tool like gulp comes into the picture.

    If you’re using gulp (or other automation tools like Grunt or webpack), chances are you’re already automating stuff like script minification (or uglification, depending on how aggressive your optimizations are.) Below is a generalized example of how you could use the gulp-uglify and gulp-concat plugins to uglify files, and then concatenate those separate uglified assets into a single one.

    var gulp = require("gulp"),
       uglify = require("gulp-uglify"),
       concat = require("gulp-concat");
    
    // Uglification
    gulp.task("uglify", function(){
       var src = "src/js/*.js",
           dest = "dist/js";
    
       return gulp.src(src)
           .pipe(uglify())
           .pipe(gulp.dest(dest));
    });
    
    // Concatenation
    gulp.task("concat", ["uglify"], function(){
       var src = "dist/js/*.js",
           dest = "dist/js";
    
       return gulp.src(src)
           .pipe(concat("script-bundle.js"))
           .pipe(gulp.dest(dest));
    });

    In this example, all scripts in the src/js directory are uglified by the uglify task. Each processed script is output separately to dist/js. When this happens, the concat task kicks in and bundles all of these scripts into a single file named script-bundle.js. You can then use the protocol detection technique shown in part one of this article series to change which scripts you serve based on the visitor’s protocol version.

    Of course, that’s not the only thing you can do with a build system. You could take the same approach to bundling with your CSS files, or even generate image sprites from separate images with the gulp.spritesmith plugin.

    The takeaway here is that a build system makes it easy to maintain two sets of optimized assets (among many other things, of course). It can be done easily and automatically, freeing you up to focus on development and improving performance for your site’s visitors.

    Reflection

    We’ve seen how an HTTP/2-optimized site can perform poorly for users with HTTP/2-incompatible browsers.

    But why are the capabilities of these users limited? It really depends.

    Socioeconomic conditions play a big role. Users tend to buy the quality of device they can afford, so the capabilities of the “average” device varies significantly, especially between developing and developed nations.

    Lack of financial resources may also drive users to restricted data plans and browsers like Opera Mini that minimize data usage. Until those browsers support HTTP/2, a significant percentage of users out there may never come on board.

    Updating phone applications can also be problematic for someone on a restricted data plan. Immediate adoption can’t be expected, and some may forego browser updates in favor of preserving the remaining allotment of data on their plans. In developing nations, internet infrastructure quality is significantly behind pace with what’s in the developed world.

    We can’t change the behavior of every user to suit our development preferences. What we can do, though, is identify the audience segment that can’t support HTTP/2, then make an informed decision whether or not it’s worth the effort to adapt how we deliver content to them. If a sizeable portion of the audience uses HTTP/2-incompatible browsers, we can change how we deliver content to them. We can deliver an optimized experience and give them a leg up, and we can do so while providing performance advantages for those users who can support HTTP/2.

    There are many people out there who face significant challenges while browsing the web. Before we fully embrace new technologies, let’s figure out how we can do so without leaving a significant segment of our audience in a lurch. The reward in what we do comes from providing solutions that work for everyone. Let’s adopt new technologies responsibly. It behooves us all to act with care.

    Further reading

    Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.

  19. Using HTTP/2 Responsibly: Adapting for Users

    A note from the editors: This article is part one of a two-part series exploring the new HTTP/2 protocol and using it responsibly. Be sure to read part two, Considering How We Use HTTP/2.

    With HTTP/2 ticking up steadily in use, it’s clear that there’s something to this long overdue update to the protocol. Implementing it, however, not only changes how websites are delivered to the user, it demands that we think critically about how we migrate existing sites to the protocol. More importantly, it demands that we consider our users’ capabilities.

    Whether you’ve already migrated your site to HTTP/2 or you’re bracing yourself to take the plunge, there are challenges when it comes to tuning your site’s front end architecture to be the most performant it can possibly be for all your users. Perhaps you’ve read about what it takes to get your site ready for HTTP/2. Perhaps you haven’t. If the latter describes you best, it’s not worth getting into the weeds here. The gist of it is that HTTP/2 optimization patterns are the opposite of those for HTTP/1. Your site will perform better on HTTP/2 if you avoid practices that combine files, because caching for those resources will be more efficient when they change.

    In order to cope with the limitations of the aging HTTP/1 protocol, we were more than willing to sacrifice some degree of caching effectiveness for return visitors in order to speed up the initial loading of a site. Thus, techniques like scripts and CSS concatenation, image sprites, and inline assets were embraced. In a world that’s creeping toward HTTP/2, however, we’re told to abandon these practices —and for the most part, rightly so.

    The reality of the situation can be more complex than we initially thought. While HTTP/2 support on both the server and client side is steadily increasing, browsers that can’t understand the new protocol will linger on for some time yet—and that doesn’t just mean Internet Explorer. It also includes browsers like Safari on older versions of OS X, UC Browser, older versions of Android Browser, and Opera Mini.

    Sometimes we hurt the ones we love

    HTTP/2 support is not a one-sided affair. In order for it to work, the server must not only implement it, but the browser must also be capable of understanding the new protocol. When a browser that understands HTTP/2 begins requesting content from an HTTP/2 server, the exchange will predictably occur in, well, HTTP/2. In the case of an older browser like Internet Explorer on Windows 7 (or even a current browser such as Opera Mini), the conversation proceeds in HTTP/1. The underlying mechanism that drives this behavior is nuanced, but it can be considered progressive enhancement in that we’re not breaking the experience for users on platforms that can’t use HTTP/2. They’re merely getting a less optimal experience.

    Whether you’ve made the jump and optimized your site for HTTP/2 already, considering the jump from HTTP/1, or somewhere in between, it can pay (sometimes quite literally) to understand how these optimizations can impact your site’s users. Depending on your audience’s capabilities, a site optimized for HTTP/2 may well be detrimental for a segment of your audience.

    HTTP/2 enjoys broad support among users in the global sense. According to the popular feature support index site caniuse.com, HTTP/2 currently enjoys support of roughly 78% of all browsers currently in use. Some fringe browsers such as IE 11 below Windows 10, and Safari on OS X below El Capitan muddle the picture a bit. You can count on at least 72% of users globally to support HTTP/2 (at least at the time of this writing).

    Of course, this is just the big picture, and it isn’t an indicator of what your specific audience looks like. You need to consider the source of your visitors and what browsers they tend to use. You also need to consider where your users reside in the world.

    In the rudimentary statistics I’ve compiled from caniuse.com, I’ve found that users in developing nations tend to use browsers that don’t support HTTP/2 more often than those in developed nations. Following that up with statistics from Akamai’s Q3 State of the Internet Report, developing nations generally have a lower quality of internet infrastructure than developed nations. I won’t get into the data here (though you can have a look for yourself), but if you’re curious, you can check out this short write-up I’ve done on the subject to get some context.

    The confluence of these two truths creates a challenge in how we optimize sites for our visitors.

    • Even if you set up a web server that uses HTTP/2, there’s a segment of your audience that won’t receive the benefits because their connection to your server will be over HTTP/1.
    • Even worse, if you’ve optimized your site for the best performance on HTTP/2, you’ve likely made your website slower for users with older browsers.

    “Aw, hell! They should just upgrade their browser!” While some of us have said this at one time or another out of utter frustration in the face of solving a challenging problem, this is a terrible sentiment. It presupposes that the user has the ability to upgrade their browser, but they’re just too damn lazy to get around to it.

    The more likely problem is that users in developing nations are reliant on antiquated infrastructure or bound to a restricted data plan that makes this impractical. We need to be empathetic to this reality. It behooves you to know how many of your users are running HTTP2-capable browsers, and how many aren’t. All you need to determine this is a Google Analytics account and caniuse.

    caniuse is able to comb through your site’s visitor data, then give you the status of support for a particular browser feature in the context of your site’s visitors, rather than for a particular country. Perfect for determining browser support for HTTP/2 in your audience! By opening the settings panel in the site and then clicking the “Import” button under the “From Google Analytics” header, you’ll be prompted to allow caniuse to access your analytics.

    Here’s a real world scenario in which I’ve used this tool to determine an audience’s HTTP/2 support: My friend runs a reasonably popular blog about guitars and guitar accessories that receives roughly 30,000 pageviews per month. When I fed the site’s Google Analytics data into caniuse, it showed that the site’s audience over the most recent 30 day period had about 91% support for HTTP/2 (Fig 1).

    Visual comparison of two equations: All Web Site Data (78.47% + 12.27% = 90.74%) and Global (70.13% + 5.95% = 76.08%)
    Fig. 1: caniuse.com’s support threshold for HTTP/2 for a specific site, labeled “All Web Site Data.”

    91% seems like a high level of support for HTTP/2 —and it is! Despite that fact, you must take into consideration the raw number of pageviews from browsers fetching resources over HTTP/1 because they don’t support HTTP/2.

    Some basic math reveals that this segment represents 2,700 pageviews per month. Furthermore, the quoted support of 91% includes browsers that partially support HTTP/2. In this specific example, we can only be absolutely certain that around 78% of this site’s visitors support HTTP/2. This means that anywhere from 2,700 to 6,600 pageviews may be served over HTTP/1. The actual number is somewhere in between, and even though this is a minority of users, it’s still a significant number of pageviews on its own, and it may be too large for you to simply ignore.

    Adapting your users’ limitations

    By this point, we know three things:

    1. HTTP/2 servers will downgrade to HTTP/1 when responding to HTTP/2-incompatible browsers.
    2. HTTP/2-specific front-end architecture optimizations are usually detrimental to users on browsers that are HTTP/2-incompatible.
    3. Users in developing nations tend to have a lower level of support for newer browser features like HTTP/2, and tend to have slower internet connection speeds.

    The only thing we don’t know at this point is how to fine-tune our content delivery so that it’s beneficial for everyone. Before we can really think about modifying how content is delivered to the user, there are a couple of things we should consider first.

    Is HTTP/2 right for you?

    Assuming you haven’t already migrated to HTTP/2, there are a few things to take into account before you invest time and resources into making the switch:

    1. While the HTTP/2 specification doesn’t explicitly require SSL, it is a de facto standard in that browsers require it. If you implement HTTP/2 on your server and fail to install a valid SSL certificate, the connection will always downgrade to HTTP/1. For the budget-conscious, certificates range from reasonably priced to 100% free via Let’s Encrypt. Even with free certificates, implementing SSL still represents a cost to your organization. It takes time and effort in the form of QA testing to ensure that existing sites aren’t broken in the migration.
    2. If your site’s footprint is very small, HTTP requests are few, and upgrading to SSL isn’t pragmatic, you may already be well-served by HTTP/1. This is especially true if you’ve implemented HTTP/1-specific optimizations and it would cost significant developer time to unravel them into HTTP/2 optimizations. This doesn’t mean that you shouldn’t upgrade to SSL, though.
    3. If most of your site’s audience uses browsers that can only support HTTP/1 and your site is well-optimized for it, you’re probably already well-served by HTTP/1. But again: consider SSL anyway.

    Let me be totally clear: HTTP/2 is an excellent performance enhancement for large, complex sites with lots of assets that would otherwise perform poorly on HTTP/1. We just need to talk about how you might be able to mitigate some of the pain for users with less capable browsers, and that begins with identifying those users when they visit.

    Checking for HTTP/2 and adapting to users’ needs

    How you deliver content based on a given user’s HTTP protocol version depends on what technologies you have available on your host. You’ll usually use a back end language like PHP to modify the markup you send to the client. Regardless of the technology you use, there are two conditions you’re covering:

    1. If the user is on HTTP/2: You’ll serve more and smaller assets. You’ll avoid stuff like image sprites, inlined CSS and scripts, and concatenated style sheets and scripts.
    2. If the user is on HTTP/1: You’ll do the opposite. You’ll bundle files, use image sprites, and inline small assets.

    The specific mechanism by which you detect HTTP/2 support will depend on the back end language you use. In PHP, we can determine the protocol version of a given connection by checking the $_SERVER["SERVER_PROTOCOL"] environment variable. Below is a one-liner that stores the HTTP/2 connection status in a variable named $isHttp2:

    $isHttp2 = stristr($_SERVER["SERVER_PROTOCOL"], "HTTP/2") ? true : false;

    Using the stristr function, the $_SERVER["SERVER_PROTOCOL"] environment variable is checked for the presence of the substring "HTTP/2". If the substring exists, $isHttp2 is set to true. If not, it’s set to false. From here, it’s up to you to apply this logic to your site, but let’s look at a couple of things you could do. For instance, you could add a class of http1 to the

    tag:

    <?php
    if ($isHttp2 === false) {
    	?><html class="http1"><?php
    } else {
    	?><html><?php
    }
    ?>

    Using this class, you can adapt your CSS to serve an image sprite for HTTP/1 users, and individual images for your HTTP/2 users. Or maybe serve a separate CSS file with inlined assets using the data URI scheme. Speaking of serving different files, you could change your markup based on the user’s protocol version to change how you serve assets to the client:

    <?php
    if ($isHttp2 === true) {
    	<script src="/js/script-1.js"></script>
    	<script src="/js/script-2.js"></script>
    	<script src="/js/script-3.js"></script>
    } else {
    	<script src="/js/script-bundle.js"></script>
    	<?php
    }
    ?>

    Or you could change your markup to inline some critical CSS for HTTP/1 users with the handy file_get_contents function:

    <?php
    if ($isHttp2 === true) {
    	<link rel="stylesheet" href="css/critical.css">
    } else {
    	<style><?php echo(file_get_contents("css/critical.css")); ?></style>
    	<?php
    }
    ?>

    Of course, on HTTP/2 sites, you would take any content that you’d normally inline and use server push to confer the benefits of inlining without actually inlining content. How you specifically adapt your site’s content delivery based on the visitor’s protocol version really depends on your specific situation.

    This concludes the first article! In part two of this series, we’ll:

    • Apply these techniques to a real world scenario
    • Use a performance testing tool to check for meaningful comparisons se a build system to generate HTTP/1-friendly assets so you can keep your workflow clean and efficient.

    Further reading

    Learn more about boosting site performance with Jeremy’s book Web Performance in Action. Get 39% off with code ALAWPA.

  20. This week's sponsor: FullStory

    FullStory, the CX platform that captures every interaction on your site for pixel-perfect playback. Get it free, forever. For real.