EW Resource


There's a huge resource of Newsfeeds on the Net which brings up-to-date information and content on a wide range of subjects.

Here are just a few relating to web development.

A List Apart: The Full Feed
  • This week's sponsor: TeamGantt 

    Keep your projects on track and your clients up to date with intuitive project scheduling from our sponsor TeamGantt.

  • Frameworks 

    A note from the editors: We’re pleased to share an excerpt from Chapter 5 of Ethan Marcotte’s new book, Responsive Design: Patterns & Principles, available now from A Book Apart.

    Over the past few years, we’ve been learning how to adapt our layouts to the infinite canvas of the web. Our sites can be viewed on any size screen, at any time, and responsive design is one approach that lets us accommodate the web’s variable shape. But with all of the challenges we’re facing and those yet to come, we need to begin building not just patterns, but principles for responsive design—principles that will allow us to focus not just on layout, but on the quality of our work.

    If each part of your responsive interface is more or less self-contained—with its own layout rules, content needs, and breakpoints—then the code behind each element’s design is far less important than thinking carefully about how and why an element should adapt. In other words, how do we move beyond thinking in terms of columns and rows, and start talking about the quality of our responsive designs? And what would frameworks to support that look like?

    Finding the words

    Honestly, there’s no perfect answer to that question. But recently, a number of designers and organizations have started sharing the vocabulary they use to decide how and when their responsive designs should adapt. Vox Media, for example, thinks of their content as existing within a river—and in keeping with the metaphor, the flow of that content can be interrupted at certain points. Here’s how they describe the front pages of Vox.com:

    Content flows around “rocks” and “breakers,” which are modules such as a “Most Commented” list or a row of “Popular Videos.” Many of these behaviors remain in the new layout system, but the key difference is an added contextual layer. Elements in the river are laid out to better highlight the diversity of content on Vox—articles, features, videos, editorial apps, card stacks, to name a few. Each one displays differently depending on its type and neighboring entries.

    Note that the language they use to talk about the quality of their layouts doesn’t revolve around columns or rows. There’s nary a mention of grids. For Vox, the design process begins with content priority and evolves into a layout. By understanding the weight and importance of each piece of content that flows through the river, the Vox team can algorithmically generate a responsive layout that best reflects the importance of the information within it.

    Starting with an abstract system of columns and rows would be wrong for them—and, I’d argue, for every web designer. After all, according to Mark Boulton, there are three fundamental benefits of a grid system:

    • Grid systems create connectedness. A well-made grid can visually connect related pieces of content or, just as importantly, separate unrelated elements from each other. In other words, they help us create narratives from our layout.
    • By establishing predefined alignment points, grid systems help designers solve layout problems.
    • A well-designed grid system will provide visual pathways for the reader’s eye to follow, and allow them to better understand a visual hierarchy.

    As Boulton notes, we historically created grid systems by adopting a “canvas in” method. Working from the edges of a printed page, designers would subdivide a page into a system of columns and rows, and place images and text upon that grid in pleasing, rational arrangements. But the web doesn’t have any such boundary—after all, it’s the first truly fluid design medium. As a result, Boulton argues we should instead adopt a “content out” approach to designing our grids: to build more complex layout systems out from a foundation of small, modular pieces of content. And to do so, Boulton proposes three guiding principles:

    • Define relationships from your content. A grid for the web should be defined by the content, not the edge of an imaginary page.
    • Use ratios or relational measurements above fixed measurements.
    • Bind the content to the device. Use CSS media queries, and techniques such as responsive web design, to create layouts that respond to the viewport.

    By understanding the shape of our content, we can create flexible layouts that support connectedness—not just between related pieces of information, but between our layouts and the device. We can make responsive grid systems that don’t just fit on an ever-increasing number of screens—they’ll feel at home, wherever they’re viewed.

    Finding the seams

    Principles are wonderful, of course, but we still have to find a means of implementing them: of translating those ideals into practical responsive patterns and layouts. For me, that “content out” process begins by looking at the smallest version of a piece of content, then expanding that element until its seams begin to show and it starts to lose its shape. Once that happens, that’s an opportunity to make a change—to introduce a breakpoint that reshapes the element and preserves its integrity.

    But first, we need a method of finding an element’s seams, and understanding how it loses its shape. For me, that process begins by looking at four characteristics: width, hierarchy, interaction, and density.


    Width might be a little self-evident. As the width of a viewport changes, so does the width of a responsive design. But as the design gets wider or narrower, so will the elements within it, and as those modules expand or contract, there may be opportunities to add a breakpoint.

    Images from Meagan Fisher’s responsive portfolio showing how different screen widths affect the typography.
    On her stunning responsive portfolio, Meagan Fisher adjusts the typography of certain elements—not just their layout—as their width expands and contracts.


    Width is, I’m sure you’ll agree, the most common characteristic of a responsive design—but it’s not the only one. As the shape of an element changes, the hierarchy of elements may need to change as well.

    Let’s take a quick look at a product page on Tattly’s responsive ecommerce site. When viewed on wider screens, the primary content area has two key pieces of information: a photo carousel of the product on the left, and a call to action to purchase the product on the right.

    Screenshot from Tattly’s responsive ecommerce site, showing a two-column grid on wider screens.
    On Tattly’s responsive ecommerce site, the product content is laid out in a pleasing two-column grid on wider screens.

    But that’s just one view of this particular part of the design, because as screens get narrower, we lose the ability to place multiple columns side by side. That’s where a question of hierarchy arises: in a single-column layout, which piece of content should appear first? Tattly opted, quite rightly, to lead with photos of the product—but you may answer hierarchy questions differently on your site.

    Screenshot from Tattly’s responsive ecommerce site, showing how the product information shifts from two columns to one on narrower viewports.
    On narrower viewports, the hierarchy of product information shifts from two columns to one.

    Hierarchy is generally a reminder to be more vertically aware in our designs. After all, we have min-width and max-width media queries, but can also avail ourselves of min-height and max-height queries more often. I think the navigation menu for the Field Museum beautifully balances vertical and horizontal layouts.

    Screenshot of the Field Museum’s responsive navigation in narrow and wide widths.
    The Field Museum’s responsive navigation, which occupies the height of the design. Below a certain width, the navigation moves to the top of the screen to avoid cropping.

    On wider screens, the navigation is anchored to the left edge of the design, and spans the full height of the viewport. You may notice that they’re using the flexible box model, or flexbox, an advanced CSS layout method we’ll look at later in this chapter. But since flexbox allows elements to automatically fill the space available to them, as the menu gets taller or shorter, the navigation elements resize vertically—but below a certain width or height, the menu is placed at the top of the page.

    By minding the navigation’s vertical edges, the Field Museum was able to introduce alternate layouts to ensure the content inside their navigation menu was never concealed, obscured, or clipped. In other words, the breakpoints we introduce to our responsive designs aren’t tied to the shape of a device’s screen. Instead, our media queries defend the integrity of the content we’re designing.


    The way we interact with an element may change along with the design. Responsive navigation systems are probably the most obvious example of this. As we saw in Chapter 2, menus are often displayed in full at wider breakpoints but concealed at smaller ones, perhaps hidden behind expandable icons or links when space is at a premium.

    Screenshots of Karen McGrane’s company site, showing a traditional navigation on wider screens and a toggled display at narrower widths.
    Karen McGrane’s company site has a traditional-looking navigation at wider breakpoints, but on smaller viewports the user toggles the visibility of the menu. Same links, but a new interaction model.

    But navigation isn’t the only kind of content that might require interaction changes. For example, take the responsive sports brackets designed by SB Nation. While they appear as complex-looking charts at wider breakpoints, a simpler, more linear view of the brackets is shown on smaller screens.

    Screenshots showing SB Nation’s brackets: fully visible on wide screens, per-section carousels on narrower screens.
    I don’t know from sports, but I know I like SB Nation’s responsive brackets: complex charts on wide screens, but a carousel of match-ups on smaller viewports. Same information, different interaction.

    Along with the simplified layout, the brackets are presented as carousels in the smaller view, where real estate is more dear. Each of the four regions for the bracket are a single slide in the carousel, allowing the user to cycle through for details. The information in both visual states is the same, but the interaction model changes.


    Finally, the amount of information you’re showing in an element might need to vary over time—in other words, the density of information can change. The Guardian’s feature on the 2015 Oscars is full of examples of this, with responsively designed timelines displaying a significant amount of movie data. Above a certain width, thumbnail images are loaded in, slightly increasing the visual (and informational) density of the timeline.

    Screenshots of the Guardian’s responsive cinematic timelines, displaying an extra image on wider views.
    The Guardian’s responsive cinematic timelines gradually increase in density, displaying an extra image above a certain width.

    Density is, as you might have guessed, an area where you should tread very carefully. As we’ve discussed before, removing or hiding information because it doesn’t fit can be problematic.

    Screenshot of Tattly's navigation, hiding submenus on smaller screens.
    Tattly hides its submenu entirely, reducing its navigation to a list of primary sections on smaller screens.

    Personally, I think the Guardian’s timelines work so well because the images shown at wider breakpoints are enhancements: they’re not critical to understanding the information around them. Could they have designed alternate versions of the timelines to show images at all breakpoints? Possibly. But I think this is a wonderful example of density used to lighten the visual impact of a design, removing extraneous information without impeding access to the content.

  • Rolling Out Responsive 

    A note from the editors: We’re pleased to share an excerpt from Chapter 2 of Karen McGrane’s new book, Going Responsive, available now from A Book Apart.

    I wish I could tell you there was one true path to rolling out a responsive redesign successfully. But from talking to dozens of organizations, it’s clear that the process by which large organizations go responsive varies widely. Many different approaches will work—but you need to understand the benefits and risks of each approach.

    Can you redesign the entire site at once or do you need to stage the rollout over time? Are you going to retrofit the existing desktop site or start from scratch? Will you release a beta version of the site or do a “big reveal”? To find the right option for your organization, ask yourself these questions:

    • How worried are you about existing customers on the desktop site? Now, no one is going to answer, “Not worried even one tiny little bit.” But some organizations (say, publishers) redesign relatively frequently without launching a beta version—they just flip the switch. Other organizations (say, banks) know they can’t risk frustrating existing customers by introducing drastic changes without an adjustment period.
    • Are you redesigning a web application? Don’t let anyone tell you that web apps can’t be made responsive. They can—but it takes time and effort. If you have large tabular presentations of data, complex form-based transaction flows, or tricky integrations with legacy backend systems, be sure to build additional time into your process.
    • Do you plan to make changes to your content? A responsive redesign is a fantastic opportunity to clean up and pare down your existing content—you may never get a better chance to fix bloated content that isn’t doing its job. That said, many organizations find they can’t do everything at once, so they roll out the content cleanup in stages.
    • Do you plan to implement a new CMS or APIs? Many organizations report that the work they’ve done over the past few years to replatform their publishing systems makes going responsive much simpler. But you’ll need to decide whether to do the CMS or the redesign first. It’s riskier and more time-consuming to do them at the same time.
    • Are your stakeholders prepared for the review process? Some organizations use a responsive redesign to engage the entire organization in learning a new process. Others take a “better to ask forgiveness than permission” approach, rolling out the redesign first and fixing the inevitable broken pieces later.

    Once you know the answers to these questions, consider your options for going responsive.


    Doing a responsive retrofit means recoding the front end of the website with little or no change to the existing content and design.

    I must confess: before I started talking to companies that launched a successful responsive retrofit, I was convinced this was the worst of all possible options, doomed to deliver a subpar experience to everyone involved. My philosophical beliefs about the “right way” to manage web processes don’t always survive their encounters with the real world: I concede that a retrofit works well in some scenarios.

    In general, retrofits work best when at least one of the following statements is true:

    1. The content isn’t going to change (much).
    2. Complex web applications don’t need to be redesigned.
    3. A componentized framework is already in place.

    Companies like Capital One, Marriott, and Nationwide Insurance have implemented responsive retrofits successfully. Doing a retrofit forced them to focus on the responsive aspects of the project without getting sidetracked by larger questions of redesigning the site, editing the content, or replatforming the CMS. For many websites, a retrofit also helps mitigate political concerns around changing or damaging the desktop experience, since it doesn’t change much.

    Here’s how you roll out a retrofit right:

    • “Don’t touch the desktop” is a mandate often handed down to the responsive team, but this guideline is too limiting. It forces the team to work toward unnecessary design parity at the expense of making better design decisions for smaller screens.
    • “Do no harm to the desktop” is a more realistic and achievable ambition. This gives teams the flexibility they need to make adjustments to layout, design, navigation, or content.
    • Set realistic expectations with your team and develop a plan for making changes over the long term. Stakeholders may be surprised when they see how existing content and functionality shifts around on different screens.
    • Consider picking one section for a complete responsive overhaul. A fully edited and redesigned section can provide a useful point of comparison with the retrofit. Picking a section for a complete redesign will give teams experience with the process, show stakeholders what’s possible, provide insight into the level of effort that can inform future scoping processes, and offer real-world data about how a fully redesigned experience will perform compared to the retrofit.

    Beta release

    In recent years, popular web applications like Gmail, Flickr, and Delicious launched in beta—and stayed in beta. This “perpetual beta” approach was a precursor to the continuous deployment practices used by many applications today to support ongoing development and testing.

    Today, when teams say they’re launching in beta, they often mean that users can opt out of the new site at any time and return to the “classic” version of the website. This “parallel beta” approach requires significantly more time and effort to develop and review, but in return delivers the ability to roll out the redesign slowly, gathering user feedback and analytics data along the way.

    Companies like Fidelity, Beatport, and the Guardian have invested in parallel beta releases, which gave them a way to test and learn from the responsive design over time. Stephen Turbek, SVP, User Experience Design at Fidelity, said their decision to launch in beta was crucial to their success:

    One of our first steps was to build a beta site that people could opt-in to, try out for a while, and return to the current site. The beta site was significant additional work, but iterating live on a site with millions of passionate customers would not have been the right approach. This enabled us to make changes faster and get lots and lots of user feedback.

    Here’s what needs to happen to launch a successful beta:

    • A test-and-learn culture should already be established in your organization. Teams must be comfortable working in tight cycles of iteration and testing—most teams will need to run tests every six weeks, and even as frequently as every week or two. If you don’t already work this way, building a culture of learning from research will take time and add complexity.
    • Technical architecture and publishing infrastructure must be in place so users that can opt in and out, which can be costly.
    • Executive buy-in from stakeholders who see the value of the beta process and are willing to invest in maintaining two versions of the site—not to mention driving traffic to two different URLs—is crucial.
    • Quality assurance testing (QA) becomes exponentially more complex when testing on more form factors. Don’t underestimate the time or staff you’ll need to QA two versions of the site.
    • Rolling out the beta in stages will help control who can access it. Alex Breuer, Creative Director at the Guardian, said they found that showing the beta site to users coming in through search or social “was a gentle way of introducing the new Guardian experience.”
    • Assume early feedback will be negative if your beta site excludes content or functionality from the old site. Help stakeholders understand that negative feedback is not a sign of failure—in fact, getting these comments early is the whole point of the beta.

    Mobile-only responsive

    Another rollout strategy—often but not always implemented in the context of a beta release—is to develop a responsive website that covers all sizes of smartphones and tablets, preserving the current fixed-width site for desktop users only. In a sense, this approach is a “responsive m-dot site,” but that word puzzle twists my brain into a knot, so let’s not call it that. We’ll call it a mobile-only responsive site.

    A mobile-only responsive site buys an organization time to focus on larger, more complex issues. Companies know they need a site that serves mobile users, but they’re afraid to hurt existing desktop traffic. But they also know the site needs a complete redesign or major backend infrastructure improvements, so they don’t want to do a retrofit. In that sense, a mobile-only responsive design offers the best of both worlds. Teams can focus on getting the responsive design right, without dealing with the stakeholder politics and operational risks inherent in changing the desktop mothership.

    But this approach is also the worst of both worlds—it allows stakeholders to keep believing that the desktop website is the “real” website, downplaying the large and growing population of mobile users. It also means, as with all m-dot sites, that smartphone and desktop users will suffer from the same performance hit due to server redirects.

    Here’s what can you do to launch a successful mobile-only responsive site:

    • Treat it like a beta even if you’re not rolling it out in stages. Have a plan for gathering data, testing, and revising the responsive site. Over time, plan for a staged rollout to desktop users.
    • Make tough choices about content and functionality. This rollout strategy is most successful when it is used to clean up and pare down a site that’s gotten out of control. If you’re not prepared to make the hard decisions, just do a retrofit.
    • Educate your team on what makes a responsive website successful.
    • The risk with a skunkworks approach is that the “mobile” team will go off and do its own thing and the rest of the organization won’t learn from the experience.
    • Make it the real website. Set expectations that this process isn’t about building a “mobile” website—it’s about building a site that will eventually replace the desktop.
    • Know when to stop investing in the desktop site and shift resources to the responsive site. BBC News said that continuing to work on their desktop site “sucked resources and morale and that cost us dearly by delaying our strategic move to ‘Responsive News.’”

    Section by section

    Other organizations choose to start with a specific section—even one particular page or template type. Rather than doing the entire site at once, they choose to sandbox their efforts and give teams time to practice.

    Which section should you start with? The answer to that question varies as widely as any other rollout approach. Some organizations report that they picked a section they knew they wanted to redesign. Celebrity Cruises started with their Destinations section, making it responsive as part of a larger effort to rewrite content and replatform the CMS. Other companies start with a less popular section, a section run by stakeholders who are excited about the process, or one that gets a disproportionate amount of mobile traffic.

    And then there’s Microsoft, which started with their homepage. This Potemkin village approach to a responsive redesign can frustrate users—promising them a website that works well on mobile devices, only to betray those expectations on the first tap. But Chris Balt, Senior Web Product Manager at Microsoft, reported that it helped them get organizational buy-in on going responsive:

    Other sites have taken different approaches, starting from the bottom up or with some out-of-the-way corner of the site. Our attempt to do it first with the homepage—and beautifully so, if I say so myself—was a good choice. It led to significant visibility that I don’t think we would have gotten if we had started with some second-level support site or something like that. So even though the experience for a user may have suffered—they are one click away from a non-responsive experience—the visibility that it obtained us politically, organizationally, both inside and outside the company, made it a great choice. I am very glad that we did it that way.

    Here’s how you might go about rolling out a responsive redesign by section:

    • Choose a section that reflects the types of problems or design patterns you’ll find elsewhere on the site. Some sections, like “Investor Relations” or “About Us,” may be easier to implement because they have relatively simple content and layouts—but they won’t provide as much insight about how to handle more complex problems.
    • Focus on your core. As with Pilates, your core does all the work. Look at your traffic and usage data to identify the pages and sections of the site that matter the most to users. Put your energy there.
    • Make sure your first-round stakeholders are on board with the extra effort required to support the redesign. They’ll be asked to make unfamiliar decisions—and they’ll need to share and defend their rationale with the rest of the organization.
    • Track and document scope to inform future initiatives. Knowing how long certain processes take, where design and development teams ran into difficulty, and which decisions were challenging for stakeholders will help you plan the next phase of work.
    • Make global decisions with everyone in mind. Some choices really do affect everyone. Dealing with responsive images, designing navigation menus, identifying core content types, developing reusable modules as part of a design system—such topics require buy-in from more than just the people managing a particular page or section.
  • This week's sponsor: Pantheon 

    Catch Jeffrey Zeldman talking web infrastructure with Josh Koenig, co-founder of sponsor Pantheon, on The Big Web Show and when you’re ready to learn more about building scalable web infrastructure, don’t miss Pantheon’s weekly webinar.

  • Ask Dr. Web with Jeffrey Zeldman: Looking for Love: Standing Out from the Crowd of Web Job Seekers 

    A note from the editors: During the 1990s, “Ask Dr. Web” was a regular part of Zeldman.com—and now Dr. Web is back to answer your career and industry questions. Read on for his advice, learn the story behind the column, submit a question of your own, and join Dr. Web along with Sarah Parmenter for a live career consultation on Wednesday, December 02, 2015, from 1–2 p.m. EST.

    In our last installment, we talked about when, why, and how to quit your job.

    This time out, we’ll discuss what to do when you have a lot to offer but can’t seem to connect with the right job.

    I was hoping you could give me some direction on how to find a design mentor. I was laid off from my product design job about three months ago. I’ve been working as a designer and developer for almost 15 years, so I feel like I have a decent understanding of the industry.

    I’ve found myself stuck in a position where I’m seeing little to no traction finding a job or even getting interviews. I don’t know if it’s because I’m currently unemployed, my portfolio is weak, or if I appear too senior on paper, or what. I’ve sought feedback from peers, but the only thing anyone wants to tell me is “you’re a good designer and your work is solid.” I can’t seem to find a source of objective feedback. I don’t know how to grow in order to get out of this slump. Do you have any advice for someone in my position?

    Slumpy in Seattle

    Dear Slumpy:

    Judging from your website, your design work is excellent. Solid, yes—with a light, warm, human touch. Understated craftsmanship that conveys a sense of brand and place, using ordinary typefaces, colors, and interface conventions. I know how hard it is to achieve that level of elegance and grace. You are clearly a mature and seasoned designer.

    Perhaps you’re looking for the wrong jobs. You may not be presenting a focused enough persona for the jobs you’ve applied for. A skilled and seasoned generalist designer can always find good work, but won’t get hired at, say, an overfunded and under-directed startup that is looking for cheap designers.

    For that matter, a seasoned product designer with a general background won’t get hired by a startup—they’re not only looking for product specialists, they’re looking for product specialists who have a track record at companies just like theirs. They might not hire an excellent designer with a deep understanding of product who hasn’t worked at places like that. Slack, for example, might hire you as a product designer only if you’d already worked as a product designer at Twitter or Facebook. (I’m using Slack simply as an example. Their hiring practices may be entirely different from what I’ve described. But most startups hire people who’ve already worked at startups.)

    In other words, people may be providing bland or vague feedback not because there’s anything wrong with your work, but simply because you’re not in the hiring track from which they draw candidates. I had a similar experience during my advertising career, when I was told I could never be hired at a hot boutique agency because I hadn’t started my career at one. (I ended up working at a hot boutique agency anyway, but only after years of wandering in the desert, and then only for peanuts.)

    Given that your work is good but people aren’t responding so far, maybe the particular niche you’re seeking work in isn’t hiring people with your background, or maybe that niche is simply overstuffed with good candidates, making it harder to rise above the crowd and get noticed.

    If that’s the case, maybe you need to freelance. Maybe you need to start a small independent studio or company with a like-minded peer or two. That’s what worked for me. My career was absolutely going nowhere until I started Happy Cog, originally as a design studio with only one employee—me. Today it’s a boutique studio with offices in two cities. (The kind of boutique studio that might not have hired my younger self.)

    What worked for me won’t necessarily work for you, but it might. When you start your own business, you can stop worrying about other people’s limited judgements and their rules about who they want to hire, and start shaping your own destiny. Just an idea.

    Not cut out for the rich-today-poor-tomorrow freelance life? Try seeking work outside the obvious circles. If you’ve been an agency person all your career, look in-house. Good web design isn’t limited to digital companies. Traditional businesses need great web designers, too. They may need them more than digital businesses do. Look for a gig at a place that desperately needs design help and acknowledges it in an interview. (You don’t want a job at a place that needs design help but doesn’t know it and won’t understand or value it. You want a place that’s ready to change and looking for the right designer to lead the charge. That’s you.)

    Meantime, you’ve been stuck in your cubicle too long. Get yourself out there. (If your current peers aren’t providing feedback that gets you out of your comfort zone, take solace in their assessment that your work is very good—I agree!—then seek out new peers who can push you harder.)

    Look for a mentor like you’d look for a mate. Attend meetups (they’re plentiful and free) and lectures (there are plenty of good ones that are free or affordable). If you like what someone says during the Q&A, go up to her or him after the Q&A and start a conversation. If the conversation goes well, exchange numbers. Invite your new friend to coffee. You may have met your mentor. And even if you haven’t, you’ve met a colleague who can help you gain the perspective you seek. Not all mentorship comes from folks in positions of seniority and authority. Sometimes you learn the most from someone else at your own level. Hope this helps!

  • Mixing Color for the Web with Sass 

    Color is one of the most powerful components of art and design. We use it to influence mood, create an environment, and tell a story. Over 125 years ago, a great impressionist painter changed the way we think about color by observing light’s role in it. So far, these observations have been largely lost on design for the web, but a preprocessor like Sass gives us a tool to shed new light on our color palettes.

    One morning in 1890, Claude Monet began painting the haystacks outside his window. But he didn’t paint just one painting, and he didn’t even paint just one painting at a time. He would have his assistant cart out wheelbarrows of canvases and would work quickly and minimally on each one as the light changed throughout the morning. Sometimes he would work on a painting for just a few minutes before the lighting conditions had changed enough to warrant moving on to the next canvas. When he was finished, Monet had painted twenty-five canvases of the same haystacks in different sunlight, seasons, and weather. The same haystacks, the same base colors—yet presented in myriad ways.

    Claude Monet, Haystacks: Snow Effect (1891). Scottish National Gallery; public domain image.
    Claude Monet, Haystacks: Snow Effect (1891). Scottish National Gallery; public domain image.

    Historically, our ability to translate this kind of flexibility to the web has been limited. We’ve neglected the art of mingling color for emotional impact, while making the most of statically declared CSS color codes. Meanwhile, manipulating color on the fly has been relegated to the arcane realm of programmers.

    Thankfully, new tools give us more power over color than ever before. But although color on the web continues to march forward, CSS alone is still pretty inflexible. That’s where preprocessors become useful. Let’s explore some of the capabilities they can lend to our stylesheets:

    • Aliases help us better recognize which colors we’re using.
    • Lightening, darkening, and scaling give us fine-grained flexibility over palettes.
    • Color mixing unlocks our inner Monet and a whole new world of nuance and artistry.

    A hex on hex codes

    Start with the color declaration: you have to know the exact values of your colors in order to use them. That means that, unless you’re using prefabricated named colors, your style sheet fills up with multiple instances of cryptic hex codes or ambiguous HSL numbers. CSS variables are on the horizon, and they’ll help clarify which color is which with natural language—but what if we don’t actually have a name for our color? That’s the kind of power CSS preprocessors give us. There are several out there to choose from, but my examples rely on Sass. Other preprocessors probably have similar functionality, but I’ll leave you to do that research on your own.

    Let’s dig into this to see what I mean.

    We’ll create a new brand and choose two colors to represent it. The first thing I’m gonna do is name the colors: $toolbox and $ol-blue.

    Brand colors, $toolbox and $ol-blue, for a hypothetical site called Gullfoss Travel Supply Co.

    Now that I’ve established my brand colors, I’ve used them to build a website for Gullfoss Travel Supply Co. The concept behind this hypothetical site is to revitalize well-designed luggage labels that show off where you’ve travelled around the world. Variations of my brand colors exist throughout this site in different (lighter) tints and (darker) shades.

    Hypothetical site for Gullfoss Travel Supply Co.
    Hypothetical site for Gullfoss Travel Supply Co.

    Take, for example, this button:

    An “Add To Cart” button using a simple gradient.

    I wanted to give my button a sense of clickability, which I can easily achieve with a simple gradient. The button is based on the color I dubbed $toolbox. The highlight is a lighter version of the swatch and the shadow is a darker version.

    Traditionally, I would write this in CSS like so:

    	background-color: $toolbox;  // fallback
    	background-image: gradient(
    		hsl(0, 33%, 52%),  // highlight
    		hsl(0, 41%, 39%);  // shadow

    While the button color is based on one of my brand colors, two of these colors (my highlight and shadow) are not in my Sass constants. I had to figure them out on my own. I opened up a color picker and manually picked variations of the swatch. Not a big deal, really, but if I want to add a secondary button, this time based on $ol-blue, I’ll need to go back into the color picker once again and figure out the new values.

    And each of these buttons needs a hover state, too! The hover highlights and shadows are going to be lighter than those on the normal button, so do I declare four more constants, or do I just fill these values in once and hope I don’t need to use them again later?

    As it turns out, Sass can do this for me. It has built-in functions to process these colors without having to keep track of all the variations.

    Packing up the color picker for Sass

    One way to lighten a color is to use the lighten function:

    lighten($toolbox, 20%);

    And to darken a color, we can use the darken function:

    darken($ol-blue, 30%);

    Simple as that! Now we have a pair of tools to mix color on the fly. Go wild! Okay, don’t go too wild. This can get a bit tricky. Consider this: if we lighten $toolbox by 50 percent, we get a very light version of $toolbox. But if we lighten $ol-blue by 50 percent, it becomes completely white. That’s because $ol-blue is a much lighter color than $toolbox.

    In order to know how far we can lighten a color before it turns white, we have to know that color’s lightness value ahead of time. That information is conveniently encoded in its HSL notation. If we subtract the color’s lightness value from 100 percent, the result is the amount we can lighten a color to get to white.

    x = 100% - l

    Since $ol-blue’s lightness value is 60 percent, we can lighten it up to 40 percent before it becomes perfectly white. $toolbox’s lightness is 40 percent, so we can lighten it by 60 percent.

    Table showing that when lightening our colors, $ol-blue turns white faster than $toolbox, because it has a higher base lightness value.
    When lightening our colors, $ol-blue turns white faster than $toolbox, because it has a higher base lightness value.
    Table showing that when darkening our colors, $toolbox turns black faster than $ol-blue, because it has a lower base lightness value.
    When darkening our colors, $toolbox turns black faster than $ol-blue, because it has a lower base lightness value.

    Therefore, in order to master this new color palette, we’ll simply need to memorize the lightness values of each of our colors. Kind of annoying, but hey, it’s better than memorizing hex codes, right? Sure! But I’ll do you one better.

    Proportional palettes with color scaling

    Sass has another color function called scale-color() that can move a color’s components proportionally. scale-color() works on the red, green, and blue channels in RGB, and the saturation and lightness channels in HSL. (To adjust the hue similarly, you would use the aptly-named adjust-hue() function.)

    As I noted before, if we were to lighten $ol-blue by 50 percent, it would become pure white, but if we were to scale the lightness with scale-color() by 50 percent—

    scale-color($ol-blue, lightness, 50%);

    —it would be halfway between the original color and white.

    Now I know exactly how much to scale any of my colors to get to white: it’s always going to be 100 percent. If I scale $ol-blue’s lightness by 99 percent, it will still be 1 percent $ol-blue. Likewise for $toolbox or any other color you can dream up (barring colors that are already so light that they may round up to white earlier); they will always top out at 100 percent lightness.

    You can more easily see what I mean with the following color table:

    Table showing that when scaling the lightness of our colors, they become proportionally lighter, and therefore more predictable.
    When scaling the lightness of our colors, they become proportionally lighter, and therefore more predictable.
    Table showing that when scaling the darkness of our colors, they become proportionally darker, and therefore more predictable.
    The darker variations are proportional, too.

    With scale-color(), you can keep your color palette limited to your base constants, but still have incredible, intuitive flexibility with tints and shades. Now our gradient declaration might look something like this:

    	background-color: $toolbox;  // fallback
    	background-image: gradient(
    		scale-color($toolbox, lightness: 50%),
    		scale-color($toolbox, lightness: -30%);
    button: hover,
    button: focus{
    	background-color: scale-color($toolbox, lightness: 50%);  // fallback
    	background-image: gradient(
    		scale-color($toolbox, lightness: 60%),
    		scale-color($toolbox, lightness: -20%);
    	background-color: $ol-blue;  // fallback
    	background-image: gradient(
    		scale-color($ol-blue, lightness: 50%),
    		scale-color($ol-blue, lightness: -30%);
    	background-color: scale-color($ol-blue, lightness: 50%),  // fallback
    	background-image: gradient(
    		scale-color($ol-blue, lightness: 60%),
    		scale-color($ol-blue, lightness: -20%);

    In this example, notice I’m only using two of my constants and scaling them as desired. In fact, this can be applied across the entire page. The content on the homepage of the Gullfoss Travel Supply Co. only uses two brand colors, scaled to different lightness values. Despite the simple palette, there’s still a lot of flexibility here.

    Mastering color with mixing

    There’s one more way you can achieve these kinds of proportional palettes, and that’s with an even more intuitive, more powerful Sass function called mix().

    If we want to tint $ol-blue by 60 percent, we’ll write:

    mix(white, $ol-blue, 60%)

    Think of it like mixing a tube of white paint into a tube of Ol’ Blue. Likewise, if we want to shade $toolbox, we’ll write:

    mix(black, $toolbox, 30%)

    It turns out that mixing with white and black does perceptually the same thing as scaling a color’s lightness but, conveniently, it’s shorter to type. Beyond that, mix can help you easily create a look and feel on your websites that was previously not possible. If we can mix colors like paint now, can we make our websites look more like paintings? I believe we can—but we have to think less like programmers and more like artists.

    Consider, again, Monet’s haystack paintings. They’re a remarkable study of light, and wonderful from a purely aesthetic standpoint. But from a design standpoint, there’s a useful lesson to be found in them. In the words of another French impressionist, Pierre Bonnard, “Color does not add a pleasant quality to design—it reinforces it.” Remember the way the color of light affected the appearance of Monet’s haystacks. What if we could take our base colors and easily influence the color in our designs the way he did back in 1890?

    Sass’s mix() function unlocks that for us. Let’s take our color palette again and add in just a couple extra colors: a highlight and a shadow. Now let’s mix our brand colors once more, but instead of simply mixing with black and white, let’s use our new colors:

    A couple of new colors for our palette: $highlight and $shadow.

    Suddenly the whole palette becomes warm and inviting, and the darker colors are rich and vibrant.

    Color table showing that tinting with a yellow highlight gives the palette a sunnier appearance.
    Tinting with a yellow highlight gives the palette a sunnier appearance.
    Color table showing that shading with a complementary shadow makes the palette feel more natural.
    Shading with a complementary shadow makes the palette feel more natural.

    If I decide I don’t like this scheme, I can simply choose new values for those two constants, and the next time the Sass is compiled into CSS, the design will automatically reflect my change.

    With this next scheme, I’m starting again with the same brand palette, but now the highlight is bright pink, while the shadow is a dark, desaturated green.

    New $highlight and $shadow colors.

    It totally changes the look of the palette, yet it remains based around our original brand.

    Table showing that a change to the highlight and shadow colors is automatically reflected in your color palette when the Sass is compiled into CSS.
    A change to the highlight and shadow colors is automatically reflected in your color palette when the Sass is compiled into CSS.
    Table showing that highlights and shadows can be tweaked to achieve just the right mood or story for your site, without making tedious changes throughout your stylesheets.
    Highlights and shadows can be tweaked to achieve just the right mood or story for your site, without making tedious changes throughout your stylesheets.

    Looking back at Gullfoss Travel Supply Co., I’ve demonstrated some of the possibilities with this kind of color mixing on each of the sticker pages. Looking at Olympia’s page, the mood is totally different from the homepage, yet all of the markup, typography, and basic layout stay the same. But since nearly every color has been mixed to some degree with yellow highlights or purple shadows, a new light (literally) has been cast on the page. Now the content background is an eggshell color and the “Add to Cart” button is natural, yet vibrant.

    The Olympia page of the Gullfoss Travel Supply Co.  site.

    Lincoln’s sticker is colored strongly with tints and shades of red, so I wanted the page to reflect that. I chose reddish highlights and shadows to make the design cohere with the illustration.

    The Lincoln page of the Gullfoss Travel Supply Co. site.

    When you visit the page for Barton Springs Pool, the cool waters and green leaves are reflected throughout. The difference between the original colors and the new ones is subtle but distinct, and that’s the point. Your colors should work together to create an aesthetic that enhances your design.

    The Barton Springs Pool page of the Gullfoss Travel Supply Co. site.

    But if drama is what you’re after, look no further than The Grid. This page reverses highlights and shadows and lends a look inspired by the movie Tron. Quite a striking change achieved just by swapping out a few constants!

    The Grid page of the Gullfoss Travel Supply Co. site.

    Additional considerations for developing your palette

    Nearly every color on these pages is mixed with a highlight or shadow to one degree or another, but sometimes the elements in your design can look a little too homogenous, and they start to blend together. In such cases, feel free to supplement your designs with another set of color mixers. This can give the layers of your pages more depth and really make them pop.

    Let’s look again at the page for Lincoln. Remember, I wanted to give it a reddish tint. It’s hard to read text against bright red, so I dialed the highlights back a lot; they’re barely red at all. Then I set the background to green. Because green is red’s complement, it plays a trick on your brain, making the very light colors appear redder, while still maintaining a pleasing contrast ratio. (Note: Because this site is responsive, the background layer isn’t visible on narrow screens.) These separate layers use very different highlights and shadows that interact with each other.

    To pursue legibility and readability a bit further for a moment, it’s also essential to keep in mind the accessibility of your color schemes. Take another look at the page for The Grid. If you found it uncomfortable to read, you’re not alone! The menu at the top of the page suffers from a low contrast ratio. According to the WCAG guidelines, it should be 4.5:1, but it comes in well below at just 2.6:1! Good contrast ratios of text and background colors make using a site much more pleasant. There are plenty of tools and recommendations for exploring this topic further.

    Before I conclude, I want to go over browser support real quick, just so it’s clear. Because all this color processing is compiled into basic CSS color declarations, everything gets translated into a static declaration, which, of course, every browser today can understand. This means that you can start playing around with these techniques today!

    Color on the web has come a long way, and it continues to improve steadily as browsers and devices add support for new technologies. Meanwhile, preprocessor mixing has given color an evolutionary leap forward. It offers us unprecedented power to create tints and shades that help us tell our stories, give our palettes more nuance, and bring out our inner Monet.

  • Writing CSS on Growing Teams 

    This fall, my team started a new project and for the first time in a long while, I was working with another developer as I started to write the styles for the interface. In fact, I started the styles, and then went on vacation while they took over.

    This project has been an exercise in writing modular CSS, which I love, when working in a team. Having been a solo front-end developer for quite some time, this was a new challenge to me. When you want your CSS to be reusable, how do you have several people working in git branches on different pages without writing completely separate styles?

    Surprise: it’s not really about how we write CSS, it’s about the process.


    Communication is the biggest piece of making this work. As we work throughout the day, we talk about the styles we’re writing and where they might be used across the application, so the other person knows how work in progress could impact the parts of the application they’re focused on.

    For example, if I change a wrapper to meet the new design spec and want to be consistent across the entire application, I mention that it’s been changed, what’s changed about it, and the branch where I’ve done this. When my coworker normalizes buttons in one branch, they let everyone know that this will be taken care of for the whole team when that branch gets merged into the master branch.

    Code review

    I’ve worked on teams that did code reviews, but my current team didn’t always do them as we worked. As the team grew, we decided to incorporate code reviews into our process. The best part of a code review is learning from each other. Maybe the way I’ve done a layout works, but could it be better? Are there styles I’m not familiar with that would make it better?

    When we review code, we discuss our modules to ensure everyone agrees they’re going to be the best way to move forward. When talking through how to use SVGs in our code, for instance, we discuss when it’s appropriate to use them as background images as opposed to images, or inlining them by putting the SVG code right into the template.


    Finally, we came up with what’s important to our team when writing CSS and we documented that. We use the ideas from Jonathan Snook’s SMACSS to guide us, along with explaining features of Sass we want to stay away from (such as nesting), so the entire team has an easy reference.

    By making this explicit, we can refer back to it for reminders as we review code. In the near future, we also hope to build a style guide to further document our work. That way, we’ll have documented how we want the code written, and we’ll have a more visual documentation of the styles we’re using to retain consistency as we continue working on the application.

    As a team grows there are always bumps along the way, but it’s been a great challenge to start documenting our process, thinking about how we write CSS in a more formal way, and reviewing it together to make sure we’re all on the same page. For me, the challenge of going from being the only person writing everything, to adding new team members and working together, has been fantastic.

  • Career Consultation with Dr. Web—Live 

    Sometimes, you don’t even know what you don’t know.

    A few years ago around the Thanksgiving table, a family member was proudly telling us about the achievements of the young people he’s mentored through the years. Someone asked if he felt he always succeeded in helping. I can still see the sadness on his face as he told us about one person, technically competent and smart as can be, who never seemed to pick up on the social and teamwork skills that would help them truly go far.

    It just goes to show, there are people who want to pass on everything they know—who care about your growth and want you to succeed. You’re part of the web family now: a far-flung clan with many aunties, uncles, and older cousins ready to share their insights and experience. There’s even a doctor in the family.

    Jeffrey Zeldman started “Ask Dr. Web” 20 years ago to help “every web author and site designer be their best.” A lot of the early advice was technical stuff: if you were the one person who knew how to make a gif loop or how to shrink graphic assets to under 30k per page, you might be the office web hero. Today, the stuff that makes you shine is more subtle, and it’s not stuff you can get out of a step-by-step tutorial or a classroom.

    At first, it’s easy to think that strong design or development skills and a willingness to work is all you really need. What Dr. Web shows you is that making business contacts, learning how to set realistic freelance rates (hint: higher than you think; higher than you’re comfortable with right now), and judging your job by its challenges and growth opportunities rather than the base pay aren’t extras—they’re the foundation of a great career.

    Being columns editor has a little perk I love: getting an early peek at Jeffrey’s Ask Dr. Web columns. What blows me away is that in every column, he takes on one of those mysterious career/life skills that can take you from working a job to having a career and wraps it in his personal stories and warmth to explain how you can get over the invisible obstacles you may not even realize are in your path.

    That’s why I’m so excited to tell you about our upcoming event, a live version of Ask Dr. Web on December 2. I hope you can join in, submit a question of your own, and learn how to create the career you absolutely deserve to have.

    December 2 event: Ask Dr. Web—Live

    Join Jeffrey Zeldman and his cohost, designer and entrepreneur Sarah Parmenter, for a live version of Jeffrey’s must-read column. Together, they’ll tackle topics like:

    • Presenting your skills with current and potential employers
    • Raising your profile and your rates as a freelancer
    • Selling your work
    • Creating side projects that are satisfying and career-enhancing

    Register now, and then submit your career conundrums on Twitter with the hashtag #askdrweb, or directly in the Hangout (you’ll get the link when you register).

    This event is free and everyone is welcome—just sign up to receive instructions. Here are the details:

    Wednesday, December 2
    1–2 p.m. EST
    via Google Hangout and YouTube livestream
    Register or get more details

    Once you register, we’ll send you everything you need to join the event, participate in the Q&A, and then get updates on accessing the video and transcript afterward.

    Join our email list to get updates when new events are announced.


    Drupal and WordPress guides from Pantheon

    Hosting and site management platforms do more than impact development teams—they tie into the entire business. These two free guides from our sponsor Pantheon will help you choose an infrastructure that’s efficient, effective, and within budget. Learn how to:

    • Explore platform options
    • Pick something that grows with your goals
    • Coordinate your resources, factor in total costs
    • Assess your security and compliance needs

    Download the Drupal Website Platform Buyer’s Guide or the WordPress Website Platform Buyer’s Guide now.

  • This week's sponsor: DreamFactory 

    Build easy-to-use REST APIs with sponsor DreamFactory. Mash up multiple APIs and talk to different databases, all with solid API security.

  • Matt Griffin on How We Work: Balancing the Scale 

    Where do you work? The term you choose to describe this place—consultancy, studio, shop, agency, freelancer—is in some ways a roll of the dice. It’s an aesthetic decision as much as anything else. But it can also say a lot about the culture of the business. For instance, where are your offerings on the spectrum of fields like advertising, design, software development, and user experience? I’ve listened to people emote emphatically about what is a shop and what is an agency, assigning pride to one and derision to another.

    Another thing those terms imply, to some degree, is scale. No one’s going to advertise their 50-person freelancer, for instance. Likewise the proclamation of a 2-person agency will no doubt elicit a few snickers from the crowd.

    But feelings aside, is there a real correlation between some of the qualities we use to measure a workplace (capabilities, cultural traits, limitations) and its size? When we’re trying to figure out where to work, or how we want to develop our own business, might we be able to make some value judgements based on scale?

    To help make this a little clearer, I talked to some friends who have been in a variety of situations. Some of them started small and grew their businesses. Others went the other direction. Let’s see if we can figure out why.

    Go big or go home

    I myself am the founder of a place that has grown over the years, albeit very gradually and in small increments. We started Bearded in 2008 with two people, and are now at seven after as many years. Now by most standards we’re still pretty small, but the differences between 2 to 3 and 6 to 7 people can be quite striking.

    As a two-person business, anything that had to be done was done by one of us. Thus we wore a lot of hats. My major roles were that of designer, salesman, and project manager. My business partner’s were mostly that of web developer and operations. And then there were the myriad less-glamorous tasks we’d split up, like mopping the floor or harassing the landlord to get the electricity turned back on after the breaker in the locked basement blew for the third time that week (true story).

    At that point, we had only a dim awareness of many of the skills and processes that I now see as integral to successful web design. As we hired new people, we found we weren’t just adding staff that duplicated our existing skill sets, but bringing on folks whose expertise complemented our own. These new folks helped us create better products for our customers.

    Our new hires brought in skills like illustration, custom application development, animation, content strategy, information architecture, user experience design, and business development. Though you might expect this would broaden our offerings, it actually did the opposite. We added people and skills, but somehow our focus grew narrower. Those added skills allowed us the expertise to solve more complex problems in more specific areas. We stopped being a general design shop, refusing projects like logo and stationary designs. Over time we matured into a web consultancy focused on user experience in a multi-device world, through the lens of progressive front-end development.

    Ben Callahan had a similar experience with Sparkbox:

    The biggest benefit to having a larger team is that we can allow people to specialize a bit more. For example, as a front-end dev that’s transitioned to the role of president, I can focus on leading our company instead of writing code. When we were smaller, everyone did everything. This focus lets us go deeper in specific areas.

    For Bearded, that small amount of growth deepened our expertise and allowed us to shed what were, to me, the least interesting things we did. It allowed us to focus on what we’re best at—what sets us apart from others. In the process, that also made Bearded a more satisfying place to work.

    What you can do with more

    Quality of life and job satisfaction are important. But practically speaking, what are the advantages that you only find at scale?

    Val Head’s previous experience in agency life felt full of knowledge and resources:

    There were so many people with different strengths, background and knowledge. If there was something you needed to know you could pretty much find someone a few cubes over or on another floor who knew all about it.

    Jeff Robbins, co-founder and CEO of Lullabot, tends to agree:

    Being bigger has given us resources to accomplish more. We’ve been able to experiment with products and even improve our website in ways that were more difficult when we were a smaller company.

    So in Jeff’s experience, Lullabot can do more with more people. But does more people mean that you can do bigger projects? Val Head puts it this way:

    Larger businesses are better at handling a whole suite of related projects. Basically anything where having more people could make things go faster or more efficiently.

    Todd Parker and Patty Toland spent some time at a very large agency before founding Filament Group, and they found that scale also really affected business development:

    The upside of that large scale was that they hired really smart people and did insightful work for good companies who wanted to solve hard problems well, and with that scale they were able to secure contracts with bigger clients and get into rooms alongside serious Big Consulting firms, and compete.

    Which is all great. But there’s a big (pardon the pun) aspect to scale that we haven’t broached directly yet, and that’s money.

    It’s all about the Benjamins

    Regardless of how you price your work, if you’re running a healthy business, most employees should do enough billable work to cover their own cost, plus generate a profit for the business.

    Now as the business grows, there will likely be a need for some support staff—people who help the business run but whose work isn’t directly billable. Some examples are operations, sales, and administrative staff. Like office space or utilities, these positions tend to support some number of billable staff. This means that the more billable staff you can employ (hire and have work for) without increasing your support staff and other overhead, the more profit the business will be able to generate.

    Though profitability tends to come in overhead-related tiers, the general rule is: the more billable staff you can employ, the more money your business can bring in. The real trick here being that those staff need to be doing billable work all the time. Which introduces a chicken and egg situation: if you hire staff and don’t have the work to justify them, you’re losing money. If you have to turn down the work you want to do because you don’t have the people to do it… that’s no fun either. And possibly worst of all is the option of taking on more work than you can reasonably handle, which will certainly get you into trouble sooner or later.

    I’ve found that growth tends to be a balance between business development and hiring. When we’re in growth mode at Bearded, we tend to try to ride at the edge of the maximum amount of work we can do while actively looking for new hires. For instance, if our ideal workload is 3 full time projects, then we’ll shoot for 3 1/2 projects worth of work for a little while. That tends to be a nice stress test, giving us a good sense of which skill sets are overworked at that scale. When the right person comes along, we hire them. We might be a little suboptimal for a while in terms of workload and stress, but eventually we’ll add appropriate staff and settle in to our new ideal workload (maybe 3½ or 4 full time projects), and start the same cycle again when we’re ready.

    Todd Parker and Patty Toland at Filament Group look at it this way:

    Even though our growth has been minuscule and snail-paced, we have always and only grown when we’ve found a potential team member who is so incredible we just have to work with them. Jim Collins was right in Good to Great when he said having the right people on the bus is the most essential decision and everything else follows (or doesn’t). Our growth decisions are always built around people.

    Sounds a lot like my experience. If you find just the right person to hire, it’s usually worth taking the hit on overhead until you can drum up more business. Good people are hard to find, and finding good people is one of the key ingredients to doing better work (and making more money).

    Growing pains

    So growing can be good. But growing a business is not without challenges.

    Lullabot’s Jeff Robbins has some interesting thoughts on the pains of scaling:

    I’ve got a theory that company growth inflection points happen at the powers of 2. Going from 1 person to 2 is a challenge. At the point where you have 4 people, the company is getting serious. When you’ve got 8 people, you begin to feel the responsibility. At 16 people, you’re legitimate—and there’s no going back. The 16 to 32 person stretch is also where you need to start thinking about management structures. At 32 people, you start to think about the needs of the company rather than just the individual people. Your trees have become a forest. You start thinking about things like “systems” and “process.” We’re on our way to 64 people. This is where people start losing track of each other. They don’t feel like they “know” everyone at the company and they don’t speak up and contribute as often because they assume that they can’t make an impact at a company of this size.

    From Jeff’s experience, there are always challenges and opportunities at any size. Each situation must be solved for to progress to the next. Growth, in other words, isn’t all tripping through the daisies.

    More people, more problems

    Ben Callahan notes that “the weight of a larger payroll is something that makes a larger size more stressful.”

    And it’s not just the weight of the larger payroll, but also of the increased infrastructure. Todd Parker and Patty Toland explain:

    Working within a larger organization always felt fraught with pipeline discussions: having a bench of idle people was stressful, and managing schedules when deadlines inevitably moved out was equally hard. Even with some incredible project managers, it was a balancing act that frequently required compromising (quality of work, ethics of clients, respect for employees’ personal lives and schedules) that wasn’t always comfortable.

    Todd and Patty make a great point about the compromises that inevitably come about when you have a big payroll. I once spoke with a former partner of an agency that had ~$1M monthly overhead. At some point she had to choose between taking work from an apparel company in the midst of a sweatshop scandal, or laying off staff. She chose to work with the apparel company and keep her staff employed, but it wasn’t long before she exited the company because of this kind of ethical conflict.

    Sparkbox’s Ben Callahan adds that larger organizations’ agility can sometimes suffer in other ways, as well:

    Smaller teams also require a little less process—having everyone in the same room can unintentionally assist in your organization’s communication. And, there’s something freeing about being small—[at Sparkbox] we try to retain all the benefits of being small, but it’s never quite the same.

    So it sounds like that increased infrastructure—that same thing that gets you all those extra resources that people like—can potentially become a liability. Coordinating all those people is difficult, and takes a significant amount of time away from other tasks.

    Regardless, Jeff Robbins has found that at Lullabot they’ve always been able to overcome the challenges that arise:

    I see growth as a creative endeavor. It’s problem solving. We used to say things like “if we grow any larger than this, the company isn’t going to be as good.” But we kept asking ourselves “why do we believe this?” And eventually we’d come up with creative solutions which would allow us to grow without losing the things we loved about the company. The growth brought with it more creative possibilities and capabilities.

    For Jeff, growth’s problems can be overcome. But some others don’t see much in the way of benefit for larger organizations. Brad Frost doesn’t agree that larger teams are better at bigger work:

    I can’t even say that a larger scale of work can only be accomplished by a larger team, as I’ve seen time and time again that small teams can do amazingly complex work given the time and autonomy to do so.

    And I’ll be damned if that isn’t a nice segue into the benefits of smaller teams!

    Let’s get small

    Not everyone wants to work at a large business. In fact, lots of folks seem to depart from large businesses with the goal of working somewhere smaller, or even on their own. Someone who’s left the larger agency world to go out on his own is G. Jason Head:

    In a larger agency setting there are a lot of titles and seniority levels that need to be addressed. Sometimes, it’s completely valid, but a lot of times it’s also stroking people’s egos. It’s just sort of the reality of agency life.

    I like not having half of my day being eaten up by meetings. I like being able to really focus myself on my development work. My concentration is so much better [since going solo], and I honestly think I am doing some of my best work.

    Brad Frost has of late done some rather high profile work as part of small ad-hoc teams, and he thinks the benefits are overwhelming:

    I absolutely love the momentum that comes with working with a small group of smart, autonomous people. You’re able to collaborate easier, solve problems faster, and get things done without the layers of bullshit that inevitably come from gargantuan teams.

    You can go your own way

    If you get small enough, you become the owner by default. And it seems like there’s a certain amount of overlap between those who want to work smaller and those who want to be in charge of their own destiny. Todd Parker and Patty Toland of Filament Group have something to say about this:

    I think the biggest advantage of being small is the ability to say “Yes” and, more importantly, “No” to the opportunities that pass our desk, and having more control over scope, schedules and terms of working relationships we commit to. With our small team, we can only take on a certain number of projects at a time, so we try to be careful to make sure they’re going to be the best use of our time, that we are the best fit with the most appropriate skills to deliver value for our clients, and that we take on the most interesting opportunities to learn, build our skill sets and promote ideas we think are important.

    Weighing those sorts of decisions, choosing whether or not to compromise, is something you don’t generally get to do when you’re not holding the reins. I remember someone talking to me about this issue a number of years ago when we were even smaller, and my response then was that because Bearded was small and had a low overhead, it was easier to turn down problematic-looking work.

    That is in some ways true, but I don’t think it’s just the amount of your overhead that ties you down. Similar to the difference between revenue and profit margin is the cost of your overhead as compared to your overall potential project revenue. If you have a $1M monthly overhead, but you have, on average, $2M worth of plausible work that wants to sign every month, then you’re in a pretty safe position as far as picking your projects goes. But if you grow to meet your average potential work, then you don’t get to be so choosy. You have to take every project that shows up at your door, like it or not.

    What shall we do?

    So what’s better, big or small? Owner or employee? Only you can answer that question. In reality, there are as many variations for a business as there are people to start them.

    The question to ask yourself is: what do you most want to get out of your work? If you like having access to a variety of skills and extensive resources, then you might need to get bigger.  If agility or a lack of bureaucracy is what you’re after, then perhaps smaller teams are a better fit. If you’re at a point where you’re looking to make more money, then it may be time to grow bigger. But if being choosy about clients and projects sounds compelling, maybe a smaller crew with less overhead is what you need.

    Now it’s likely that most people care about all of those things to some degree. But what’s most important to you? It’s almost assured that you spend as much time working as you do anything else. And no one can ever pay you enough to hate that time—your time on earth. So make sure that, whatever your choices, they help create an environment that makes those days more satisfying.

  • This week's sponsor: MailChimp Pro 

    Get more from your newsletters with comparative reports and multivariate testing from sponsor MailChimp Pro.

  • Antoine Lefeuvre on The Web, Worldwide: Singapore, a Hub for Designers? 

    One of this column’s objectives is to take you traveling. Our destination today is the city-state of Singapore. During my voyages, I kept coming back to this small Asian nation, because Singapore is a hub for world travelers. But is it a hub for designers too? Here’s the answer from three Singapore designers—two expats and one local.

    The Lion City

    I first traveled to Singapore in 2010, my mind full of stereotypes: I expected to find a postage stamp-sized country—think Vatican—so aseptic that even chewing gum is illegal. But I quickly realized how wrong I was. Singapore is actually a 30-mile-wide island blessed with lush vegetation and home to a thriving city of 5 million inhabitants. Only 60 percent are Singaporean citizens, including Amalina Zakaria, a web designer “born and raised in Singapore” who represented her country at WorldSkills 2009.

    The Lion City—Singapura in Malay—is also a hotspot for expatriates. Game designer Antoine Henry left the banks of the Seine for the shores of Malacca Strait in August 2014. In the growing expat community he met Perrine Lefeuvre, a creative director who has been working in Singapore since 2012 for luxury brands such as Guerlain and Dom Pérignon.

    One of the notions I had about the city turned out to be true. Singapore is “Asia for dummies”—an easy city for first-time travelers to Asia: orderly, English-speaking, clean, well-connected. Easy doesn’t mean boring, though. The whole of Asia meets in the city-state.

    View of traditional and modern architecture in Singapore.

    A unique blend

    “The cultural diversity here is one of my main sources of wonder. For a European like me, it is amazing to find yourself at the crossroads of Asian cultures like Chinese, Indian, Malay, and the whole diversity of South-East Asia in general,” says Antoine Henry. Perrine Lefeuvre also finds that the city-state is an exciting place to be a designer. “If you have experience, you will have access here to projects you will never work on in Europe.”

    Even for those who are not new to this melting pot, like Amalina Zakaria, the diversity is mind-opening. “The different styles of each culture and how it is fused and integrated into modern design has always been an inspiration for me as a designer.”

    With 75 percent of Singaporeans being ethnic Chinese, you might be tempted to imagine the Lion City as a microcosm of China, a tropical Hong Kong. “Don’t,” reply my three interlocutors as one. “Despite our large Chinese population,” says Amalina Zakaria, “we are ultimately a Singaporean audience, rather than a Chinese, Malay, or Indian audience.” Perrine Lefeuvre adds, “Singapore only feels like China during Chinese New Year, when everything is gold and red—the traditional colors.” She even believes there’s a Singaporean style of design: “Very preppy, gentle, clean—and a bit hipster.”

    The right environment for creatives?

    Many web, game, and design companies have chosen the city-state for their Asian headquarters, Perrine Lefeuvre told me. And startups are following suit. “With a growing entrepreneurial spirit among locals, this creates opportunities for creative professionals to work with startups on exciting new projects. There is a lot of financial support and backing in the form of grants if creative professionals want to start something,” says Amalina Zakaria. “Singapore is a booming industry for creatives,” she adds.

    Singapore, a paradise for startups and web companies? Although Amalina Zakaria has found bureaucratic procedures stifling, Harvard Business Review calls Singapore “one of the easiest countries in the world in which to do business.”

    But when it comes to recruiting creatives, most of the expats I met told me the process of fostering creative thinking needs more time. A tradition of putting the group in front of the individual has historically made local workers less comfortable displaying initiative and creativity. “After a few frustrating experiences, I had to hire a designer from the Philippines because I couldn’t find one from Singapore,” explains Perrine Lefeuvre. Antoine Henry, who leads a team of designers, also experienced the culture gap. “I was used to challenge and be challenged quite openly regardless of who’s managing who. This is happening a lot less here, and I had to change my work process to actively seek that kind of honest feedback.”

    A genuine world city

    Listening to Antoine Henry, I have the feeling Singapore is actually Asia’s biggest Western city. “From my colleagues’ gaming habits and the test sessions we conduct with Singaporeans, I tend to think that their video games consumption is closer to Western than Chinese.”

    Singaporeans are “exposed to a lot of influences from the West right from the start,” explains Amalina Zakaria. “We may be struggling to inject more Eastern influences into our work!” she adds. Which means designers choosing the city-state for a deep dive into Asian cultures might be in for a disappointment. “It doesn’t have the hints of Asian tradition that you find elsewhere in South-East Asia, nor the eccentricity found in South Korea or Japan,” acknowledges Antoine Henry.

    But Singapore is actively shaping its own culture. This could well be its best argument to attract foreign clients as well as creative workers. As Amalina Zakaria says, “designers in Singapore are so well-versed in Western media, culture and customs, that we’re able to communicate effectively with our global clients.”

    Because it concentrates so much diversity, Singapore has always struck me as an “East meets West” kind of place. “It’s a more complex situation than just ‘East meets West’,” retorts Amalina Zakaria. “We do not have a long history that is unique to ourselves,” she says. “However, we are globally exposed with a lot of influences coming from outside, rather than inside—and that’s what makes us globally competitive.”

  • From Pages to Patterns: An Exercise for Everyone 

    Language defines the life of components. A “blue button” will work until the button is no longer blue—and then the name won’t make sense anymore. The pattern will have no reason to exist if blue buttons have fallen out of use. A component with the name “button,” however, will live a longer and more fruitful life, even if its properties change. Why? Because its name describes its function, not how it looks.

    As many of us know only too well, naming is difficult—but it’s the key to building a robust system. And it involves leaving some entrenched ways of thinking behind.

    Thinking in pages (still)

    Even when the final deliverable is a pattern library, clients often still expect to sign off on page designs. As pages make their way through various teams and managers for approval, they are, of course, discussed; before you know it, they turn into Home page, Listing page, Product page, and so on. Everyone is thinking in terms of pages, so it can seem natural for component design and page design to occur in tandem. But building components from page designs is like starting from the outside and working in—and that can get complicated.

    At Clearleft, the challenge of simultaneously developing pages and components became particularly evident in some of our recent projects, where instead of delivering completed pattern libraries to our clients, we were asked to collaborate with in-house teams of designers and developers to help them build and maintain their own. In one instance, as an exercise, we spent a few weeks focusing on UX and UI with a team before we asked them to name and code components from the designs. We were working from a product page design with product-related content in each component. The first component we built looked like a card, so everyone called it “product card.” We continued the exercise for different components, with similar results.

    Now, it’s great that people came up with unanimous suggestions—but do you see a problem with this naming structure? What if the component moves to another page or gets populated with different content? You could also think of the product card as a “profile card” or a “location card.” It might be reused for a range of different purposes. The name “card” would be simpler and far more versatile.

    From pages to patterns

    To help others adopt pattern thinking, we came up with an exercise for everyone involved in the pattern library. This isn’t just for developers and designers—anybody who has a decision to make in the creation of the pattern library should join in. The goal is to get everyone thinking about patterns at a granular level, removing any context around each component. It also encourages a shared vocabulary.

    All you need are some visual designs of pages or components (these can be anything from a first draft to final designs) and the following:

    • a printer
    • paper
    • scissors
    • Post-it notes

    Here’s how you do it:

    Part one: paper and scissors

    • Print the page designs and share them among the team so that everyone has components to cut up.
    • In a group or individually, cut up each page into its smallest elements and mix them up so you don’t know which page they came from.
    • Group similar elements like buttons, icons, form fields, etc. and remove any duplicates.

    Duplicates are multiple instances of the exact same element with the exact same design. You can safely remove them; you only need to note one instance of each element. However, if you end up with several instances that have slight variations among them, you might want to review your designs and streamline them to ensure that you create a consistent and cohesive experience.

    Brad Frost uses a technique called an interface inventory to analyze the interface components of a website. Instead of cutting up paper, he uses screenshots and gathers them in a spreadsheet. When he did an inventory of his bank’s website, he found that the button designs were quite inconsistent. Using his technique helped uncover the need for a design review.

    An example of the first part of the exercise: interface elements printed on paper, cut up into components, and categorized.
    My version of the pages-to-patterns exercise. I’ve grouped together form fields, tables, buttons, icons, font families, font sizes, and even website colors.

    Part two: naming components

    Generating ideas for component names as a team is a fantastic way to start developing a shared vocabulary.

    • Pick a component.
    • Everyone take a Post-it note and write down a name for that component.
    • Keep the names a secret until everyone has finished. Think about the function the component will carry out and avoid any references to its appearance. Asking why a designer made something look the way it does can help identify its function or purpose. Does the name still make sense if the component is moved to a completely different place from where you might be imagining it?
    • Once everyone has thought of a name, reveal each Post-it note. Compare and discuss. Names that appear multiple times are good candidates because they indicate a shared vocabulary forming.
    • Repeat this with each component.

    In my experience, this part of the exercise has sparked some productive discussions around naming, surfacing class names that bear some relevance for the company and for naming methodologies in CSS. Naming things shouldn’t just be left to developers. Getting everybody involved makes the challenging tasks of naming things a little easier and encourages the team to continue using the same terminology after the exercise is done.

    If the project is in its early stages and the designs are likely to change significantly, it may not be necessary to do this part of the exercise. On the other hand, there is a lot of value in getting used to naming components and starting to form a shared vocabulary early—even if that vocabulary evolves throughout the project.

    Three larger components labeled with suggested names on Post-it notes.
    Some suggestions for naming components.

    Part 3: code

    There’s a final step to this exercise for those who feel comfortable with coding. If you’ve started discussing CSS methodologies, this is a great time to try them out. At this point, you can play with as many variations as you like; if you decide that a particular methodology or term doesn’t work for you, you can drop it without investing any code in the actual pattern library.

    • Everyone grab a component.
    • Code it up in HTML and CSS. Set a time limit and resist the temptation to perfect things. It’s fine to throw away the code if the designs change.
    • Compare and discuss your code.
    • Repeat.

    Repeat, repeat, repeat

    This whole exercise can be repeated again to identify larger components. Some of these will contain elements identified in the first round of the exercise. You can check that they make sense and can stand alone within their new context.

    Image showing Post-it notes with some suggestions for naming components.
    Part one of the pages-to-patterns exercise repeated with larger components.

    One of the great things about this exercise is that it can be valuable at different stages of a project. Perhaps groups with differing skill sets, including people who aren’t developers or designers, want to start thinking in patterns. If that’s the case, just use initial drafts or whatever version you happen to be on. It doesn’t matter if the designs change, because the focus is on a new way of thinking—not on how the patterns look. At this stage, the names chosen in the second part of the exercise are apt to be temporary—but since naming is invariably challenging anyway, why not use this mutability as an opportunity to start building the foundations of your shared vocabulary by trying out various names in the context of the project?

    Or perhaps you’re further on in the project and the design is pretty solid, so you want to start grouping and naming patterns. Again, use the latest designs for the exercise. The beauty of paper prototyping is its low cost of change; you can throw it away and repeat it as many times as you like. Natalie Downe used to carry out a similar exercise when she worked at Clearleft. She used pens and paper to prototype components, demonstrating their functionality and size. This enabled her to see how they might work and fit together before investing any time in code.

    What happens next?

    That’s down to you. It depends on what you hope to gain from the exercise. Personally, I find it useful to put the components and their names onto a large piece of paper and then stick it up on a wall for everyone to see. As designs change, the components can be reprinted, discussed, and replaced. Keeping things visible serves as a reminder of the components, and will provoke discussions as the project progresses. Or if the team can’t work in the same building, you can keep a record online. Dan Mall has talked about using a Google Sheet as a central repository of components so that everyone in the team can access and discuss them asynchronously.

    The aim of the exercise I’ve described here is to involve everybody in the pattern library creation team. Alla Kholmatova takes it even further and involves users of the website. She tests paper components with them to get their feedback as early in the process as possible.

    Here, participants can pick up, move around, discuss, and scribble on the cards, actively becoming part of the design process. This gives us a chance to test our language choices and make sure that the functions we’ve defined make sense to our users.
    Alla Kholmatova

    Similarly, Heydon Pickering uses paper, pens, Blu-Tack, scissors, and tape to prototype interfaces for users to play around with at Neontribe. This way, he can quickly validate ideas with users without spending time on the fidelity of prototypes. Sometimes he tears up the prototypes and leaves with little more than he started with, but at least he can quickly move on to new ideas.

    Developing components

    The card example illustrates a common component and it highlights the need for a naming scheme. In this case, the class .card acts as a blueprint of styles for each card component, where variations can be created. This is how the markup for a whole card component might look using BEM syntax:

    <div class="card">
        <a class="card__link" href="">
            <h3 class="card__title">Hello</h3>
            <img class="card__hero" src="images/image.png" alt="Card image">
            <p class="card__description">Some text content</p>

    A variation—a product, say—can be created by modifying the card component like so:

    <div class="card card--product">
        <a class="card__link" href="">
            <h3 class="card__title">Hello</h3>
            <img class="card__hero" src="images/image.png" alt="Card image">
            <p class="card__description">Some text content</p>

    Some significant changes in web development, notably modular approaches to CSS and naming conventions, have occurred in recent years. Naming conventions are a major part of what methodologies like SMACSS, BEM, and OOCSS provide. All of these help address the same challenge: naming things clearly and consistently.

    Resist the temptation to dive straight into code. There’s a lot to be gained from getting away from our screens and focusing first on thinking, language, and approach. It might seem like a lot of trouble and time, but it can reduce the chances of discovering that you need to course-correct later on.

    The key benefits of this exercise are that it creates the same starting point for everyone, and encourages a shared language and pattern thinking across the team—all of which help lay the foundations of an effective pattern library. I’ve started using this exercise to kick off every pattern library project I work on; I only wish I had discovered it sooner. After all, who doesn’t love messing around with paper and scissors?

  • How We Hold Our Gadgets 

    A note from the editors: We’re pleased to share an excerpt from Chapter 1 of Josh Clark's new book, Designing for Touch, available now from A Book Apart.

    Where do hands and fingers fall on the device? This question is the linchpin for every form factor this book examines, and the answer tells you how to design your layout for comfort and efficiency. Since we hold phones, phablets, tablets, and laptops very differently, it’s no surprise that each of these touchscreen variations has its own UI needs.

    Yet these devices also share many consistencies, especially in the crucial role of thumbs. Whether we’re tapping away at tiny phones or jumbo tablets, our thumbs do most of the walking. That fact helps us establish sturdy cross-device guidelines. This chapter looks at why the thumb is so important, and reveals fundamental “rules of thumb” based on how we grab screens of all sizes.

    The smartphone is of course the device that we hold most. We stare at it for more than 20% of our waking hours, consulting it 221 times per day on average. Let’s start with that most familiar of gadgets.

    Hold the phone

    In 2013, researcher Steven Hoober took to the streets to observe over 1,300 people tapping away at their phones. He found that in nearly every case, they held their phones in one of three basic grips. At 49%, the one-handed grip was most popular; 36% cradled the phone in one hand and jabbed with the finger or thumb of the other; and the remaining 15% adopted the two-handed BlackBerry-prayer posture, tapping away with both thumbs.

    Drawings showing three different ways of holding smartphones.

    Smartphone use is defined by three basic handholds, and we often shift among them.

    The study also confirmed what many of us know from our own phone habits: we change grips frequently, depending on convenience and context. We switch between one hand and two, or swap between left and right; sometimes we tap absent-mindedly while doing something else; and other times we stop and give the screen our full attention. Plus: we are nimbly ambidextrous. Hoober found that two-thirds of one-handed grips are in the right hand—a majority, but smaller than the 90% who are right handed. That means many of us favor our non-dominant hand, while using the other to write, drink coffee, hold a baby, or read a book about designing for touch.

    So while few of us stick with the same grip, we show a distinct preference for one-handed use. And this is where we get to thumbs. When we hold our phones with one hand, the thumb is the only finger comfortably available for tapping. Even when we use both hands, many of us prefer mashing away with our thumb then, too. Of those who cradle their phone in one hand and tap with the other, Hoober discovered that most use their thumb on the screen. Combine all those folks, and it’s thumbs up: thumbs drive 75% of all phone interactions.

    Drawings showing that the most common smartphone grips are thumb-driven.

    Though we often refer to “finger-friendly” designs, the thumb does most of the work.

    The phone’s thumb zone

    While a thumb can sweep most of the screen on all but the most oversized phones, only a third of the screen is truly effortless territory: at the bottom, on the side opposite the thumb. For example, if you hold a phone in the right hand, your thumb falls naturally in an arc at the bottom left corner of the screen—no stretching your thumb or shifting the phone required. The same arc shape applies to the two-handed cradle grip, but the arc is larger because the thumb has greater range of motion.

    Comfort and accuracy don’t perfectly align, however. Within this comfort zone, a separate, fan-shaped arc draws out the most accurate targets for thumb tapping, as uncovered in a study by Qian Fei of Alibaba (subscription required). She also found that, for right-handed users, the bottom and top-right corners were the least accurate thumb zones.

    Zones showing the easiest access points for thumbs on a smartphone screen.

    The green thumb zone is the most comfortable and accurate region of phone screens for one-handed users. Avoid the red-zone reach, or at least compensate with larger-than-usual touch targets.

    What about lefties? The thumb zone flips from left to right. But this left-versus-right distinction isn’t especially crucial, since most of us switch hands easily (and frequently) depending on context. Even so, optimizing for one hand penalizes the other: the best solutions put core features at screen middle, where left and right thumb zones overlap. In the end, top versus bottom is more important than left versus right. No matter which hand you use, screen bottom is most comfortable, while the top demands a stretch. That rule holds true for all phone screens, large or small, but as phones grow to jumbo dimensions, that top-screen stretch becomes a strain.

    The phabulous phablet

    The first generation of post-iPhone devices consistently featured screens under four inches (as measured across the diagonal), an easy size for one-handed use. By mid-2014, however, a third of mobile web-browsing took place on larger screens as bigger phones shouldered into the marketplace. These super-sized devices fill the spectrum between phone and tablet, a category with the dubious nickname phablet, with screens as large as seven inches. My, how our phones have grown up. And down. And sideways.

    Photograph showing three people operating phablets.

    Samsung’s 7” Galaxy W and similar jumbo devices blur the line between phone and tablet. Photograph courtesy Samsung.

    Despite phablets’ gargantuan proportions, people typically handle them like phones, and the three basic grips still apply. Unlike with smaller phones, however, phablet users switch among grips much more often to work the entire screen, and two hands are almost always required. In another study, Hoober and Patti Shank observed that phablet owners use both hands 70% of the time across holds (subscription required). The most popular of these grips, used 35% of the time, is holding a phablet in one hand while tapping with the index finger of the other. But the thumb remains the pointer in charge: 60% of the time, phablet owners tap away with either one thumb or both.

    Drawings showing different phablet grips.

    Although none of the thumb-driven grips are as common as tapping a phablet with the index finger, they cumulatively account for much more activity.

    The phablet’s thumb zone

    With so much thumb use, the thumb zone is as important for 4”–7” screens as for smaller ones—with a caveat. Phablet folk use two thumbs more often, which creates a pair of mirrored, overlapping thumb zones at the screen’s bottom, with a swath of tough-to-reach space at the top. Despite its popularity, the double-thumb zone isn’t the one to optimize. Although we hold phablets with one hand only 25% of the time, the single-thumb grip takes on disproportionate importance for designers, because it has the least range.

    This brings us to our first rule of thumb for all form factors: always accommodate the most constrained grip, so people can use your interface no matter how they choose to hold their device. On phablets, that means designers should target the single-thumb grip.

    Here’s a tricky surprise: the one-handed thumb zone is smaller for phablets than for phones. As phone size increases, the thumb zone remains roughly the same shape and position—anchored to screen bottom—until the size hits a tipping point, where the grip shifts to stabilize the phablet. In that handhold, most people slide their pinky finger under the phone to keep it in place, reducing the thumb’s range.

    Zones showing the easiest access points for thumbs on multiple screen sizes.

    The size and shape of the thumb zone shifts when the phone’s dimensions require support from the little finger.

    Even as swaths of the screen become unreachable by thumb alone, some thumb diehards stick with one-handed use, opting to “choke up” on the phone—sliding their hand higher to extend their thumb’s reach. On phablets, this grip gives people more thumb range overall than the traditional phone grip at screen bottom. We’ll look at the implications of this later in this chapter.

    Zones showing thumb access for higher grips on phablets.

    A higher one-handed grip on a phablet nets a bigger thumb zone, but the bottom half of the screen goes out of reach.

    Tablets: more screen means more handholds

    While phones and phablets stay true to three basic grips, there’s no such luck with tablets. More screen means more ways to hold, making things unpredictable. The rule of thumb still applies, but with a special headache: the thumb zone isn’t consistent even for individual devices; it varies depending on stance and posture.

    Standing, we typically use two hands to manage a large tablet like the iPad, holding it halfway up the sides for leverage (hold it too close to the bottom, and the thing keels over). Some wrap an arm around it like a clipboard and tap with the other hand. More likely, though, we’re sitting; Hoober and Shank found that 88% of tablet use happens while seated, compared to 19% of phone use. Sitting at a table, we tend to prop up a tablet with one hand at the lower third and, again, tap with the other. Leaning back on the couch, we tend to rest the thing on the belly or nestle it in a blanket, tapping away with one hand. On top of these shifts in grip, each stance also affects how far away we hold the device: we tend to hold tablets closest while standing, and farthest while reclining. Portrait versus landscape is a mixed bag too, with a 60–40 split in favor of a vertical, or portrait, orientation.

    As screens get bigger, they also get heavier, and we often lay them down altogether. Hoober and Shank observed that people put large tablets down in nearly two out of three sessions. We rest them flat on a surface (whether table or lap) 40% of the time and upright in a stand 22%. (Smaller 7”–8” tablets are far easier to handle, and 69% of small-tablet use is handheld.) Those surface and stand positions suggest we use large tablets more like traditional monitor screens—or, closer to keyboard-touchscreen hybrids, which we’ll get to in a moment—than handheld devices.

    The tablet’s thumb zone

    When we do lift up our tablets, they prove too big to be held and operated with one hand, so two hands come into play. Here again, thumbs play an all-important role. We tend to grab tablets at the sides, and while the specific location wanders up and down, thumbs settle at the middle to top third of the screen. This grip makes the neighboring sides and top corners most friendly to touch. On the flip side, the top and bottom edges of tablet screens are hostile zones, because of the necessary reach. The bottom is especially tough, since thumbs are rarely near the bottom—and sometimes that portion of the screen isn’t even visible. In the laziest and perhaps most common tablet posture—lying down—the bottom bezel disappears into blankets, sweaters, or soft bellies.

    Zones showing thumb access for a two-handed grip on a phablet screen.

    Because the tablet grip is typically at the side edges, the thumb zone changes completely from the phone’s.

    We also, of course, often reach into the middle of the screen; as screen size grows, our hands field ever more surface. However, unlike a mouse cursor, which sweeps effortlessly across a screen’s sprawl, our fingers are weighed down by this thing called an arm. This meat pointer goes all the way up to the shoulder, and hefting it around the screen demands effort. An interface shouldn’t be a physical workout: group frequent controls within easy reach of thumbs. Nobody ever broke a sweat twiddling their thumbs.

    Hybrids and laptops: slap a keyboard on it

    If scaling up the screen size has such a dramatic effect on how we hold a device, it should come as no surprise that adding a keyboard shakes things up even more. Our postures, along with our hands and arms, shift yet again to accommodate the keyboard. Until recently, it was rare to spot this hybrid touchscreen-keyboard combination in the wild. And then came Windows 8.

    In 2012, Windows introduced touch interaction to the desktop in a total overhaul of the world’s most-used operating system. In response, a new category of touch devices—touchscreen laptops and tablet-keyboard combos—flooded the consumer market, creating a new ergonomic environment…and fresh demands on designers.

    The wrinkle is that hybrids require us to move our hands between keyboard and touchscreen. Before this generation of hybrids arrived, many dinged the concept as ergonomically untenable: shuttling hands to and fro would be too much effort, resulting in a fatigue dubbed gorilla arm. It’s a criticism leveled at the science-fiction interfaces of Minority Report and Iron Man too: Who wants to work with their arms constantly in the air? “Touch surfaces don’t want to be vertical,” a dismissive Steve Jobs said in 2010. “It gives great demo, but after a short period of time you start to fatigue, and after an extended period of time, your arm wants to fall off.”

    Research suggests such worries were unnecessary. A study by Intel found that people quickly embrace touch in these new devices, opting for the touchscreen 77% of the time instead of the mouse or keyboard. Despite the availability and precision of the old-school cursor, people said the touchscreen felt more intimate and direct. Other studies have documented this emotional resonance. One reported that people attach more value to products they “touch” on a website versus click with a mouse. When touch is introduced, cold pixels somehow take on the warmth and emotional investment of physical objects. We’ll look at this idea more deeply when we poke at gestural interfaces in Chapter 4.

    Appeal aside, the touchscreen isn’t a complete mouse replacement, but rather a welcome addition to the mix—“like having a laptop with an extra gear,” one tester told Intel. With these hybrid devices, people move easily among touch, keyboard, mouse, and trackpad: whatever input seems most convenient. That’s a lot of back and forth, though, and you’d think that would only worsen the gorilla-arm problem. Why aren’t people’s arms going numb? Turns out people quickly figure out how to work the touchscreen without lifting their arms. A study by researcher John Whalen found that when we use touchscreen laptops, we rest our arms alongside the keyboard, keeping a loose grip at the bottom corners of the screen.

    The hybrid’s thumb zone

    This hands-on-the-corners posture defines the thumb zone for hybrids. Once again, placing touch targets within easy reach of the thumbs makes for easy tapping and, in this case, avoids the need to raise the arms.

    Zones showing thumb access on hybrid device screens & Zones showing index finger access on hybrid device screens.

    The hot zone for thumbs on hybrid devices settles into the bottom corners, nearly opposite the hot zone for the index finger.

    Not everyone adopts the bottom grip, though. Others (especially newcomers) go free-form, jabbing at the screen with their index finger as they roam the entire interface. For designers, this introduces a head-scratcher; the index finger’s hot zone is the reverse of the thumb zone. For index fingers, the center of the screen is easy to hit, and corners are troublesome.

    Optimizing for thumbs means a subpar experience for the index finger, and vice versa. One layout has to win, though, and as with every other touch device, studies give the thumb the edge. After a bit of experience with the device, hybrid users soon prefer thumb use for everything, keeping arms planted alongside to thwart gorilla arm.

    Photograph showing an example of thumb use in the middle of a hybrid device screen.
    Photograph showing an example of thumb use in the middle of a hybrid device screen.

    Expert users of touchscreen hybrids prefer heavy thumb use, even to reach deep into the screen. Photographs by Intel Free Press (top, bottom).

    And that’s the most striking consistency across the form factors we’ve reviewed: thumbs do the driving no matter how large the screen. The thumb offers the most convenient range of motion with the least possible effort. This physical ease is exactly what Bell Lab’s researchers—along with every industrial designer ever—had to take into account as they designed their interfaces. These ergonomic considerations will determine the layouts for your digital interfaces too. We’ll start with some general principles for all touch designs, then dive into guidelines for different devices.

  • This week's sponsor: MailChimp Pro 

    Send newsletters with multivariate testing, comparative reports, and compliance insights from our sponsor MailChimp Pro.

  • Using Roleplay to Prepare Design Managers 

    Every so often, a designer gets promoted. If you are lucky, they are someone you have personally trained and developed. Congratulations! You now have a newly-minted design manager on your team. As a new manager, their relationship with the team will most likely change. They are now in charge of delegating design tasks, performance reviews, and leading critique—all things that require a different set of verbal communication and leadership skills.

    As the design lead or director, it’s your job to get your manager up and running. If someone is being promoted to a leadership role on your team, I’d like to believe they have shown good instincts and leadership before. They are ready for the next step, but will need to practice within a structure for a while, with your guidance, as they acclimate to the new role. There will be quite a few situations where you cannot be there all the time to guide them, so instead of constantly playing catchup, you can use roleplays as a way to prepare them beforehand.

    So, what is the point of roleplay? Do we need to create characters and do some method acting? Nah. None of that. In this context, roleplay asks your design manager to be themselves and to practice language and behaviors. You can then critically analyze their performance together to help them improve as a manager.

    There are a few common situations when new design managers will be a bit out of their depth.

    • When they need to lead a design critique session. This may involve leading a team to a new solution, or pushing a designer to look more closely at a part of their work.
    • When they need to delegate design work. This is always a tough one. Lots of designers struggle with delegation, as they may be used to “doing it all myself” and have trouble giving up control of the details.
    • During performance reviews. Yearly reviews are common in larger, more structured companies, and hopefully you have something similar where you work.

    I’ll show you the way I usually conduct these role-play sessions, but keep in mind that you should choose methods that you are comfortable leading and that will support your teammate. Not everyone will need this level of support, especially if they have other management experience, but I am confident you’ll be sensitive to people’s skills and abilities.

    Plan ahead

    Always explain what you will be doing. Book time in your diary in advance, and clearly list out what the session will be about and what it will achieve. I often use some variation of the following email:

    As you transition more into a leadership role, it’s my job to help prepare you and ensure you have the tools you need to successfully lead your team. One of the ways we can do that is by practicing some of these common conversations that you will have with your team:

    • offering critique and feedback
    • delegating design work and assigning tasks

    I’ve booked 60 minutes in our calendars, and we will use the time to go over some common language, and then practice it together so you get more comfortable. If there are other conversations with your team that you would like to practice, let me know.

    These emails have the added benefit of being a template for the new manager to reuse when they do their own training sessions.


    I’ll use the example of delegating design work. New managers often struggle with delegation, because of the fear that team members will feel they are being bossy. It’s often a misguided fear, but can have a real effect on how they assign work.

    In the session, I start by setting the scenario:

    I’m the design manager. I have a large project that I want to assign to you. I’ll ask you to take the project on, give you instructions on what needs doing, and what the deadline is, if at all. You are the designer. Please just react naturally, there is no need to act like someone else.

    As I speak, take a mental note of what I say and the words I use. After we are done, we will quickly discuss what happened. Any questions?

    We then do the roleplay. I assign the large project, and they respond naturally. Afterward, I ask them to repeat back to me what language I used, and their impressions of it. This is an essential part. You are getting them to say, out loud, the types of language they will need for the next exercise.

    This step is a clear example of why you should almost never have two new managers present to each other. Not only will they be confused about what language to use, you risk reinforcing ineffective delegation techniques. Always model the language or management technique first, so they have a pattern to follow.


    So, I’ve have set the scenario, and we’ve practiced once, with myself in the lead. After reviewing, we need to switch roles and do it again. Even though I explained the process over email, I still set the scenario and give instructions once more. By repeating this before we practice, I reinforce effective management pattern.

    Ok. We are going to switch roles. Now you are the design manager and I’m the designer. You have have a large project that you want to assign to me. Ask me to take it on, give me instructions on what needs doing, and what the deadline is, if at all. Use the language we discussed just now, and what you heard me do the last time.

    After we are done, we will discuss how it went. Any questions?

    We then do the roleplay again. See how things build up over time? In language teaching, this process is called scaffolding; it allows people to internalize the routines and language they need.


    Just as you promised at the very beginning, now you can take a step back. Offer some praise, and offer some constructive feedback to your new design manager. Both are essential!

    Ask them to go over what they were comfortable with, what felt awkward coming out, where misunderstandings might arise, and other questions that force critical analysis of their language and actions. Now repeat the cycle! This repeated roleplay allows the design manager to build up a sort of muscle memory of the conversation, making it feel less stressful when they need to have it in the future.

    There will be times then the roleplay goes completely off the rails. Don’t be afraid to call a time-out, offer correct language or tips, and then ask them to repeat after you. It’s better to adjust in midstream than wait until the end, when you are really far away from your stated goals.

    OK, let’s pause for a second. Your instructions to the designer about a deadline were quite vague, you said, “if you could kinda…” and “maybe try…” and other imprecise phrases when giving them a due date. Let’s try that once more, but this time say, “I’d like you to deliver it by…” instead. How does that sound?

    Never think this is just an hour-long session that you book and get out of the way. Training requires that you revisit the conversation, see how your new design manager is getting along with it, and scheduling further practice and review as time goes on. These role-play sessions could even be every month, spread out over a six to eight month period, if that is what it takes to get your teammate comfortable.

    Roleplay is but one technique available as you develop your team, but it’s one that I have found successful both as a design manager and a teacher. New managers often have the right instincts and design skills to teach others, but they need a bit of help in learning how to pass those instincts and skills onward. Using roleplay makes them more confident in their actions and team interactions, and gives them accurate, practiced language to use whenever they need to.

  • Rachel Andrew on the Business of Web Dev: Offering Feedback 

    Over at Perch we develop the product based on customer feedback. Our method of ordering features is to add the things that will make the most difference to the most people. We gather feedback from our interactions with customers (primarily this happens in our support forums) and try to shape a feature from the specific requests that will meet a more general use case. As we help customers to implement their websites we discover areas where we could do things in a better way, uncover requirements that we had not thought of. In addition, we have a feature requests area of the forum. We find that, directly or indirectly, the next thing we should be adding rises to the top. That might be due to a change in the industry, or that we have started attracting a certain subset of customers.

    There is, however, a danger with this approach. In support, we typically hear from 25 percent of our active customers more than once. That leaves a lot of people whose ideas and needs may never be taken into account.

    Experienced developers using our product also find places where a new feature or a refinement would have been helpful to a recent project. Rather than logging a request, they route around it and find a different way of achieving the end result. Sometimes they explain that they didn’t want to bother us as it “wasn’t a big deal. ” With the requirement solved they didn’t need support, so the fact that a useful feature had been identified never made it back to us.

    In our own work, we try to use tools and services from other small companies. When we come up against something that a tool or service can’t do, our response is usually to build something on our side to route around the problem. Even as product owners ourselves we forget how valuable the feedback from other developers is. When we do remember to drop them a line with a feature request it is very well received. Sometimes we’ve had what we needed the very same day.

    Our own hesitancy about interacting with developers of the products we use reminds us of how many of our customers we never hear from. It encourages us to find ways to make contact with the people who don’t readily contact us, to find out how we can better serve their needs even if they are happy with the product currently.

    We try to make contact with the silent majority of our customers by a variety of means. We pose questions in our customer emails, directly contact specific groups of customers, run occasional surveys, and invite them onto beta programs for major revisions of the core product and addons. We’ve launched a Slack channel, and are seeing people show up to chat there who never turn up in our support forum. Nevertheless, we know that there are long term, committed customers who we simply never speak with.

    There are lessons here for all of us. If you are a product owner, be aware that the feedback you get may not be completely representative of your customers. Be prepared to dig a little deeper and find ways to contact and speak to the silent majority. If you do not do this, you run the risk of moving the product in a direction biased towards the minority.

    As for developers, next time you find yourself writing some code to route around an issue with a third party product or API, take the time to offer feedback to the product team. If you have had to write code to deal with an issue then you are in the perfect place to show a real use-case, something that we as product developers love to see. Never feel that you are bothering the product team with something you could solve yourself. We all want to make our products better, and we can only do that by having our attention brought to where the issues exist.

  • This week's sponsor: Acuity Scheduling 

    Spending more time scheduling than actually meeting with clients? Sponsor Acuity Scheduling is your website’s favorite way to schedule calls, appointments, and hangouts…without pulling your pixels out.

  • Object-Oriented UX 

    In June 2012, while working at CNN.com, I was tasked with designing the user experience of election night. The next five months of my life would be dedicated to that single night—but success to me had nothing to do with who won. I was concerned with findability, data visualization, a shape-shifting canvas, and how the hell mouse-over flyouts were going to work on an iPhone. For the first time in history, CNN.com was releasing a responsive experience. And, for the first time in history, I was going to design a responsive experience.

    The stakes were high. Election night is like Super Bowl Sunday for CNN.com. If well executed, it’s one of the highest revenue nights in a four-year cycle. To add to the pressure, we were on a tight timeline with a deadline that was not going to budge. November 6th or bust.

    Then I learned that the first development sprint kicked off in four days. Four days?! My project manager calmly told me, “Don’t worry. The devs only need one template for the first sprint. While they are building the first template, you can move on to the next.”

    Huh? How was I supposed to design a cog in a machine without first roughing out the design of the machine?

    Thinking myopically worked okay when we were designing in pages on fixed screen sizes; we could get away with quilting together pieces designed in silos. I was pretty clueless about responsive design, but I did know that we’d need a clean and simple system, not pages strung together. And as all engineers and designers know, the more moving parts in a system, the more opportunities for disaster.

    So during those first four days, I did not wireframe one disconnected template. Instead, I blocked out a holistic system made of reusable, interchangeable parts. Here’s what it looked like:

    Election night diagram
    The diagram of the proposed election night experience I first presented to the CNN.com team.

    I presented this diagram to a conference room of stakeholders who expected to review a single “finished” template. I demonstrated that I had reduced the number of components and templates compared to our 2008 design, and that the new system was simple enough to fit on one 8.5 × 11 sheet of paper! Thankfully, a critical mass of people in the room saw the value of what I presented: less stuff to build.

    The diagram I churned out in 2012 was far from perfect, mostly in that I was trying to do too much too soon. I jumped the gun on implementation, blocking out flyouts and bar graphs. I was still thinking desktop-first, worrying about positioning, as opposed to prioritization. I packed in a premature homepage, a cover sheet for the experience (which I would now design last). I took a stab at persistent top-level navigation, instead of focusing on the content modules first.

    Although imperfect, the spirit of the diagram, and the thinking behind it, hit a chord with me. It wasn’t a sitemap; it showed no hierarchy. It wasn’t a storyboard; it didn’t block out a task flow. Instead, this diagram mapped out a system of things. And it changed the way I do UX.

    Stripping away interaction, persistent navigation, homepage, and layout, here’s the diagram that I would have created then if I knew what I know now, showing a system of three objects: States, Races, and State-Race Results.

    An updated election night diagram
    How I’d present the election night experience if I were designing it today.

    It worked: our responsive election night turned out to be the Super Bowl Sunday CNN executives hoped for. But we did it by the skin of our teeth, working late nights and weekends to make sure the design performed on a myriad of devices. I’m not sure we could have pulled it off with a design any more complex.

    Today, I’ve evolved this trial-by-fire experience into a proven, structured object-based process. In this article, I will introduce object-oriented UX, share my process of object mapping, and help you start doing it yourself.

    Mobile first, content first, and objects first

    Always separate thinking about real-world things from the documents which describe those things. Resource before representation.
    Mike Atherton

    It took me about about a year to retrain myself to truly think mobile first, but today, I do so even when designing desktop-only software applications. To me, mobile first simply means forced prioritization. It means think about layout later. Start with a single column “design” (also known as a list), and force yourself to prioritize content and functionality with sequential ranking.

    This approach dovetails nicely with the concept of content first: “content-out design” as opposed to “canvas-in” design. You have to know what you’re saying before you can prioritize it.

    Sometimes, this means having real-deal copy first—particularly when you’re working on a site with a critical mass of evergreen or instructional copy that can be organized, prioritized, analyzed, and updated before design work begins.

    But if you are working on a site that is 99 percent instantiated objects (news articles, products, campaigns, donations), there’s no way to build a complete copy deck up front—or ever. Instead of prioritizing actual copy, I have to think in objects.

    That’s OOUX: putting object design before procedural action design, and thinking about a system through the lens of the real-world objects in a user’s mental model (products, tutorials, locations), not digital-world actions (search, filter, compare, check out). We determine the actions after first defining the objects, as opposed to the traditional actions-first process that jumps straight into flows, interactions, and features.

    OOUX is powerful

    Newsflash! This is how your backend engineers work. In the ’80s, the software engineering community began to transition from procedural languages to object-oriented languages, which have benefits like code reuse, data encapsulation, and easier software maintenance. Most programmers bring your designs to life using object-oriented languages like Java, Ruby, Python, C++ or C#.

    Engineers start their process by mapping out the objects that make up the problem domain—something UXers should be doing from day one. When they look at your wireframes or prototypes, they first reverse-engineer your design to parse out the objects. They think, “How will object X talk to object Y? Will object A be made up of lots of object Bs? Which attributes will each object have? Will this class of objects inherit from that class of objects?”

    On the web, we develop object-orientedly, but still design procedurally, focusing on drill-down hierarchy or linear task flows. But there’s another option. In his 1995 book, Designing Object Oriented User Interfaces, designer and engineer Dave Collins argues that basing both front-end and backend design on object-oriented principles “brings coherence to the software development process. Object-orientation reveals deep structural correspondences between the artifacts of analysis, design, and implementation.”

    Defining objects that mimic the mental model of your users provides a scaffolding for team communication. It gives you a shared language. On top of team cohesion, designing object-orientedly can also help you:

    • match your user’s mental model, improving their experience
    • ensure simplicity, reducing any accidental complexity due to extraneous design elements
    • grow and maintain your product: objects can be iterated on without affecting the rest of the system and new objects can be gracefully folded in (as opposed to tacking on features)
    • build better APIs with portable, independent objects
    • get SEO brownie points from structured content and valuable cross-linking

    Then, there’s my favorite justification: OOUX helps you bake in more-crucial-than-ever contextual navigation. In other words, it helps users get to content through content.

    Persistent navigation might be hidden, hamburgered out of sight when a user is on a small screen. But even on 17-inch monitor, the most beautiful pinned-to-the-top navigation might still get ignored. When a user visits a site for the first time, they often gravitate to the big shiny objects, using the navigation or search bar only as a backup plan. As Val Jencks neatly summed up, “We go to content on the page first. The top navigation is the fire escape.”

    If a user is reading a recipe, where might they want to go next? We should anticipate how they might want to explore based on the recipe they are reading, and not leave it up to them to peck through a hierarchical menu or come up with a search term. And we certainly should not leave them with a few “related recipes” and consider our work done. They might want to see all the recipes that the chef has posted. Or maybe they want to see more recipes that use swiss chard, pivoting by ingredient?

    If we are thinking object-orientedly, we will experiment with ways that each object might relate to other objects, looking beyond the obvious. Maybe chefs have favorite ingredients? In the object-oriented design below, a user can continually explore instances of these three objects (recipe, chef, ingredient) without ever hitting a dead end. The content is the navigation, and it’s all in context.

    An object model for a cooking site
    In this object model, recipes, chefs, and ingredients are interconnected, allowing continuous exploration.

    If this concept feels familiar, you’ve probably read about or practiced content modeling. In the past five years, many information architects (see Mike Atherton’s work) and content strategists (see Rachel Lovinger’s work) have started focusing on systems of reusable content types, and becoming more involved in the design of CMSes: the content creator, not just the end-user, is a primary user.

    In her book Content Everywhere, Sara Wachter-Boettcher encourages us to model our content before diving into wireframes and interaction design:

    Content modeling gives you systematic knowledge; it allows you to see what types of content you have, which elements they include, and how they operate in a standardized way.

    Unfortunately, the art of content modeling is still unfamiliar to many UX designers, who hear “content” and assume it doesn’t apply to them. This is especially true for UXers who deal with software as a service or product design: strategies involving content sometimes fall on deaf ears.

    Object mapping

    Object mapping, my process behind OOUX, is content modeling for designers who do not deal with content in the traditional sense, but still need to design systems—and not just systems of implementation. While a tight collection of reusable templates and modules is invaluable, those design patterns don’t hold meaning for a user unless they’re backed by a system of real-world objects that matches that user’s mental model. Focus first on designing the system of real-world objects, then on designing a system of implementation to bring it all to life. This is the linchpin of all my design work, because it transforms goals into an executable system that meets those goals.

    Get out your sticky notes, grab your team, and clear some wall space—I’d like to walk you through my process.

    Step 1: Extract objects from goals

    One of my favorite perks of object mapping is that it provides a perfect bridge from goals to design. Instead of haphazardly whiteboarding A Beautiful Mind-style, object mapping provides a neat framework to move from strategy to design. (Please continue to go all John Nash at the whiteboard, but create an object map first. It will give your wild creativity a solid foothold.)

    As an example, let’s say we are building an application to help home improvement brands connect to DIYers. After user interviews, a competitive analysis, and discussions with stakeholders, we have our brief:

    Give DIYers an outlet to post their home improvement challenges, soliciting potential solutions from product companies (brands). DIYers get expert solutions to their challenges and brands get exposure.

    • DIYers can search and browse existing challenges, commenting on the proposed solutions.
    • Brands can search and browse for open challenges that might be a good fit for one of their products.
    • Brands can create solutions that feature one or more of their products.
    • DIYers can close a challenge after a solution has been chosen, and later follow-up on how well the solution worked.
    • Brands can create a library of solutions that can be reused on various challenges.

    To extract the objects, we basically highlight the nouns.

    Image of the brief with nouns highlighted
    Highlighting the nouns in our project brief is the first step to mapping our objects.

    Recognizing nouns is first-grade simple, but extracting objects does require some subtle art:

    • We pay special attention to nouns that keep popping up, like challenge and solution. Those will be important objects.
    • We ignore the abstract noun exposure, as this describes a fluffy concept we hope will emerge from our system, not a tangible object that will be part of our system.
    • We ignore library because this is simply a collection of other objects (solutions). Watch out for words like calendar, catalog, or map. These are usually just fancy list-views of the core object: an event, product, or location, respectively. For example, most systems that deal with locations will have a single (perhaps filterable) map view. The map is a design mechanism, not an object itself.
    • We infer an object from two actions: “commenting on” and “following up.” Obviously, we will need some sort of comment object.
    • We note that a challenge object needs multiple states: posted, in progress, closed, and closed with feedback.

    From this 10- to 15-minute exercise, we have the main building blocks of our system. Let’s write each object on a blue sticky.

    Blue sticky notes
    We write each object on its own sticky note to visualize the building blocks of our system.

    Next, we need to define what the objects are made of.

    Step 2: Define core content of objects

    Content modeling requires you to simultaneously understand your goals at the highest level and get intimate with your content’s most minute attributes.
    —Sara Wachter-Boettcher, Content Everywhere

    Quite. We just determined the macro building blocks of our system, and now we must determine the most granular elements of each. This activity is often reserved for eleventh-hour detailed design, but defining elements while in the medium of sticky notes is liberating—when you start sketching a little later on, you can focus on more creative aspects. Also, having early conversations about what makes up each object can help you avoid moments late in the game where an important element is left off (or extraneous) and the change needs to be made across several design documents.

    Most importantly, you can have conversations with your team such as, “Should DIYers be able to add their budget onto a challenge?” before non-designers are looking at wireframes or layout. This helps keep conversations focused, rather than getting stuck on something like the icon for budget.

    At this point in the process, I separate two types of elements: core content and metadata. Core content, like text and images, goes on yellow stickies. Metadata—any data that a user might sort or filter on—I put on red stickies.

    Blue, yellow, and red sticky notes
    The granular elements of each of our objects are mapped out with additional sticky notes.

    If your team isn’t sure about a potential piece of content, write it down anyway and just add a question mark. Move on and return to it later.

    Step 3: Nest objects for cross-linking

    And now the system comes alive. Do a series of thought experiments for each object. Starting with one object, consider ways that each of the other objects can “nest” inside that given object. As you nest objects, you are defining the relationships between them, and, implicitly, the contextual navigation as well. Using blue stickies, experiment with how each object might nest its other sibling objects.

    The complete object model
    We finish out the model by adding sticky notes that show how other content objects can “nest” within each object.

    For example, here’s how that conversation might go for our challenge object:

    • DIYer: “Easy, the DIYer is the author of the challenge.”
    • Solution: “This is the main nested object of a challenge. We need to show all solutions posted to this challenge.”
    • Brand: “Eh, not really? Brand will be a part of the solution modules (as an author of the solution), but probably not directly nested into a challenge.”
    • Product: “Again, part of a solution, not directly nested. Huh. Unless DIYers can post the products they already have at home?”
    • Comment: “Hmmm. Probably relegated to solution…should we keep all commenting on the solution? Or should brands and DIYers perhaps be able to post questions directly to the challenge? We need to explore this more.”

    Note that not everything is figured out. Some items, like the commenting discussion, might be best resolved during sketching—but you will be intentionally exploring an identified design problem, as opposed to that problem catching you by surprise.

    Step 4: Forced ranking

    Ugh. This is the most diabolically difficult step. In the prior steps, it’s very important that you wrote each element and nested object on separate stickies. Why? Because now we need to reorder the elements, from most to least important.

    A prioritized object model
    Our object model, reordered based on how important each element is.

    This ordered list does not necessarily provide a direct representation of what will be at the top and the bottom of the screen. In design, priority might manifest in size or color. Low-priority content might be placed at the top of the screen, but in a collapsed panel (yay, progressive disclosure!). So reassure your team that we are simply prioritizing and not designing.

    While prioritizing, imagine which elements will be most important to your users. Which bits are must-have information and which are nice-to-have? When considering metadata, think about the most important sorting and filtering mechanisms. If the default sorting will be by “popularity,” then “number of DIYers who like this” will be high priority.

    A new foundation and framework

    Now you have an object-based system derived straight from goals. But keep in mind that while this activity provides a foundation for designing an implementation system, interactions, and persistent navigation, it doesn’t carve any decisions in stone. It’s a first draft! As you iterate, objects and elements will be introduced, eliminated, and reprioritized. Your object map provides a framework for continued conversation and collaboration: with your client, your design team, and your developers.

    OOUX is not a new end-to-end process; it’s a new ingredient to add to your current process. It adds clarity, simplicity, and cohesion—to how you design, and to the products you release into the world.

  • Choosing a CMS Your Organization Will Love 

    The internet doesn’t exactly lack for advice on how to pick a CMS platform. Go for the one with the most impressive feature set, advises one expert. Consider the costs of ownership, charges back another. Make sure it produces SEO-optimized pages, warns every SEO consultant everywhere. Unfortunately, picking the right CMS by consulting generic criteria is as effective as studying census data to improve your writing skills.

    Experts often readily admit the importance of considering organizational needs in the CMS selection process, but they’re rarely willing to talk about those needs specifically. Understanding the varied departmental interests, psychological trade-offs, and political realities of your organization, however, is key—your CMS selection criteria should emphasize factors that will directly impact the success of the people who will use it. In other words, stop worrying about having a CMS and start worrying about having a usable CMS.

    The curse of enterprise software

    A 2012 executive survey revealed that CMS projects are seven times more likely to fail because of internal politics and lack of cultural fit than from a lack of features. Anecdotal evidence further suggests that even projects that seem successful initially can quickly go off the rails if the CMS can’t accommodate how the organization works.

    As Jason Fried and Karen McGrane have famously pointed out, these problems stem from the fact that the people who buy enterprise software aren’t the people who use it. Changing the sales process isn’t enough to truly overcome this problem, however; one also has to understand who will be using the CMS and what their key needs are.

    Those users typically fall into three categories: developers customizing and running the software, editors producing actual content, and managers using online content to achieve specific business goals. To choose a CMS that can serve the organization, you need to understand how the CMS impacts their daily work and what challenges they have to contend with.

    Tools maketh the developer

    All developers know that no two CMSes are created equal. On one end of the spectrum, you will find publishing platforms that carefully separate application data, presentation, and business logic, making them easy to extend and customize. On the other (more crowded) end, you will bump into CMSes whose innards consist of spaghetti code—unnecessarily intricate and poorly structured. What hides under the hood of a CMS matters a great deal, because poorly architected code slows down, frustrates, and demoralizes even the most accomplished developers, turning any promising new initiative into an endless grind.

    Unfortunately, the difference between properly designed and haphazardly thrown-together software might be obvious in hindsight, but there is no way of telling them apart when you are still shopping. Businesses often hedge this risk by betting on CMS vendors boasting a big developer community. Indeed, a vibrant community addresses many of the shortcomings of a slapdash architecture: technical mysteries are solved with a quick googling session; there is a smorgasbord of themes, plugins, and extensions to supplement the standard functionality; and one never runs out of experienced technical contractors to recruit.

    But the rise of API-centric services and the new approaches to publishing they spawn—from headless CMS and content-as-a-service to mobile backends and static site generators—has added a new twist to the old story. Rather than requiring developers to slog through the quirks of internal architecture or master a hodgepodge of tools and frameworks, the new breed of CMSes hides the complexity behind an API layer. All a developer has to do to fetch the content is issue an API call, and, milliseconds later, a neatly formatted response is returned. As long as a developer is working in one of the popular programming languages, the costs of integrating content delivered this way are trivial.

    This means that technical stakeholders have to make a strategic architectural decision in addition to thinking about security, deployment, and performance. Traditional vendors offer complex software that takes months to master, but has a large developer community to turn to. New upstarts provide lightweight services with no programming overhead, but it will take years before they catch up in terms of social proof.

    Here are some questions to help weigh the pros and cons of these options:

    • How much specialization is required to master the CMS? Does the CMS expose data in a standard way? Is there a clear separation of concerns? How well-documented is the code? Is customizing the CMS supported by default? What developer tools are available?
    • How big is the developer community? Are there many technical contractors specializing in the product? How easy is it to troubleshoot bugs and find answers to technical questions? Is there a marketplace catering in extras?
    • Does the CMS ship with a native API? What type of data is accessible programmatically? How detailed and well-illustrated is API documentation? How difficult is it to customize API endpoints? How does the API perform against the benchmarks?

    The editor’s fear of manuals

    Developers usually find detailed software documentation a sign of quality. Busy editors take just the opposite view: the best publishing tools come free of manuals and are intuitive to use. Unfortunately, the generic interfaces they have to contend with today more often feel like a product of a violent database eruption rather than painstaking design. Some vendors have tried to address the problem by improving styles and layouts, adding descriptive labels, and tweaking interactions to take the friction out of using a CMS. But better interfaces alone won’t make a CMS intuitive—we need better authoring experiences (AX).

    Getting AX right requires that software developers design the CMS around the way editors and content authors perform their tasks—for example, preparing and uploading responsive images, identifying stale content in need of refreshing, customizing field labels, or updating help text. A good AX comes from actively and carefully designing for those everyday workflows, so that editorial teams can define their content model and customize the authoring interfaces without touching the code.

    This focus on AX dovetails with concerns about how to structure content inside the CMS. Traditional, page-centric tools store information in big blobs of data, where actual content is mixed with formatting styles and layout elements. Karen McGrane has illustrated the painful struggle to adopt such content to new mediums in all its gory details. The antidote to the majority of these problems is to disassemble undifferentiated content blobs into small, reusable chunks of data and keep this data strictly separate from the visual presentation.

    The organization of content has a dramatic impact on the productivity of the team, because it provides editors with very distinct tools. Page-centric CMSes allow authors to assume the role of a designer and tinker with how things look in a desktop browser. Structured-content CMSes help authors act like architects, assembling individual pieces to fit the constraints of a specific medium. Editorial teams obsessing over the look of their content would feel sabotaged without a WYSIWYG editor, while teams working in multiple mediums expect content to come in LEGO-like chunks. The real question is, which use case is critical for your business?

    When selecting a CMS, examine your use cases and editorial process, then consider these questions:

    • How customizable is the CMS? Can custom data types be defined without coding skills? What about UI? Can authoring experience be tailored to reflect the team’s workflows and culture? Can the CMS accommodate the needs of several user groups?
    • Does the CMS support high-fidelity presentation? Does the CMS include design templates? Can editors select layouts and style individual page elements? What preview options are there? Are assets auto-scaled for target viewports?
    • Does the CMS support structured content? Is content broken down into reusable chunks? Are inputs stored as specific data types? Are editors prevented from formatting and styling entries? Is it easy to define and maintain multiple content types?

    Helping managers see the big picture

    Managers are rarely mentioned in the context of CMS selection; when they are, it is usually to tell a cautionary tale about the dire consequences of listening to the HiPPO. This line of thinking tends to ignore very valid concerns that decision-makers like senior editors, marketing VPs, or product managers have.

    Managers orchestrate individual contributors to produce content serving an organization’s needs. It’s a tricky process that requires strong planning skills, lots of empathy, and attention to details. While a CMS is a poor substitute for empathy, it gets its chance to shine by helping busy managers see the big picture: what content is live, which pieces are scheduled for publishing, and who on the team has fallen behind. Contextual information also comes in handy when working with individual pieces, where the ability to visualize recent changes, enforce validations, and track down whoever deleted the cover image helps streamline internal discussions.

    Juggling roles and permissions is another source of managers’ anxiety, largely because access management is often the last item in a CMS vendor backlog. Organizational culture dictates very different needs in this area: managers charged with coordinating a constantly evolving network of contributors want a one-click approach to onboarding new contributors and waving goodbye to old ones. By contrast, those working with stable teams are more interested in capturing in-depth author info.

    The same goes for workflows: flat organizations can get by without elaborate checks and balances, while those in regulated industries might look for a way to enforce triple sign-off before new material hits the homepage. All this just goes to show that the goals a team pursues profoundly shape their expectations about how different parts of CMS will work. Even when CMS vendors reassure you that their tool comes packaged with roles and permissions, remember to investigate whether the way access control works really fits your needs or requires a computer wiz to operate it on a daily basis.

    • How can one keep tabs on CMS activity? How does one follow organizational activities? Are there notifications? If yes, how do they work? What filtering and reporting options are there? Is contextual information available under individual entries?
    • How are roles and permissions implemented? What default roles are available? What does it take to add custom roles? Can one review current access details? How easy is it to add/remove collaborators?
    • Does the CMS support specific workflows? Can the publishing process be automated? Does the CMS provide template workflows? How easy is it to add custom steps and values? Are there built-in notifications?

    The human bottleneck

    CMS projects succeed or fail largely due to human factors. The CMS plays a different day-to-day role in different departments, necessitating strategic trade-offs. Some trade-offs are interrelated: an API-powered CMS is easy to combine with cloud-based analytics and A/B testing services; focusing on AX makes it a breeze for managers to set up custom workflows. But it is just as likely that in some situations, your organization will find itself at a crossroads, with key stakeholders opting for competing CMS vendors. How does one handle these sensitive situations?

    In the past, a common way of resolving these differences of opinions was to defer to the IT department or gracefully accept the backroom deal engineered by the higher echelons of management. This approach incurs a lot of costs, with poor usability being the most obvious one.

    Instead, it’s best to approach this problem by looking at your production process. Think of the steps performed by your different teams: developers doing custom development and providing daily support; editors creating, updating, and maintaining content; and managers overseeing processes and measuring how published content impacts the business.

    Identify the weak links in the process, where risks abound and schedules get routinely delayed. These are your bottlenecks: they hold back organizational plans, drag down the bottom line, and put people under pressure.

    The bottleneck is a relative concept: it always depends on a configuration of individual factors in a given situation. For a newly established business, it’s often the size of the IT bill that determines limitations; for a university department, the constraints may come down to the available time and technical savvy of the faculty members; and in a media company with evergreen content, the biggest productivity jump might come from removing the obstacles in the way of the marketing team.

    Selecting a CMS with these obstacles in mind improves user productivity in a number of distinct ways—from eliminating mistakes and speeding up content creation to simplifying user onboarding and ensuring more enthusiastic reception. Helping the weakest teams unlock their potential goes far beyond eliminating the immediate bottlenecks—it also makes the entire organization more agile and resilient.

    Setting up for success

    For a long time, selecting a CMS platform was treated as a technical problem, to be solved by an IT department or a trusted technical advisor. Resist this view. As a tool that defines your online presence, imposes idiosyncratic editorial processes, and affects the productivity of your team, the choice of a CMS platform is too important to be decided on technical criteria or imposed by a single stakeholder.

    Approaching the CMS selection as an organizational problem, on the other hand, yields many benefits: selection criteria that flow from functional requirements, work patterns, and cultural expectations of future users ensure focus on the job-to-be-done, not features-to-be-shipped. Visualizing content creation as an organization-wide process helps avoid internal turf wars and prioritizes high-impact solutions.

    Start by identifying who in your organization will be impacted by the CMS: we talked about developers, editors, and managers, but the stakeholder list can include other roles too. Next, understand the big trade-offs involved: is the size of a developer community a deal-breaker? How should your content be structured? What is the role of managers? Working through these questions should help you articulate the needs and expectations of future users, which can then be translated into a checklist of technical requirements.

    Equipped with this knowledge, you can now reengineer the vendor selection to put the true needs of your organization at the center of all discussions. And once you do, adopting new software will no longer breed uncertainty, risk, and anxiety, but—on the contrary—help your organization become more agile, focused, and resilient. Just like those sales folks have always promised you.

  • Nishant Kothary on the Human Web: Groups of Five 

    Gavin Belson, CEO of the fictitious tech juggernaut Hooli, is gazing out the floor-to-ceiling windows of his office.

    Hordes of Hooli employees are migrating in groups across the fiber-optically rich pastures of its headquarters. Behind him stands his spiritual advisor: an Indian man, judging by his complexion and the kurta (but somewhat muddled by the collection of prayer beads around his neck). Arms crossed, brow furrowed in reflection, Belson observes, “It’s weeeeeeird. They always travel in groups of five, these programmers. There’s always a tall skinny white guy, short skinny Asian guy, fat guy… with a ponytail, some guy with crazy facial hair, and then… an east-Indian guy. It’s like they trade guys until they all have the right group.”

    Like so many scenes in HBO’s excellent show “Silicon Valley,” this one has cult-classic potential on par with several scenes from Office Space. Packed into these thirty seconds is a lifetime’s worth of truth.

    I write this acutely aware of the cliché that is writing about the life lessons that may be gleaned from [favorite_TV_show_or_really_anything]. But I’m also writing this as a software engineer wearing a hoodie and Warby Parker glasses, typing on a Mac from a small, fair trade, neighborhood coffee shop. When it comes to being a cliché, I have much bigger worries. So screw it, let’s indulge in cliché (because not indulging in cliché because it’s cliché is about as cliché as it can get OK I’ll stop now).

    Where was I? Ah, yes, the scene and its truths.

    First, there’s the environment itself: Belson’s expansive yet deliberately modest office, a hallmark of the modern, frugal, enlightened tech leader. In fact, thriftiness isn’t a signal reserved just for individuals; it’s for entire corporations too (which in legal terms are individuals, I guess). Take Amazon’s legendary door desks, for instance. I had one of these bad boys to my name from 2005 to 2007—adjusting the height required filing a maintenance ticket that brought a handyman to your door (desk) armed with a 4×4, a saw, and not much of a sense of humor.

    There is nothing particularly offensive about valuing thriftiness and correlating it to your ability to revolutionize industries, synergize economies, and materialize innovation. On the contrary, one could argue (in press releases that nobody reads, and Medium posts that a few people read so long as the reading time is three minutes or less) that it is a good thing. Except of course when it’s just cheap signaling, which more often than not, it is.

    Then there’s the uncomfortable juxtaposition of white guy with always-agreeable, non-white spiritual advisor guy standing behind white guy: a setup that masterfully draws out irony and discomfort. From the Beatles to Steve Jobs to the lady down the street that you can’t stand but “God, she’s so nice!” to even Zuckerberg, few things can warp your average spiritual person straight to self-actualized god-among-men like a visit to India.

    But the writing here works on more planes than the “brown men are props in a white male tech culture” narrative. Last year, Anil Dash wrote a persuasive piece about how Asian-American men are in a position of privilege in the tech industry, and often complicit in the oppression of other minorities. That’s the nuance the scene nails: brown guy looking over leader white guy’s shoulders, as they both look down at the common folk.

    The truthiest truth of this scene is the subject of the scene itself: Belson’s revelation that programmers sort themselves into groups of five by ethnicity, size, and facial hair. It’s hard not to sink a little deeper into your hoodie as you watch his revelation unfold. But it’s just as hard to put your finger on exactly what causes the discomfort.

    Is it the Indian guru looking on with admiration, as he was paid to do? Is it Belson’s sociopathic callousness as exemplified by, well, every superficial observation he made? Is it that the group of five doesn’t include “non-model” minorities? Or that it excludes women entirely? Or, is it Belson making clear that humans are just pattern-matching monkeys fooled into thinking they aren’t by the accident that is consciousness?
    Brace yourself for the cliché of clichés:  life is a game—a game of identifying and navigating patterns. Every once in awhile, I forget this. I drop my guard, and start going about my day with the earnestness of a puppy play-bowing to a grumpy 11-year-old cat who’s seen it all and frankly, has had enough. And as you’d expect, with the swoosh of a claw, the overweight ball of fur and hate delivers a cut so surgical that my yelp comes out before the bleeding starts. And then I faint (because,  as I learned all too well from the self-amputation finalé of 127 Hours or from simply walking around the hotel lobby during my last visit to India, things make me faint).

    But when I come around, I am the better for it. Because as much as I loathe all these ugly patterns—and loathe having to see them, and turn them, and bend them, and fit them all together, and take them apart, and repeat, so that I may be able to see the picture more clearly—by accepting that it is what it is, I am in a much better position to make it what it isn’t.

    Or even, what I want it to be.

    As Belson gapes out the window, the camera’s focus shifts past him to the face of his spiritual advisor, like a homunculus perched on his shoulder to echo his self-congratulation. For one split second, the advisor’s face flashes a micro-expression of disbelief that almost betrays his inner eye-roll.

    But then, with seasoned grace, it morphs into a picture of serenity. A knowing smile appears on his face, and without skipping a beat, he responds, “You clearly have a great understanding of humanity.”

  • This week's sponsor: Toptal 

    Looking for great freelance designers and developers to grow your team? Sponsor Toptal is here to help.

  • URLs Beyond the Web 

    With the newest versions of the two most popular mobile operating systems, iOS 9 and Android M, third-party native applications will be able to respond to URLs, rather than a web browser, enabling deep-linking into applications. Tapping a link to a tweet will open Twitter’s official application and display it there, if the application is installed, rather than navigating to the tweet in the default browser.

    This has some major implications for what we think of as “the web,” and how we build experiences for it. I don’t think “the web” consists only of websites. I see everything we build that is connected via the internet as “the web.” As John Gruber said:

    We shouldn’t think of “the web” as only what renders in web browsers. We should think of the web as anything transmitted using HTTP and HTTPS. Apps and websites are peers, not competitors.

    The things we build are—and should be—peers, but the shared language of the web, the URL, has not been fulfilling its “universal” promise. And yet, the universality of the web is what makes it one of the greatest technological achievements in human history.

    After championing progressive enhancement for so long, we know that not all experiences are the same—nor should they be. I see URL-enabled applications as the next level in the progressive enhancement approach: those with the associated app installed will be sent to the app, since we might reasonably assume that’s their preferred experience, those without the app installed (or without it available on their device altogether) will be sent to the website.

    I’ve talked before about not drawing such hard lines between experiences, and about letting operating systems handle the parts they can handle best. Application deep-linking is a great example of both. Another level has been opened up for our progressively-enhanced experiences, and it’s up to us to take advantage of that.

    Cool URIs don’t change.” Even cooler ones work everywhere.