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
  • The Couch Cone of Silence 

    This is Geek Mental Help Week. We’re participating because we want to make it safer for people in our industry to talk about mental health. Join in or follow along at @geekmentalhelp and #geekmentalhelp.

    About five years ago, I bought a cushy couch for my office. (Okay, yes, I did get the model that could flatten into an emergency nap station, but let’s just say that I plan for contingencies—it sounds more professional that way.) Our projects required a lot of office-to-office visiting to discuss situations in person, and eventually, said couch (and therefore, my office) became a veritable beacon, attracting anyone looking for an excuse to decompress. Such is the life of a one-couch, 50-chair business.

    Project chats could turn quickly into personal deep dives. I learned which to expect by the way people knocked on my door and asked if I was busy. The biggest tip-off was closing of the door as they came in.

    Most people just wanted someone to listen. I’d hear grumblings about managers and stress, and sometimes they’d ask for advice. But gradually, I sometimes also heard about anxiety, depression, emotional baggage, counseling, complicated diagnoses, and the merits of medications. Finding out what people were dealing with often left me with absolutely no idea what to say. I’m no therapist.

    How was I supposed to respond? Labeling something a “mental health issue” makes it feel amorphous and scary—unknown, subjective territory that’s best left to professionals. But mental health is not a Boolean value; it’s a spectrum we’re all on, and one that’s always fluctuating, though we may define those fluctuations with other names. Some conditions are temporary, some are precipitated by events, some are genetic, and some can be caused by medications taken for innocuous, unrelated reasons. We are complex adaptive systems affected by situations, and no one is on the forever side of “not mentally ill.” In light of that, there is nothing to hide or be ashamed of. No one should feel alone. When our friends and colleagues are struggling, we don’t have to be a professional to help them fight that fight.

    It’s very natural to just jump in, but it’s very, very important to first learn about what is going on under the surface and behind the scenes. Internal struggles aren’t easy to see, mental health-related or not. I have a couple of extroverted, life-of-the-party friends who battle major depression, and even overcompensate for it because they are expected to be “the fun ones.” It must be exhausting. Like many, many conditions, depression doesn’t affect everyone in the same way—it isn’t defined so simply as “noticeably sad and constantly crying.” The signs and symptoms vary because the condition (whether temporary or congenital) is just an overlay, a layer, a facet. It doesn’t define the person. In other words, “you’re still you.”

    Like my friends, people can do a great job at hiding the dark sides of their struggles. Maybe a coworker is 15-20 minutes late to work every day, but it’s a win for them to be there at all. It took three hours for them to gear up the physical energy to simply get dressed, and everything else they’ve got in the tank to make it home later. Or how about the calmest, most mellow person at the office? Perhaps they’re riding a roller coaster without a seatbelt, experiencing states that take them from happy, energized, and on top of the world to despair and crushing loss in a moment. They’re very aware that they aren’t really feeling those things, yet that’s what they’re feeling. And all because their head is trying to keep standard chemicals in the brain perfectly balanced, only theirs slightly over- and under-calibrates.

    Little do you know, they’re making impossible choices—like deciding whether to handle their condition through sheer grit or to take a medication that dulls their symptoms, yet affects acuity as the dosage increases. It might even make them seem glazed over and stoned to someone who didn’t know any better. How do you choose between your health and your job?

    It’s also important to mention that many mental health conditions affect quality of life so significantly that they are classified as disabilities—legally afforded accommodations and protections against discrimination. In reality, disclosing disabilities can be devastating to a career. Even advocates at disability services groups cautiously discuss the potential ramifications of sharing with HR, managers, and coworkers. An employee might just as soon be told to “suck it up,” passed over for promotion, not hired in the first place, or shifted slowly to the door, as have the chance of being granted accommodations that would greatly ease their ability to earn a living. But that’s daily life for some: hacking away at an impossible server issue while exploding inside from anxiety, or somehow channeling creative energy into design work when there’s a pull to just end things. It takes guts to go to work every day.

    When someone bravely opens up about their lives, they aren’t in search of platitudes, yet we tend to lean on what we’ve seen modeled. That might mean grasping beyond the realm of real experiences. With rare exceptions, movies, TV, and books love to present the extremes—stereotypes for the sake of plot. They treat mental health issues like comic relief, reasons the “heros” of the story should be afraid or on guard, or treat others with pity bordering on condescension. This is disrespectful, ill-informed, and only serves to miseducate on a mass scale, leaving stereotypes and stigma to go hand-in-hand. We’re better than that.

    So, how do we respond to and support others in the most respectful and honorable way possible?

    Specifically ask how they would like for you to be there and support them. They might just want an open door or someone to have lunch with sometimes. Don’t assume they’re expecting a rescuer or someone to fix things. In this moment, they are just opening up and talking as a means of easing the weight that’s on their shoulders.

    Do be a friend who “checks in.” Show that you’re around—you don’t have to talk long, just don’t “disappear” on them.

    Do talk about other things, but don’t not talk about the condition, either. They probably don’t want to talk about it all the time, and would love to have a distraction, but it’s also good to ask them about what they’re going through, and for them to explain more about it and suggest good, accurate resources to read.

    Don’t assume they’ve forgotten the internet exists. They have likely already been online and investigated the symptoms or condition thoroughly. Think twice before sending them reading materials and links to websites, blogs, forums, or articles, especially those written by others with similar issues. This implies they haven’t thought to look themselves, and there’s a chance that content written by those in worse situations can bring them down and play on fears that things can’t get better. While you’re at it, don’t suggest (or base suggestions for treatment on) movies, TV shows, or books because a character seems to have similar issues.

    Don’t say things like, “Can’t you take a pill for that?” It not only diminishes the issue by implying that medication is some sort of cure-all (which it isn’t), someone may not even need medication, may be sensitive to it, already be on some, or have tried many already without finding ones that help. They might even have personal reasons not to take it.

    Don’t think they’ve never heard about counseling or treatment. It can be very helpful to talk to a professional, but it is ultimately a personal choice to decide when the time is right to do so, and whom to see.

    If they’re an employee, ask what sort of accommodations would help them at work. A willingness to make accommodations and support them is huge, even if they choose not to ask for those accommodations in the end, or they suggest agreeable compromises. Ask what would be best for the particular person, such as if remote work might help or be too isolating, or if a flexible schedule would be best.

    One of my personal tenets is this: make time for people. Rejection is subtly transmitted in enumerable ways, so be mindful and learn to listen. We don’t have to know what to do, just know how to be there and how to go about it, whether it’s an afternoon coffee run together, a ready couch, or just letting others know they’re worthwhile.

    In our industry in particular, part of our very job is to consider people, their lives, their needs, and how to optimize everything around personal experiences so that no one is left feeling excluded or forgotten. Accessibility and inclusion stand for more than what we craft on a bright screen someplace.

    Note: only a trained mental health professional is qualified to make a diagnosis. If you’re coping with personal struggles, know that you have lots of people out there to support you. Reach out to find them, and don’t give up.

  • Learning to Be Flexible 

    As a freelancer, I work in a lot of different code repos. Almost every team I work with has different ideas of how code should be organized, maintained, and structured.

    Now, I’m not here to start a battle about tabs versus spaces or alphabetical order of CSS properties versus organizing in terms of concerns (positioning styles, then element layout styles, then whatever else), because I’m honestly not attached to any one system anymore. I used to be a one-tab kind of person, along with not really even thinking about the ordering of my properties, but slowly, over time, I’ve realized that most of that doesn’t really matter. In all the projects I’ve worked on, the code got written and the product or site worked for the users—which is really the most important thing. What gets me excited about projects now is the code, making something work, seeing it work across different devices, seeing people use something I built, not getting upset about how it’s written.

    Since I went down the freelance route again earlier this year, I’m working with many different teams and they all have different standards for how their code should be written. What I really want to know when I start a project is what the standards are, so I can adhere to them. For many teams that means a quick look through their documentation (when they have it, it’s a dream come true—there are no questions and I can just get to work). For other teams, it means I ask a lot of questions after I’ve taken a look at the code to verify how they prefer to do things.

    Even more so than just thinking about how to write code, there’s the fact that I may be working in straight CSS, Sass, Stylus, Handlebars, plain old HTML, or Jade and I usually roll right along with that as well. Every team makes decisions that suit them and their way of working—I’m there to make life easier by coming in and helping them get a job done, not tell them their whole setup is wrong. The variety keeps me on my toes, but it also helps me remember that there isn’t just one way to do any of this.

    What has this really done for me? I’ve started letting go of some things. I have opinions on how to structure and write CSS, but whether it’s written with a pre-processor or not, I don’t always care, and which pre-processor matters less to me as well. Any way you do it, you can get the job done. Choosing what works best for your team is what’s most important, not what anyone outside the team says is the “right” or “only” way to do something.

  • Personalizing Git with Aliases 

    Part of getting comfortable with the command line is making it your own. Small customizations, shortcuts, and time saving techniques become second nature once you spend enough time fiddling around in your terminal. Since Git is my Version Control System of choice (due partially to its incredible popularity via GitHub), I like to spend lots of time optimizing my experience there.

    Once you’ve become comfortable enough with Git to push, pull, add, and commit, and you feel like you’d like to pursue more, you can customize it to make it your own. A great way to start doing this is with aliases. Aliases can help you by providing shorthand commands so you can move faster and have to remember less of Git’s sometimes very murky UI. Luckily, Git makes itself easy to customize by setting global options in a file named .gitconfig in our home directory.

    Quick note: for me, the home directory is /Users/jlembeck, you can get there on OSX or most any other Unix platform by typing cd ~ and hitting enter or return. On Windows, if you’re using Powershell, you can get there with the same command and if you’re not using Powershell, cd %userprofile% should do the trick.

    Now, let’s take a look. First, open your .gitconfig file (from your home directory):

    ~/code/grunticon master* $ cd ~
    ~ $ open .gitconfig

    You might see a file that looks similar to this:

      name = Jeff Lembeck
      email = your.email.address@host.com
      st = status
      ci = commit
      di = diff
      co = checkout
      amend = commit --amend
      b = branch

    Let’s look at the different lines and what they mean.

      name = Jeff Lembeck
      email = your.email.address@host.com

    First up, the global user configuration. This is what Git references to say who you are when you make commits.

      st = status
      ci = commit
      di = diff
      co = checkout
      amend = commit --amend
      b = branch

    Following the user information is what we’re here for, aliases.

    Any command given in that screen is prefaced with git. For example, git st is an alias for git status and git ci is git commit. This allows you to save a little time while you’re typing out commands. Soon, the muscle memory kicks in and git ci -m “Update version to 1.0.2” becomes your keystroke-saving go-to.

    Ok, so aliases can be used to shorten commands you normally type and that’s nice, but a lot of people don’t really care about saving 10 keystrokes here and there. For them, I submit the use case of aliases for those ridiculous functions that you can never remember how to do. As an example, let’s make one for learning about a file that was deleted. I use this all of the time.

    Now, to check the information on a deleted file, you can use git log --diff-filter=D -- path/to/file. Using this information I can create an alias.

    d = log --diff-filter=D -- $1

    Let’s break that down piece by piece.

    This should look pretty familiar. It is almost the exact command from above, with a few changes. The first change you’ll notice is that it is missing git. Since we are in the context of git, it is assumed in the alias. Next, you’ll see a $1, this allows you to pass an argument into the alias command and it will be referenced there.

    Now, with an example. git d lib/fileIDeleted.js. d is not a normal command in git, so git checks your config file for an alias. It finds one. It calls git log --diff-filter=D -- $1. And passes the argument lib/fileIDeleted.js into it. That will be the equivalent of calling git log --diff-filter=D -- lib/fileIDeleted.js.

    Now you never have to remember how to do that again. Time to celebrate the time you saved that would normally be spent on Google trying to figure out how to even search for this. I suggest ice cream.

    For further digging into this stuff: I got most of my ideas from Gary Bernhardt’s wonderful dotfiles repository. I strongly recommend checking out dotfiles repos to see what wild stuff you can do out there with your command line. Gary’s is an excellent resource and Mathias’s might be the most famous. To learn more about Git aliases from the source, check them out in the Git documentation.

  • An Excellent Week 

    A couple of big announcements are making the rounds this week, both of them exciting for those of us who make web sites:

    Google advises progressive enhancement

    In a blog post explaining updates to its indexing system, Google makes it clear that they’re now parsing web pages in their entirety — not just HTML, but also CSS and JavaScript. Their indexer used to ignore layout and behave as if it were a text-only browser, but now it’s scanning fully rendered pages.

    This means a few things. First, make sure you’re not denying Googlebot access to directories that hold your CSS and JavaScript. Check your `robots.txt` file to make sure.

    Second, from Google’s post:

    Just like modern browsers, our rendering engine might not support all of the technologies a page uses. Make sure your web design adheres to the principles of progressive enhancement as this helps our systems (and a wider range of browsers) see usable content and basic functionality when certain web design features are not yet supported.
    Pierre Far, Webmaster Trends Analyst

    (Emphasis mine. By the way, this support for progressive enhancement plays very nicely with their strong recommendation for responsive web design.)

    And third: Speed matters. We’ve known for a while that a fast-loading site makes for a better user experience, but with this update it also means Google’s indexing system now explicitly favors faster-loading sites over slower ones.

    How do your sites stack up?

    HTML5 is now an official standard

    After initially taunting us with a release date well into the next decade, W3C has published their official recommendation for HTML5, ending years of of often-frustrating, but productive development.

    Most of us have been using HTML5 for years already (Jeremy Keith published HTML5 For Web Designers in 2010), so this may seem like a small thing to celebrate. But now we can use elements with full confidence they won’t change, we may see quicker adoption by browser makers of all the exciting things HTML5 brings to the table, and any XHTML holdouts may finally be convinced that HTML5 is good to go.

    Let’s get out there.

  • This week's sponsor: Hack Reactor 

    Thanks to Hack Reactor for sponsoring A List Apart this week. Hack Reactor is currently accepting applications for its 12-week, immersive online coding school, Remote Beta. Apply today.

  • Rachel Andrew on the Business of Web Dev: Seeing Past the Highlight Reel 

    I am not the sort of person who “airs her dirty laundry in public.” I wouldn’t walk into a mixed group of friends, colleagues, and complete strangers at a party and announce something deeply personal, and so it is with Twitter. For me, Twitter is a place to chat, a replacement for the Telnet Talkers I was so fond of in the 1990s. I share things I think are interesting, I keep up with what people I know are doing, but I see it as a public place.

    Recently, I had a Twitter conversation with someone who felt that people who don’t post about their bad days are being disingenuous. As if trying to keep things positive meant living a lie. However, I’m not pretending to be something I am not. It’s just that there is a filter through which I assess what is appropriate to share.

    Unlike those Telnet Talkers, Twitter has essentially become a place where I do business. My “personal brand” enables me to sell books and to gain writing and speaking gigs. It’s not all work: I post photos of my cat, participate in events such as the annual mocking of the Eurovision Song Contest, and relate what I saw while out running. All of it is content I would be happy for my clients, my mother, or my daughter to see.

    I know many other people have the same filter. Our filters may allow a little more or a little less through, but any of us operating professionally online have to leave things unsaid. If we show ourselves as being vulnerable via Twitter or Facebook, tell other people about the battles we face with our own minds, what might that do to our businesses? What if a potential client or employer finds those tweets? Discrimination due to mental health issues is unlawful, in the UK at least, but you can’t legislate against a potential client deciding not to get in touch with a freelancer who once tweeted about their depression.

    Despite living our lives in public, developing our filters without really thinking about them, we are still creating real relationships with each other. Via social media we know a lot of the detail of each others’ day-to-day lives—far more detail than we would know of many of the colleagues we work alongside in an office. I count as true friends some people who I rarely get the chance to interact with outside of what is essentially a public place. If we met in person, maybe they would look into my eyes and see the things I don’t speak of. Perhaps I would see the same in theirs.

    There is a saying, often used when people are talking about imposter syndrome:

    The reason we struggle with insecurity is because we compare our behind-the-scenes with everyone else’s highlight reel.

    While this quote is aimed at reassuring the person struggling with insecurity, there is also a person behind the highlight reel. Know that just as we are sharing our own highlights, so are our friends and colleagues.

    When we spend time with people, we learn their usual demeanor and we have visual clues to help us know that something is up. We can take that friend to one side and offer a safe place where they can share their struggles without worrying it will cross over into professional life.

    The relationships we form online are no less “real” than those we’ve formed face to face. Perhaps we are still learning how to help one another and how to ask for help in this space. Are those tweets sounding slightly less positive because someone having a bad day, or is there more to it? Are those uncharacteristically snarky responses coming from someone who is finding life really tough right now? Can we learn to look out for each other, as the lines between the real world and online blur? We can take our friends to one side virtually—drop them an email, offer a phone or Skype call to “catch up,” then offer a listening ear.

    For Geek Mental Help Week I want us to remember that where professional lives are entwined with personal on Twitter, we probably are seeing only the public side of a person. We’re all still learning how to care for each other in these new communities we are creating. For every one of our friends bravely sharing their story this week, there will be many more who are not in a place where they can do so right now. Let’s be aware that those battles may be deeply hidden, be kind to each other, and look out for subtle signs that someone might need somewhere less public to ask for support.

  • Beyond You 

    In client work, it’s our responsibility to ensure that our work lives beyond ourselves. Sometimes that means making sure the CMS can handle clients’ ever-changing business needs, or making sure it continually teaches its users. For clients with an internal development team that will be taking over after you, it means making sure the design system you create is flexible enough to handle changes, yet rigid enough to maintain consistency.

    Making your work live beyond you starts by changing your approach to design and development. Rather than defining and building a certain set of pages, focus on building an extensible design system of styles, modules, and page types.

    Clients can use the system like LEGO bricks, by taking apart and rearranging modules in new and different ways. The key to a successful system is keeping that modularity in mind while going through design, front-end, and backend development. Every piece you build should be self-contained and reusable.

    But a system like that only survives by educating your clients on how to use, maintain, and update it. Show how the components function, independently and together. Document and teach everything you can in whatever way works best—writing, screencasting, or in-person training sessions.

    The most common mistake made in this process—and I’ve made it plenty of times before—is stopping at education. Building and teaching a modular system is a great start, but success hinges on your clients being able to use it entirely on their own.

    In order for that to be the case, there is an important role reversal that must happen: the client team must become the doer, and you become the feedback-provider. That may sound weird, but think about how the design process normally goes. Say the client gives feedback on a checkout form—the functionality needs to be tweaked a bit to match their business operations. You take that feedback, design a solution, and present it back to them.

    Instead, after this role reversal, the client team identifies the change that needs to be made, they use their knowledge of the system to make it, and you provide feedback on their implementation. That process gives their team a chance to work with your system while you’re still involved, and it lets you ensure that things are being used the way you intended.

    So if you’re on the agency side like I am, remember that it’s your responsibility to make your work live on beyond your involvement. If you’re on the client side, hold your partner accountable for that. Ask all the necessary questions to really learn the system. Late in the project, ask how you can make changes, instead of letting the agency (or freelancer) make changes themselves. Force them to teach you how to care for what they’ve built, and everyone will be happier with, and more confident in, the result.

  • Rian van der Merwe on A View from a Different Valley: How to Do What You Love, the Right Way 

    Every time I start a new job I take my dad to see my office. He loves seeing where I work, and I love showing him. It’s a thing. As much as I enjoy this unspoken ritual of ours, there’s always a predictable response from my dad that serves as a clear indicator of our large generation gap. At some point he’ll ask a question along the lines of, “So… no one has an office? You just sit out here in the open?” I’ve tried many times to explain the idea of colocation and collaborative work, but I don’t think it’s something that will ever compute for him.

    This isn’t a criticism on how he’s used to doing things (especially if he’s reading this… Hi Dad!). But it shows how our generation’s career goals have changed from “I want the corner office!” to “I just want a space where I’m able to do good work.” We’ve mostly gotten over our obsession with the size and location of our physical workspaces. But we haven’t completely managed to let go of that corner office in our minds: the job title.

    Even that’s starting to change, though. This tweet from Jack Dorsey has received over 1,700 retweets so far:

    In episode 60 of Back to Work, Merlin Mann and Dan Benjamin discuss what they call “work as platform.” The basic idea is that we need to stop looking at work as a thing you do for a company. If you view your career like that, your success will always be linked to the success of the company, as well as your ability to survive within that particular culture. You will be at the mercy of people who are concerned about their own careers, not yours.

    Instead, if you think about your work as platform, your attention starts to shift to using whatever job you are doing to develop your skills further, so that you’re never at the mercy of one company. Here’s Merlin, from about 31 minutes into that episode of Back to Work (edited down slightly):

    If you think just in terms of jobs, you become a little bit short-sighted, because you tend to think in terms of, “What’s my next job?”, or “If I want good jobs in my career, what do I put on my resume?” So in terms of what you can do to make the kinds of things you want, and have the kind of career you like, I think it’s very interesting to think about what you do in terms of having a platform for what you do.

    There’s always this thing about “doing what you love.” Well, doing what you love might not ever make you a nickel. And if doing what you love sucks, no one is ever going to see it, like it, and buy it, which is problematic. That’s not a branding problem, that’s a “you suck” problem. So the platform part is thinking about what you do not simply in terms of what your next job is — it’s a way of thinking about how all of the things that you do can and should and do feed into each other.

    I think it’s worth giving yourself permission to take a dip into the douche-pool, and think a little bit about what platform thinking might mean to you. Because if you are just thinking about how unhappy you are with your job your horizons are going to become pretty short, and your options are going to be very limited.

    So here’s how I want to pull this all together. Just like we’ve moved on from the idea that the big office is a big deal, we have to let go of the idea that a big enough title is equal to a successful career. Much more important is that we figure out what it is that we want to spend our time and attention on — and then work at our craft to make that our platform. Take a realistic look at how much agency you have at work — it may be more than you realize — and try to get the responsibilities that interest you most, just to see where it takes you.

    This is also why side projects are so important. They help you use the areas you’re truly interested in to hone your skills by making something real, just for you, because you want to. And as you get really good, you’ll be able to use those skills more in your current role, which will almost certainly make for a more enjoyable job. But it could even turn into a new role at your company — or who knows, maybe even your own startup.

    If you go down this path, little by little you’ll discover that you suddenly start loving what you do more and more. Doing what you love doesn’t necessarily mean quitting your job and starting a coffee shop. Most often, it means building your own platform, and crafting your own work, one step at a time.

  • Axiomatic CSS and Lobotomized Owls 

    At CSS Day last June I introduced, with some trepidation, a peculiar three-character CSS selector. Called the “lobotomized owl selector” for its resemblance to an owl’s vacant stare, it proved to be the most popular section of my talk.

    I couldn’t tell you whether the attendees were applauding the thinking behind the invention or were, instead, nervously laughing at my audacity for including such an odd and seemingly useless construct. Perhaps I was unwittingly speaking to a room full of paid-up owl sanctuary supporters. I don’t know.

    The lobotomized owl selector looks like this:

    * + *

    Despite its irreverent name and precarious form, the lobotomized owl selector is no mere thought experiment for me. It is the result of ongoing experimentation into automating the layout of flow content. The owl selector is an “axiomatic” selector with a voracious purview. As such, many will be hesitant to use it, and it will terrify some that I include it in production code. I aim to demonstrate how the selector can reduce bloat, speed up development, and help automate the styling of arbitrary, dynamic content.

    Styling by prescription

    Almost universally, professional web interface designers (engineers, whatever) have accustomed themselves to styling HTML elements prescriptively. We conceive of an interface object, then author styles for the object that are inscribed manually in the markup as “hooks.”

    Despite only pertaining to presentation, not semantic interoperability, the class selector is what we reach for most often. While elements and most attributes are predetermined and standardized, classes are the placeholders that gift us with the freedom of authorship. Classes give us control.

    .my-module {
    	/* ... */

    CSS frameworks are essentially libraries of non-standard class-based ciphers, intended for forming explicit relationships between styles and their elements. They are vaunted for their ability to help designers produce attractive interfaces quickly, and criticized for the inevitable accessibility shortcomings that result from leading with style (form) rather than content (function).

    < !-- An unfocusable, semantically inaccurate "button" -->
    <a class="ui-button">press me</a>

    Whether you use a framework or your own methodology, the prescriptive styling mode also prohibits non-technical content editors. It requires not just knowledge of presentational markup, but also access to that markup to encode the prescribed styles. WYSIWYG editors and tools like Markdown necessarily lack this complexity so that styling does not impede the editorial process.


    Regardless of whether you can create and maintain presentational markup, the question of whether you should remains. Adding presentational ciphers to your previously terse markup necessarily engorges it, but what’s the tradeoff? Does this allow us to reduce bloat in the stylesheet?

    By choosing to style entirely in terms of named elements, we make the mistake of asserting that HTML elements exist in a vacuum, not subject to inheritance or commonality. By treating the element as “this thing that needs to be styled,” we are liable to redundantly set some values for the element in hand that should have already been defined higher in the cascade. Adding new modules to a project invites bloat, which is a hard thing to keep in check.

    .module-new {
    	/* So… what’s actually new here? */

    From pre-processors with their addition of variables to object-based CSS methodologies and their application of reusable class “objects,” we are grappling with sandbags to stem this tide of bloat. It is our industry’s obsession. However, few remedies actually eschew the prescriptive philosophy that invites bloat in the first place. Some interpretations of object-oriented CSS even insist on a flattened hierarchy of styles, citing specificity as a problem to be overcome—effectively reducing CSS to SS and denying one of its key features.

    I am not writing to condemn these approaches and technologies outright, but there are other methods that just may be more effective for certain conditions. Hold onto your hats.

    Selector performance

    I’m happy to concede that when some of you saw the two asterisks in * + * at the beginning of this article, you started shaking your head with vigorous disapproval. There is a precedent for that. The universal selector is indeed a powerful tool. But it can be good powerful, not just bad powerful. Before we get into that, though, I want to address the perceived performance issue.

    All the studies I’ve read, including Steve Souders’ and Ben Frain’s, have concluded that the comparative performance of different CSS selector types is negligible. In fact, Frain concludes that “sweating over the selectors used in modern browsers is futile.” I’ve yet to read any compelling evidence to counter these findings.

    According to Frain, it is, instead, the quantity of CSS selectors—the bloat—that may cause issues; he mentions unused declarations specifically. In other words, embracing class selectors for their “speed” is of little use when their proliferation is causing the real performance issue. Well, that and the giant JPEGs and un-subsetted web fonts.

    Contrariwise, the * selector’s simultaneous control of multiple elements increases brevity, helping to reduce file size and improve performance.

    The real trouble with the universal sector is that it alone doesn’t represent a very compelling axiom—nothing more intelligent than “style whatever,” anyway. The trick is in harnessing this basic selector and forming more complex expressions that are context-aware.

    Dispensing with margins

    The trouble with confining styles to objects is that not everything should be considered a property of an object per se. Take margins: margins are something that exist between elements. Simply giving an element a top margin makes no sense, no matter how few or how many times you do it. It’s like applying glue to one side of an object before you’ve determined whether you actually want to stick it to something or what that something might be.

    .module-new {
    	margin-bottom: 3em; /* what, all the time? */

    What we need is an expression (a selector) that matches elements only in need of margin. That is, only elements in a contextual relationship with other sibling elements. The adjacent sibling combinator does just this: using the form x + n, we can add a top margin to any n where x has come before it.

    This would, as with standard prescriptive styling, become verbose very quickly if we were to create rules for each different element pairing within the interface. Hence, we adopt the aforementioned universal selector, creating our owl face. The axiom is as follows: “All elements in the flow of the document that proceed other elements must receive a top margin of one line.”

    * + * {
    	margin-top: 1.5em;


    Assuming that your paragraphs’ font-size is 1 em and its line-height is 1.5, we just set a default margin of one line between all successive flow elements of all varieties occurring in any order. Neither we developers nor the folks building content for the project have to worry about any elements being forgotten and not adopting at least a standard margin when rendered one after the other. To achieve this the prescriptive way, we’d have to anticipate specific elements and give them individual margin values. Boring, verbose, and liable to be incomplete.

    Instead of writing styles, we’ve created a style axiom: an overarching principle for the layout of flow content. It’s highly maintainable, too; if you change the line-height, just change this singular margin-top value to match.

    Contextual awareness

    It’s better than that, though. By applying margin between elements only, we don’t generate any redundant margin (exposed glue) destined to combine with the padding of parent elements. Compare solution (a), which adds a top margin to all elements, with solution (b), which uses the owl selector.

    Diagram showing elements with margins, with and without the owl selector.
    The diagrams in the left column show margin in dark grey and padding in light gray.

    Now consider how this behaves in regard to nesting. As illustrated, using the owl selector and just a margin-top value, no first or last element of a set will ever present redundant margin. Whenever you create a subset of these elements, by wrapping them in a nested parent, the same rules that apply to the superset will apply to the subset. No margin, regardless of nesting level, will ever meet padding. With a sort of algorithmic elegance, we protect against compound whitespace throughout our interface.

    Diagram showing nested elements with margins using the owl selector.

    This is eminently less verbose and more robust than approaching the problem unaxiomatically and removing the leftover glue after the fact, as Chris Coyier reluctantly proposed in “Spacing The Bottom of Modules”. It was this article, I should point out, that helped give me the idea for the lobotomized owl.

    .module > *:last-child,
    .module > *:last-child > *:last-child,
    .module > *:last-child > *:last-child > *:last-child {
    	margin: 0;

    Note that this only works having defined a “module” context (a big ask of a content editor), and requires estimating possible nesting levels. Here, it supports up to three.

    Exception-driven design

    So far, we’ve not named a single element. We’ve simply written a rule. Now we can take advantage of the owl selector’s low specificity and start judiciously building in exceptions, taking advantage of the cascade rather than condemning it as other methods do.

    Book-like, justified paragraphs

    p {
    	text-align: justify;
    p + p {
    margin-top: 0;
    text-indent: 2em;

    Note that only successive paragraphs are indented, which is conventional—another win for the adjacent sibling combinator.

    Compact modules

    .compact * + * {
    	margin-top: 0.75em;

    You can employ a little class-based object orientation if you like, to create a reusable style for more compact modules. In this example, all elements that need margin receive a margin of only half a line.

    Widgets with positioning

    .margins-off > * {
    	margin-top: 0;

    The owl selector is an expressive selector and will affect widgets like maps, where everything is positioned exactly. This is a simple off switch. Increasingly, widgets like these will occur as web components where our margin algorithm will not be inherited anyway. This is thanks to the style encapsulation feature of Shadow DOM.

    The beauty of ems

    Although a few exceptions are inevitable, by harnessing the em unit in our margin value, margins already adjust automatically according to another property: font-size. In any instances that we adjust font-size, the margin will adapt to it: one-line spaces remain one-line spaces. This is especially helpful when setting an increased or reduced body font-size via a @media query.

    When it comes to headings, there’s still more good fortune. Having set heading font sizes in your stylesheet in ems, appropriate margin (leading whitespace) for each heading has been set without you writing a single line of additional code.

    Diagram showing automatically adjusted margins based on font-size.

    Phrasing elements

    This style declaration is intended to be inherited. That is how it, and CSS in general, is designed to work. However, I appreciate that some will be uncomfortable with just how voracious this selector is, especially after they have become accustomed to avoiding inheritance wherever possible.

    I have already covered the few exceptions you may wish to employ, but, if it helps further, remember that phrasing elements with a typical display value of inline will inherit the top margin but be unaffected in terms of layout. Inline elements only respect horizontal margin, which is as specified and standard behavior across all browsers.

    Diagram showing inline elements with margin.

    If you find yourself overriding the owl selector frequently, there may be deeper systemic issues with the design. The owl selector deals with flow content, and flow content should make up the majority of your content. I don’t advise depending heavily on positioned content in most interfaces because they break implicit flow relationships. Even grid systems, with their floated columns, should require no more than a simple .row > * selector applying margin-top: 0 to reset them.

    Diagram showing floated columns with margins.


    I am a very poor mathematician, but I have a great fondness for Euclid’s postulates: a set of irreducible rules, or axioms, that form the basis for complex and beautiful geometries. Thanks to Euclid, I understand that even the most complex systems must depend on foundational rules, and CSS is no different. Although modularization of a complex interface is a necessary step in its maturation, any interface that does not follow basic governing tenets is going to lack clarity.

    The owl selector allows you to control flow content, but it is also a way of relinquishing control. By styling elements according to context and circumstance, we accept that the structure of content is—and should be—mutable. Instead of prescribing the appearance of individual items, we build systems to anticipate them. Instead of prescribing the appearance of the interface as a whole, we let the content determine it. We give control back to the people who would make it.

    When turning off CSS for a webpage altogether, you should notice two things. First, the page is unfalteringly flexible: the content fits the viewport regardless of its dimensions. Second—provided you have written standard, accessible markup—you should see that the content is already styled in a way that is, if not highly attractive, then reasonably traversable. The browser’s user agent styles take care of that, too.

    Our endeavors to reclaim and enhance the innate device independence offered by user agents are ongoing. It’s time we worked on reinstating content independence as well.

  • The Specialized Web: Working with Subject-Matter Experts 

    The time had come for The Big Departmental Website Redesign, and my content strategist heart was all aflutter. Since I work at a research university, the scope wasn’t just the department’s site—there were also 20 microsites focusing on specific faculty projects. Each one got an audit, an inventory, and a new strategy proposal.

    I met one-on-one with each faculty member to go over the plans, and they loved them. Specific strategy related to their users and their work! Streamlined and clarified content to help people do what needed doing! “Somebody pinch me,” I enthused after another successful and energizing meeting.

    Don’t worry, the pinch came.

    I waltzed into my next microsite meeting, proud of my work and capabilities. I outlined my grand plan to this professor, but instead of meeting with the enthusiasm I expected, I was promptly received a brick wall of “not interested.” She dismissed my big strategy with frowns and flat refusals without elaboration. Not to be deterred, I took a more specific tack, pointing out that the photos on the site felt disconnected from the research. No dice: she insisted that the photos not only needed to stay, but were critical to understanding the heart of the research itself.

    She shot down idea after idea, all the while maintaining that the site should both be better but not change. My frustration mounted, and I finally pulled my papers together and asked, “Do you really even need a website?!” Of course, she scoffed. Meeting over.

    Struggles with subject-matter experts (SMEs) are as diverse as the subject-matter experts themselves. Whether they’re surgeons, C-level executives, engineers, policy makers, faculty—we as web workers need SMEs for their specialized content knowledge. Arming yourself with the right tools, skills, and mentalities will make your work and projects run smoother for everyone on your team—SME included.

    The right frame of mind

    Know that nobody comes to the table with a clean slate. While the particulars may be new—a web presence, a social media campaign, a new database-driven tool—projects aren’t.

    When starting off a project, I’ll ask each person why they’re at the table. Even though it may be obvious why the SME is on the team, each person gets equal time (no more than a minute or two) to state how what they do relates to the project or outcome. You’re all qualified to be there, and stating those qualifications not only builds familiarity, but provides everyone with a picture of the team as a whole.

    I see SMEs as colleagues and co-collaborators, no matter what they may think of me and my lack of similar specialized knowledge. I don’t come to them from a service mentality—that they give me their great ideas and I humbly craft them to be web-ready. We’re working together to create something that can serve and help the user.

    Listening for context

    After my disastrous initial meeting with the prickly professor, I gave myself some time to calm down, and scheduled another meeting with one thing on my agenda: listening. I knew I was missing part of the story, and when we sat down again, I told the SME that I only wanted her to talk to me about the site, the content, and the research.

    I wasn’t satisfied with her initial surface-level responses, because they weren’t solvable problems. To find the deeper root causes of her reluctance, I busted out my friends the Five Ws (and that tagalong how). When she insisted something couldn’t be removed or changed, I breezed right past why, because it wasn’t getting me anywhere. Instead, I asked: when did you choose this image? Where did this image come from? If it’s so essential to the site, it must have a history. I kept asking questions until I understood the context that existed already around this site. Once I understood the context, I could identify the need that content served, and could make sure that need was addressed, rather than just cutting it out.

    Through this deeper line of questioning, I learned that the SME had been through an earlier redesign process with a different web team. They started off much in the same way I had—with big plans for her content, and not a lot of time for her. The design elements and photos that she was determined to hang on to? That was all that she had been able to control in the process before.

    By swooping in with my ideas, I was just another Web Person to her, with mistrust feeding off old—but still very real—feelings of being ignored and passed over. It was my responsibility to build the working relationship back up and make it productive.

    In the end, the SME and I agreed to start off with only a few changes—moving to a 960-pixel width and removing dead links—and left the rest of the content and structure as-is in the migration. This helped build her trust that I would not only listen to her, but be a good steward of her content. When we revisited the content later on, she was much more receptive to all my big ideas.

    If someone seems afraid, ornery, reluctant, distrustful, or any other work-hampering trait, they’re likely not doing it just to be a jerk—there are histories, insecurities, and fears at work beneath the less-than-ideal behavior, as Kerry-Anne Gilowey points out in her presentation “The People Puzzle: Making the Pieces Fit.”

    Listening is a key skill here: let them be heard, and try to uncover what’s at the root of their resistance. Some people may have a natural affinity for these people skills, but anyone will benefit from spending time practicing and working on them.

    Tools before strategy, heading for tragedy

    Being a good listener, however, is not a simple Underpants Gnome scheme toward project success:

    1. Listen to your frustrating SME
    2. PROFIT

    Sometimes you and your SME are on the same page, ready to hop right in to Shiny New Project World! And hey, they have a great idea of what that new project is, and it is totally a Facebook page. Or a Twitter feed. Or an Instagram account, even though there is nothing to take photographs of.

    This doesn’t necessarily indicate a mentality of “Social media, how hard can it be!”–instead, exuberance signals your SME’s desire to be involved in the work.

    In the case of social media like Facebook or Twitter, the SME knows there is a conversation, a connection, happening somewhere, and they want to be a part of it. They may latch onto the thing they’ve heard of—maybe they check out photos of their friend’s kids on Facebook, or saw the use of hashtags mentioned during a big event like the World Cup. They’re not picking a specific tool just to be stubborn—they often just don’t have a clue as to how many options they actually have.

    Sometimes the web is a little freaky, so we might as well stare it in the face together:

    Graphic showing the range of available social media tools.
    The Conversation Prism, a visual map of social media. Click to view larger.

    Each wedge of this photo is a different type of service, and inside the wedge are the sites or tools or apps that offer that service. This is a great way to show the SME the large toolbox at our disposal, and the need to be mindful and strategic in our selection.

    After peering at the glorious toolbox of possible options, it becomes clear we’ll need a strategy to pick the right tool—an Allen wrench is great for building an IKEA bookshelf, but is lousy for tearing down drywall. I start my SME off with homework—a few simple, top-level questions:

    1. Who is this project/site/page for?
    2. Who is this project/site/page not for?

    Oftentimes, this is the first time the SME has really thought about audience. If the answer to Question 1 is “everyone,” I start to ask about specific stakeholder groups: Customers? Instructors? Board Members? Legislators? Volunteers? As soon as we can get one group in the “not for” column, the conversation moves forward more easily.

    An SME who says a website is “for everyone” is not coming from a place of laziness or obstinacy; the SMEs I work with simply want their website to be the most helpful to the most people.

    1. What other sites out there are like, or related to, the one we hope to make?

    SMEs know who their peers, their competitors, and their colleagues are. While you may toil for hours, days, or weeks looking at material you think is comparable, your SME will be able to rattle off people or projects for you to check out in the blink of an eye. Their expertise saves you time.

    There are obviously a lot more questions that get asked about a project, but these two are a great start to collaborative work, and function independently of specific tools. They facilitate an ongoing discussion about the Five Ws, and lay a good foundation to think about the practical side of the how.

    Get yourself (and your project, and your team) right

    It is possible to have a great working relationship with an SME. The place to start is with people—meet your SME, and introduce yourself! Meet as soon as the project starts, or even earlier.

    Go to their stomping grounds

    If you work with a large group of SMEs, find out where and when they gather (board meetings, staff retreats, weekly team check-ins) and get on the agenda. I managed to grab five minutes of a faculty meeting and told everyone who I was, a very basic overview of what I did, and that I was looking forward to working together—which sped up putting faces to names.

    Find other avenues

    If you’re having trouble locating the SMEs—either because they’re phenomenally busy or reluctant to work together—try tracking down an assistant. These assistants might have access to some of the same specialized knowledge as your SME (in the case of a research assistant), or they could have more access to your SME themselves (in the case of an executive assistant or other calendar-wrangler). Assistants are phenomenal people to know and respect in either of these cases; build a good, trusting relationship with them, and projects will move forward without having to wait for one person’s calendar to clear.

    Make yourself available

    Similarly, making yourself easier to find can open doors. I told people it was fine to “drop by any time,” and, while true, actually left people with no sense of my availability. When I started establishing set “office hours” instead, I found that drop-in meetings happened more often and more predictably. People knew that from 9 to 11 on Tuesdays and Thursdays, I was happy to talk about any random thing on their mind. I ended up having more impromptu meetings that led to better work.

    For those of you about to collaborate, we salute you

    SMEs, as stated in their very name, have specialized knowledge I don’t. However, the flip side is also true: my specialized knowledge is something they need so their content can be useful and usable on the web. Though you and your SMEs may be coming from different places, with different approaches to your work, and different skill sets and knowledge, you’ve got to work together to advance the project.

    Do the hard work to understand each other, and move forward even if the steps seem tiny (don’t let perfect be the enemy of the good!). Find a seed of respect for each other’s knowledge, nurture it as it grows, and bask in the fruits of your labor—together.

  • Nishant Kothary on the Human Web: The Politics of Feedback 

    “Were you going for ‘not classy’? Because if you were, that’s cool. This isn’t classy like some of your other work,” said my wife, glancing at a long day’s work on my screen.

    “Yep. That’s what I was going for!” I responded with forced cheer. I knew she was right, though, and that I’d be back to the drawing board the next morning.

    This is a fairly typical exchange between us. We quit our jobs last year to bootstrap an app (for lack of a better word) that we’re designing and building ourselves. I’m the front-end guy, she’s the back-end girl. And currently, she’s the only user who gives me design feedback. Not because it’s hard to find people to give you feedback these days; we all know that’s hardly the case. She’s the only one providing feedback because I think that’s actually the right approach here.

    I realize this flies in the face of conventional wisdom today, though. From VC’s and startup founders emphatically endorsing the idea that a successful entrepreneur is characterized by her willingness—scratch that: her obsession with seeking out feedback from anyone willing to give it, to a corporate culture around “constructive” feedback so pervasive that the seven perpendicular lines-drawing Expert can have us laughing and crying with recognition, we’ve come to begrudgingly accept that when it comes to feedback—the more, the merrier.

    This conventional wisdom flies in the face of some opposing conventional wisdom, though, that’s best captured by the adage, “Too many cooks spoil the broth.” Or if you’d prefer a far more contemporary reference, look no further than Steve Jobs when he talked to Business Week about the iMac back in ’98: “For something this complicated, it’s really hard to design products by focus groups. A lot of times, people don’t know what they (customers) want until you show it to them.”

    So which is it? Should we run out and get as much feedback as possible? Or should we create in a vacuum? As with most matters of conventional wisdom, the answer is: Yes.

    In theory, neither camp is wrong. The ability to place your ego aside and calmly listen to someone tell you why the color scheme of your design or the architecture of your app is wrong is not just admirable and imitable, but extremely logical. Quite often, it’s exactly these interactions that help preempt disasters. On the flip side, there is too much self-evident wisdom in the notion that, borrowing words from Michael Harris, “Our ideas wilt when exposed to scrutiny too early.” Indeed, some of the most significant breakthroughs in the world can be traced back to the stubbornness of an individual who saw her vision through in solitude, and usually in opposition to contemporary opinion.

    In practice, however, we can trace most of our failures to a blind affiliation to one of the two camps. In the real world, the more-the-merrier camp typically leaves us stumbling through a self-inflicted field of feedback landmines until we step on one that takes with it our sense of direction and, often more dramatically, our faith in humanity. The camp of shunners, on the other hand, leads us to fortify our worst decisions with flimsy rationales that inevitably cave in on us like a wall of desolate Zunes.

    Over the years I’ve learned that we’re exceptionally poor at determining whether the task at hand calls for truly seeking feedback about our vision, or simply calls for managing the, pardon my French, politics of feedback: ensuring that stakeholders feel involved and represented fairly in the process. Ninety-nine out of a hundred times, it is the latter, but we approach it as the former. And, quite expectedly, ninety-nine out of a hundred times the consequences are catastrophic.

    At the root of this miscalculation is our repugnance at the idea of politics. Our perception of politics in the office—that thing our oh-so-despicable middle managers mask using words like “trade-off,” “diplomacy,” “partnership,” “process,” “metrics,” “review” and our favorite, “collaboration”—tracks pretty closely to our perception of governmental politics: it’s a charade that people with no real skills use to oppress us. What we conveniently forget is that politics probably leads to the inclusion of our own voice in the first place.

    We deceive ourselves into believing that our voice is the most important one. That the world would be better served if the voices of those incompetent, non-technical stakeholders were muted or at the very least, ignored. And while this is a perfectly fine conclusion in some cases, it’s far from true for a majority of them. But this fact usually escapes most of us, and we frequently find ourselves clumsily waging a tense war on our clients and stakeholders: a war that is for the greater good, and thus, a necessary evil, we argue. And the irony of finding ourselves hastily forgoing a politically-savvy, diplomatic design process in favor of more aggressive (or worse, passive-aggressive) tactics is lost on us thanks to our proficiency with what Ariely dubs the fudge factor in his book The (Honest) Truth About Dishonesty: “How can we secure the benefits of cheating and at the same time still view ourselves as honest, wonderful people? As long as we cheat by only a little bit, we can benefit from cheating and still view ourselves as marvelous human beings. This balancing act is the process of rationalization, and it is the basis of what we’ll call the fudge factor theory.”

    Whether we like it or not, we’re all alike: we’re deeply political and our level of self-deception about our own political natures is really the only distinguishing factor between us.

    And the worst part is that politics isn’t even a bad thing.

    On the contrary, when you embrace it and do it right, politics is a win-win, with you delivering your best work, and your clients, stakeholders, and colleagues feeling a deep sense of accomplishment and satisfaction as well. It’s hard to find examples of these situations, and even harder to drive oneself to search for them over the noise of the two camps, but there are plenty out there if you keep your eyes open. One of my favorites, particularly because the scenarios are in the form of video and have to do with design and development, comes in the form of the hit HGTV show Property Brothers. Starring 6'4" identical twins Drew (the “business guy” realtor) and Jonathan (the “designer/developer” builder), every episode is a goldmine for learning the right way to make clients, stakeholders, and colleagues (first-time home owners) a part of the feedback loop for a project (remodeling a fixer-upper) without compromising on your value system.

    Now, on the off-chance you are actually looking for someone to validate your vision—say you’re building a new product for a market that doesn’t exist or is already saturated, or if someone specifically hired you to run with a radical new concept of your own genius (hey, it can happen)—it’ll be a little trickier. You will need feedback, and it’ll have to be from someone who is attuned to the kind of abstract thinking that would let them imagine and navigate the alternate universe that is so vivid in your mind. If you are able to find such a person, paint them the best picture you can with whatever tools are at your disposal, leave your ego at the door, and pay close attention to what they say.

    But bear in mind that if they are unable see your alternate universe, it’s hardly evidence that it’s just a pipe dream with no place in the real world. After all, at first not just the most abstract thinkers, but even the rest of us couldn’t imagine an alternate universe with the internet. Or the iPhone. Or Twitter. The list is endless.

    For now, I’m exhilarated that there’s at least one person who sees mine. And I’d be a fool to ignore her feedback.

  • Routines Aren’t the Enemy 

    I recently read Greg Smith’s piece on Bocoup’s blog about how they think about time tracking, including all the fascinating data about how your brain works to solve problems. It interested me a lot, since I’ve been thinking about not just how I track projects, but also how I structure my day as a freelancer.

    In addition, I read David Brook’s piece in the New York Times, where he discusses routine and creative people. I am a creature of routine, so reading that so many creative, smart people are too, gives me a bit of hope. It means that maybe, my routines are helping me actually be more productive (or at least that’s what I like to tell myself).

    Routine, for me, means making sure I’m taking breaks and putting some structure around my days. Not everyone is the same, but I find that I can go strong and get “in the zone” as it were, for about three to four hours at a go. After that, I need a break. So, now that I’m mostly working remote, and doing that work in my home office, I’ve had to figure out how to make that happen.

    This means that I need to work a regular work day, especially since I have a partner doing the same. I get up, eat breakfast, and then hit the office and go hard for an hour or so to organize my day. Once I know what’s ahead of me, I may take a break to shower or run, or I may dive in. But the most important thing for me: I take a lunch. I get away after a morning of work. And if it’s nice, I go outside. Then I hit it again and by 5 or so, I’m done. Maybe my brain isn’t totally spent, but I stop so that I don’t get to the overwhelmed, “what am I doing?!” phase of things.

    My favorite part of the day has become when I finish work and move into cooking mode. While cooking, my brain relaxes and I process things. Sometimes solutions pop into my head as well, and I may jot those down to remember for the next morning. As the Bocoup piece discusses, when we allow our brains to process in the background, we’re giving ourselves space to “incubate” what we’ve been working on previously. My routine allows me to make space for incubation.

    The other part of the routine that I’m grateful for is that it keeps me working a “normal” amount of hours and allows me to be more productive and efficient in them. By making parts of my day off limits for work, I know I need to get things done in the amount of time I’ve allotted for work. It allows for the space away from the computer, away from my home office, and away from the web. Jeffrey Zeldman discusses this in the lynda.com documentary about his work on the web, how with focused time, he’s getting more done in less time. I find the same to be true and it’s affirming to hear I’m not alone in that.

    As a freelancer working on several different things at once and keeping track of details, the routine comforts me. I realize this isn’t for everyone. Most people would say that since I’m freelance I can work whenever I want, so why not take advantage? I do sometimes; a yoga class sneaks in, or I have a slow day where I can step away and do something else in the afternoon—but for the most part, my friends work 9 to 5 jobs and I want to be able to have fun with them when they’re available. In addition, I find the “work whenever you want” idea actually turns into working more because you work all the time.

    This isn’t just about me being able to write the best code either. Having a routine can help with writing, getting ready for a presentation, or whatever your work may be. Even if you are going into an office, trying to block off time for focused work and other times for meetings, or breaks, or email, is just as beneficial as me making sure I’m not spending my whole life working.

    Plus, if routines made it so some of the great minds could produce great works, I guess it’s not so bad to have a routine when trying to solve code and design problems.

  • Training the CMS 

    Nothing brings content modeling to life like launching a shiny new site: teasers fit neatly without any awkward ellipses, images are cropped perfectly for different screen sizes, related content is wonderfully relevant. The content strategy comes to life, and all is right with the world.

    But for years, my joy was short lived—because it would only take a couple weeks for things to begin to fall apart: teasers would stop teasing, an image would get scaled oddly, and—I won’t lie—I’d even start seeing “click here” links.

    “Why are you messing this up?” I’d wonder. The content was perfectly modeled. The CMS was carefully built to reflect that model. I even wrote a detailed training document!

    In my mind, I saw authors printing out my instructions and lovingly taping them to the side of their screen. In the real world, they skimmed the document once, then never opened it again. When new staff was hired, no one remembered to tell them a content guide even existed.

    The problem? I’d spent months neck-deep in the content model, and knew exactly how important those guidelines were. But the authors didn’t. For most of them, it was their first time breaking content into its component parts and building it for reuse. It’s not surprising they were fumbling their way through the CMS: misusing fields, putting formatting where they shouldn’t, and uploading images that clashed with the design.

    Maybe you’re like me: you know what needs to happen in the CMS to create the experience everyone’s bought into on the front end, but you’ve found there’s a big difference between having a plan and actually getting people to execute it in their daily work. The results are frustrating and demoralizing—both for you and for the authors you’re trying to help.

    Don’t despair. There’s a better way to get your content guidelines adopted in the real world: put them right where they’re needed, in the CMS itself.

    Getting the team together

    If you’ve made a content template or page table before, the idea of an instructional content strategy document will sound familiar. Content templates act as a guide to a content model, explaining the purpose of each field and section, including information like intended audience, style reminders, and example copy. The problem is that these guidelines typically live independently of the CMS; the closest they ever come to integration is including a few screenshots of the editing interface.

    Content guides are generally owned and created by whoever is in charge of content in a team. But actually gathering the guidelines is a collaborative effort: a designer contributes information about ideal photo caption length, art direction, and image sizing. A developer knows all the different places a particular field will be displayed, which file formats are accepted for upload, and how many blog posts can be promoted to the front page at once. A project owner or manager knows whom the author should contact with attribution questions, which audience a product description should target, and which voice and tone documents are relevant for each content type.

    Getting content guidelines into the CMS itself requires connecting all these disciplines, which means it doesn’t fit neatly into most teams’ processes. In this article, I’ll show you how to bring all the pieces together to create guidelines that provide help when an author needs it, and make it easier for them to do their job well. We’ll do this by following three principles.

    Good labels and guidelines:

    • provide context, explaining what a field is for and how it will be used;
    • are specific, encouraging accuracy and uniformity while eliminating guesswork; and
    • are positive and helpful, rather than hostile and prohibitive.

    Let’s walk through how we can apply these principles to each piece of the CMS, using specific examples and addressing common challenges.

    Content types

    Before throwing an author into the endless fields of an edit form, we want to give them an introduction to the overall content type: what it is, where and how it will be displayed, and who it’s for.

    Let’s say authors used to create new pages for each event, and then remove them (when they remembered!) after the event ended. We’re replacing that with a specific Event content type. To help authors transition, I might include text like:

    Events are displayed in the Calendar page and in a block on the homepage, and will be automatically archived after their date has passed. The calendar is mainly used by members who are already familiar with our work and internal terms.

    Where and how this works varies by CMS. For example, Drupal has an “Explanation or submission guidelines” field for each content type that displays at the top of every entry’s edit page. Wordpress allows you to add meta boxes to edit screens with custom code or plugins like Advanced Custom Fields, which makes the information more accessible than hiding it in the contextual help tab. If you’re not sure how to do this in your CMS, talk to your developers—chances are, they can make it possible once they understand the goal.

    Field names

    When naming fields:

    • Be specific and descriptive. For example, in an artist profile, you might replace the default of “Title” and “Body” with “Artist Name” and “Biography.” Even when they feel redundant, field names like “Event Name” and “Event Description” help orient the author and remind them which content belongs where.
    • Describe the content in the field, not the format of the field. An image field named “Image” doesn’t tell an author what kind of image. Something like “Featured Photo” is better, and best is a specific description like “Venue or Speaker Photo.”
    • Be consistent. For example, don’t phrase a label as a question (“Open to the public?”) unless you consistently use questions across all your fields and content types.
    CMS form using three generic field names: Title, Type, and Body.
    Before: Generic field names on a CMS entry form.
    CMS form using three specific field names: Artist Name, Preferred Medium, and Full Biography.
    After: Specific field names give context to the entry, and help authors avoid mistakes.

    Help text and instructions

    Where a field name describes what content is, help text describes what it does. The goal is to help authors meet the site’s strategic, format, and style needs, and answer questions like the ones in these four categories:

    Messaging and information

    • What’s the underlying message of this copy?
    • What does this content do, in the context of the site? Is the point of this field to inform a user, drive them to action, or provide metadata for the site structure?
    • Are there things this field must include, or shouldn’t include?
    • Should the alt text describe, caption, or explain the function of this image?
    • Who’s the audience? Are they new to our work or familiar with our internal jargon?

    Style, voice, and tone

    • What grammatical structure should this text take (e.g., full sentence, sentence fragment, Three. Word. Tagline.)?
    • Should the title be straightforward, or written as clickbait? (Hint: NO.)
    • Should there be ending punctuation?
    • Character count can be enforced by the CMS, but is there an ideal length the author should aim for?
    • Are there style rules, such as acronym or capitalization usage, that are likely to come into play?
    • Are you trying to change authors’ current writing habits? For example, do they need reminders not to write “click here” or reference page location like “the list to the left”?


    • Which formats are allowed for an image or file upload?
    • Do uploads have a size limitation?
    • Should the filename follow a specific pattern (e.g., OrpingtonPoster-August2014.pdf)?
    • If a field uses HTML, which tags are accepted?
    • For a checkbox or select list, is there an upper or lower limit to the number of selections?

    Design and display

    • Does the value of this field change how or where the content is displayed? For example, does a checkbox control whether an article will be pushed to the homepage?
    • Does this field display alongside other fields (and so shouldn’t be duplicative), or appear alone (like teaser text)?
    • Will the CMS scale and resize images automatically, or does the author need to upload multiple versions?
    • Where will this image be displayed? Will different sizes (like thumbnails) show in different places around the site?
    • Are there art-direction requirements for this image? For example, does it need dark negative space in the left for an overlaid headline? Should it show a person looking directly at the camera?
    CMS event entry form with specific help text like “Spell out your acronyms!” and “When possible, use place names over street addresses” for each field.
    A CMS form with a mix of technical and editorial guidelines helps authors create consistent content entries.

    Making every word count

    You can’t answer all of those questions at once—no one is going to read three paragraphs of instructions for a single text field. Your goal is to highlight the most valuable—and most often forgotten—information. For example, a company that long-ago settled on PNGs for its product images doesn’t need reminders of appropriate file types. You might remind users to write in second person in a “Subtitle” field, then link off to a full voice and tone document for more guidance.

    Whatever you do, use space wisely—if the field label is “Featured Photo,” don’t write “This is where you upload the featured photo.”

    Special considerations

    Beware the big WYSIWYG

    Even the most well-meaning authors can be overwhelmed by a big blank box and a million WYSIWYG buttons, and the results aren’t pretty. Editorial guidelines help remind users what these long text fields should and shouldn’t be used for.

    If authors will be doing any formatting, it can be helpful to customize the WYSIWYG and provide explicit styling instructions to keep them on track.

    WYSIWYG editor with a very limited selection of formatting buttons, and help text including advice like “Remember that date-specific events should be made into Timeline entries rather than tucked into this field.”
    WYSIWYG field with a limited selection of buttons, including editorial and formatting guidelines.

    Be wary of endless “DO NOT” instructions. Positive reminders and examples of good content can be just as effective—and feel much friendlier—than prohibitions.

    Making lists contextual and clear

    Select fields and lists of checkboxes are part of many content types, but they’re used for a variety of different functions: a “Category” field might control where an entry is shown on the site, how it relates to other content, or even which layout template will be used for display. Good instructions provide authors with this context.

    Please remember to change your lowercase, underscore-ridden, concatenated, and abbreviated machine names, like “slvrLc_wynd,” to real words, like “Silver-Laced Wyandotte.” Key:label pairs exist so that your authors don’t have to speak database to be successful. Use them.

    Ordering your fields

    Many CMSes will let you group fields—most commonly in fieldsets or tabs—to help authors make sense of what they’re seeing. In most CMSes, the front-end display order doesn’t need to match the backend form order, so you can organize fields to help the authors do their job without affecting how things look on the live site.

    Usually, you’ll want to either group similar content fields together, or arrange fields in the order they’ll be entered.

    For example, say that you need multiple versions of a single piece of information, like a short title and a long title. It’s helpful to see these side by side, with reminders about how specifically the versions should differ from one another.

    Or, say that your content will be copied from another system, like a manufacturer’s specification or a legacy database. Matching your field order to the content source means that authors won’t have to skip around while creating an entry. Similarly, if your authors always enter the “Event Location” content in between the “Presenter Bio” and “Event Date” fields, the edit form should match that—even if it’s not the order that makes the most sense to you.

    Two fieldsets showing fields organized in groups under Homepage slideshow and Open graph metadata.
    Fieldsets help make sense of complex CMS entry forms, organizing fields into groups that help authors keep track of different types of content.

    Getting specific

    The developer in me wants to create a library of reusable generic help snippets, but the best instructions I produce are the ones that are specific to a particular client’s internal organization and processes. Don’t shy away from including information like “Contact Ann Sebright (x8453) for photo attribution information,” or “Check the internal calendar for date conflicts before posting a new event.”

    Making it real

    Every team’s workflow is different, so I can’t tell you exactly how to integrate the creation of these instructions into your projects. I can give you questions, though, so you can have productive conversations at the right times in your process.

    Picking a CMS

    If you haven’t selected a CMS yet, consider the following questions when evaluating your options. If the CMS has already been chosen, be aware of the answers so you can adjust your instructions strategy accordingly.

    • What formats of field-level help text does the CMS support: single lines of text, paragraphs, pop-ups, hover text?
    • Can the instructions include HTML? A bit of simple formatting can go a long way toward readability.
    • How hard is it to update the help text? As needs change over time, will adjusting the instructions be a hassle?
    • Can you change custom field labels used in the admin interface without affecting the machine name used in queries and front-end display?

    Content modeling

    Content strategists, developers, designers, and clients or subject-matter experts often work together to build content models. But it’s important to bring regular authors—not just the project leads, but the people who will actually be creating entries on the site—into the conversation as well, as early as possible.

    • Review content models and field names with authors before they are finalized. Do the field names you’re using make sense to them? Do they understand the relationships between fields, and what that means for connections between pieces of content?
    • Are there places where the new model differs significantly from the authors’ current conception of the content? Larger changes warrant more detailed reminders and help.
    • For fields that are subtly different from one another: what kind of information will authors need to distinguish between them and use them correctly?
    • If you’ve chosen a CMS with a limited ability to include help text, have you simplified your models accordingly? A model people can’t remember how to follow won’t do much for your content.

    Content migration planning

    When you have significant legacy content, plan for migration to be its own phase of the project. Talk about what kinds of guidelines would make moving content to the new CMS smoother.

    • If blobs in the current site are being split into component chunks, position those field components near each other during migration, since they are all being derived from the same source.
    • Create a set of perfect example entries for authors to consult during migration. A set of real content—especially one showing how information from the old site fits into the new model—is a valuable reference tool.
    • Consider adding “migration phase” instructions and field groupings, with a separate set of “live site” guidelines to be put in place after migration is complete. The kind of reminders needed while content is being moved are not always the same as the help text for content being newly created.

    Design and development

    As the design and CMS take shape, designers and developers are in the perfect position to spot potential snags.

    • Are any pieces of content making your spidey sense tingle? Is there author-editable imagery that has particular art direction needs? Are there site functions (e.g., “only one piece of content can be promoted to the front page at a time, and promoting a new piece will un-promote the existing content”) that you feel like you’re the only person who understands? Make note of any piece of site content that makes you nervous, and share them with your team so the guidelines address the issue.
    • Who’s going to enter the help text into the CMS itself? If the instructions are more tactical, this may be something the development team can do as they’re building out the content models. The content strategist may take the lead for more editorial guidelines—in many CMSes, help text is entered through a GUI rather than in code, so its entry doesn’t necessarily need to be owned by a developer.
    • Help text deserves its own QA. It’s incredibly important to see the instructions in context—there’s no other way to realize that a particular piece of text is too long or lost in the clutter, or that the field order doesn’t make sense in the form. The development and client or business teams should both review the edit forms for every content type to make sure all the important information has been captured.

    Ongoing adjustments

    Revisit your work regularly with both your team and your client or project sponsor. Adjusting the help text or rearranging the fields won’t take much ongoing time, but can make a huge difference to the quality of the author experience—and the resulting content.

    • Review live pages, especially any with complex layouts. If you find images that aren’t following art direction or text that isn’t providing needed information, add more specific help text around those issues.
    • Chat with the authors using the system and make adjustments based on their feedback. Is there anything annoying about the edit form? Are the fields in an order that works for them? Are there places where a link over to a style guide or intranet page would save them time? Small changes to the interface can make a big difference to the overall workflow for an author.

    Setting authors up for success

    I used to think it was inevitable: that a few months after launch, I’d be guaranteed to find misused fields and confusing headlines littering a site—the particular kind of chaos that arises from combining a powerful CMS with untrained site administrators. But as I’ve moved the content guidelines into the CMS itself, my post-launch check-ins have shifted away from annoyed sighs and toward small improvements instead.

    When we embed instructions where they’re most relevant and helpful, we help our authors build good habits and confidence. We allow them to maintain and expand a complex site without feeling overwhelmed. A website that looks perfect on launch day is a wonderful thing. But when we improve the author experience, we improve the content forever—and that’s a whole lot more satisfying.

  • Collaborative User Testing: Less Bias, Better Research 

    I’ve always worked in small product teams that relied on guerrilla user testing. We’d aim to recruit the optimal number of participants for these tests. We’d make sure the demographic reflected our target audience. We’d use an informal approach to encourage more natural behavior and reduce the effect of biases participants could be prone to.

    But you know what we almost never talked about? Ourselves. After all, we were evaluating work we had personal and emotional involvement in. I sometimes found myself questioning, how objective were our findings, really?

    It turns out, they may not have been.

    In “Usability Problem Description and the Evaluator Effect in Usability Testing,” Miranda G. Capra identifies a tendency in the UX community to focus on users when talking about testing, while seldom talking about the role of evaluator. The assumption is that if the same users perform the same tasks, the reported problems should be the same—regardless of who evaluates them.

    But when Capra studied 44 usability practitioners’ evaluations of pre-recorded sessions, this wasn’t observed. The evaluators, made up of experienced researchers and graduate students, reported problems that overlapped at an unexpectedly low rate—just 22 percent. Different evaluators found different problems, and assigned different levels of severity to them. She concluded that the role of evaluator was more important than previously acknowledged in the design and UX community.

    If complete and objective results couldn’t be achieved even by usability professionals who were evaluating the same recordings, what can we expect from unspecialized teams planning, conducting, and evaluating user testing?

    Bias is unavoidable

    As people fully immersed in the project, we are susceptible to many cognitive biases that can affect outcomes at any stage of research—from planning to analysis. Confirmation bias among inexperienced evaluators is a common one. This leads us to phrase questions in a way that is more likely to confirm our own beliefs, or subconsciously prioritize certain responses and ignore others. I’ve done it myself, and seen it in my colleagues, too. For example, I once had a colleague who was particularly keen on introducing search functionality. Despite the fact that only one respondent commented on the lack of search, they finished the testing process genuinely convinced that “most people” had been looking for search.

    We all want our research to provide reliable guidance for our teams. Most of us wouldn’t deliberately distort data. But bias is often introduced unknowingly, without the researcher being aware of it. In the worst-case scenario, distorted or misleading results can misinform the direction of the product and provide the team with false confidence in their decisions.

    Capra’s research and other studies have shown that bias commonly occurs at the planning stage (when drafting test tasks and scenarios), during the session itself (when interacting with the participants and observing their behavior), and at the analysis stage (when interpreting data and drawing conclusions). Knowing this, my team at FutureLearn, an online learning platform, set out to reduce the chance of bias in our own research—while still doing the quick, efficient research our team needs to move forward. I’d like to share the process and techniques we’ve established.

    Take stock of your beliefs and assumptions

    Before you begin, honestly acknowledge your personal beliefs, particularly if you’re testing something you have “strong feelings” about. Register those beliefs and assumptions, and then write them down.

    Do you think the Save button should be at the top of the form, rather than at the end, where you can’t see it? Have you always found collapsing side menus annoying? Are you particularly pleased and proud of the sleek new control you designed? Are you convinced that this label is confusing and that it will be misinterpreted? By taking note of them, you’ll stay more aware of them. If possible, let someone else lead when these areas are being tested.

    Involve multiple reviewers during planning

    At FutureLearn, our research is highly collaborative—everyone in the product team (and often other teams) is actively involved. We try to invite different people to each research activity, and include mixed roles and backgrounds: designers, developers, project managers, content producers, support, and marketing.

    We start by sharing a two-part testing plan in a Google Doc with everyone who volunteered to take part. It includes:

    • Testing goals: Here we write one to three questions we hope the testing will help us answer. Our tests are typically short and focused on specific research objectives. For example, instead of saying, “See how people get on with the new categories filter design,” we aim for objective phrasing that encourages measurable outcomes, like: “Find out how the presence of category filters affects the use of sorting tabs on the course list.” Phrasing the goals in this ways helps focus our evaluators’ (mis)interpretation.
    • Test scenarios: Based on the goals, we write three or four tasks and scenarios to go through with participants. We make the tasks actionable and as close as possible to expected real-life behavior, and ensure that instructions are specific. With each scenario, we also provide context to help participants engage with the interface. For example, instead of saying: “Find courses that start in June,” we say something along the lines of: “Imagine you’ll be on holiday next month and would like to see if there are any courses around that time that interest you.”

    In one past session, where participants were required to find specific courses, we used the verbs “find” and “search” in the first draft. A colleague noticed that by asking participants to “search for a course,” we could be leading them toward looking for a search field, rather than observing how they would naturally go about finding a course on the platform. It may seem obvious now that “search” was the wrong word choice, but it can be easy for a scenario drafter who is also involved in the project to overlook these subtle differences. To avoid this, we now have several people read the scenarios independently to make sure the language used doesn’t steer responses in a particular direction.

    Perform testing with multiple evaluators

    In her paper, Capra argues that having multiple observers reduces the chance of biased results, and that “having more evaluators spend fewer hours is more effective than having fewer evaluators spend more hours.” She notes that:

    Adding a second evaluator results in a 30-43% increase in problem detection… Gains decreased with each additional evaluator, with a 12-20% increase from adding a third evaluator, and a 7-12% increase for adding a fourth evaluator.

    In my past experience, the same small group of people (or a single person) was always responsible for user testing. Typically, they were also working on the project being tested. This sometimes led evaluators to be defensive—to the point that the observer would try to blame a participant for a design flaw. It also sometimes made the team members who weren’t involved in research skeptical about undesirable or unexpected results.

    To avoid this, we have several people oversee all stages of the process, including moderating the sessions. Usually, four of us conduct the actual session — two designers, a developer, and someone from another interest (e.g., a product manager or copywriter). It is crucial that only one of the designers is directly involved in the project, so the other three evaluators can offer a fresh perspective.

    Most importantly, everyone is actively involved, not merely a passive observer. We all talk to participants, take notes, and have a go at leading the session.

    During a session, we typically set up two testing “stations” that work independently. This helps us to collect more diverse data, since it allows two pairs of people to interview participants.

    FutureLearn staff gathered around a research participant at a user testing station.
    Multiple evaluators participate in each user research session, which take place at stations like these.

    The sessions tend to be short and structured around the specific goals identified in the plan. The whole process lasts no more than two hours, during which the two stations combined talk to 10 to 12 participants, for about 10 minutes each.

    Bias can take many forms, including the manipulation of participants through unconscious suggestion, or selection of people who are more likely to exhibit the expected behavior. Conducting testing in a public place, like the British Library, where our office is conveniently located, helps us ensure a broad selection of respondents who fit our target demographic: students, professionals, academics, and general-interest learners.

    Have multiple people analyze results

    Data interpretation is also prone to bias: cherry-picking findings and being fixated on some responses while being blind to others are common among inexperienced evaluators.

    Analyzing the data we gather is also a shared task in our team. At least two of us write up the notes in Google Docs and rewatch the session videos, which we record using Silverback.

    Most of our team doesn’t have experience in user testing. Being given a blank sheet of paper and asked to make sense of their findings would be intimidating and time-consuming—they wouldn’t know what to look for. Therefore, the designer responsible for the testing typically sets up a basic Google form that asks evaluators a series of fact-based questions. We use the following structure:

    • General questions: The participant’s name, age group, level of technical competence, familiarity with our product, and occupation. We ask these questions right at the beginning, along with having people sign a consent form.
    • Scenario performance: This section contains specific questions related to participants’ performance in each scenario. We typically use a few brief multiple-choice questions. Since our tests are short, we usually provide two to four options for each answer, rather than complex rating scales. Evaluators can then provide additional information or comments in an open text field.
    Two sample evaluator questions: Found courses starting in June? (options: found easily, struggled, or gave up or ran out of time), and Which course did they select? (options: future course, Current course, or Neither (didn't join)).
    Excerpts from the Google form each evaluator fills out while watching session videos.

    These simple forms help us reduce the chance of misinterpretation by the evaluator, and make it easier for inexperienced evaluators to share their observations. They also allow us to support our analysis with quantitative data—e.g., how many people experienced a problem and how often? How easy or difficult was a particular task to complete? How often was a particular element used as expected, versus ignored or misinterpreted?

    Using these forms, an evaluator can typically review all five of a station’s participants in about an hour. We do this as soon as possible— ideally on the same day as the sessions, while the observations are still fresh in our memories, and before we get a chance to overanalyze them.

    Once evaluators submit their forms, Google Docs creates an automatic response summary, which includes raw data with metrics, quotes, performance for each task, and other details.

    Based on these responses, recorded videos, and everyone’s written notes, the designer responsible synthesizes the team’s findings. I usually start by grouping all the collected data into related themes in another spreadsheet, which helps me see all the data at a glance and ensure nothing gets lost or ignored.

    An excerpt of a spreadsheet that groups data from research sessions into themes, such as “Start Dates” and “Terminology.”
    Grouping and organizing the data in a spreadsheet makes it easier to see themes and patterns.

    At this stage we look for general patterns in observed behavior. Inevitably some outliers and contradictions come up. We keep track of those separately. Since we do research regularly, over time these outliers add up, revealing new and interesting patterns, too.

    We then write up a summary of results—a short document that outlines these patterns and explains how they address our research goals. It also contains task performance metrics, memorable quotes, interesting details, and other things that stood out to the team.

    The summary is shared with the research team to make sure their notes were included and interpreted correctly. The researcher responsible then puts everything together into a user testing report, which is shared with the rest of the company. These reports are typically short PDFs (no longer than 12 pages) with a simple structure:

    • Goals of testing and tasks and scenarios: Content from the testing plan.
    • Respondents: A brief overview of the respondents’ demographics (based on the General Questions section).
    • Results and observations: Based on the results summary recorded earlier.
    • Conclusions: Next steps or suggestions for how we’ll use this information.

    Some teams avoid investing time in writing reports, but we find them useful. We often refer back to them in later stages and share them with people outside the project so they can learn from our findings, too. We also share the results in a shorter presentation format at sprint reviews.

    Keep it simple, but regular

    Conducting short, light sessions regularly is better than doing long, detailed testing only once in a blue moon. Keeping it quick and iterative also prevents us from getting attached to one specific idea. Research has suggested (PDF) that  the more you invest in a particular route, the less likely you are to consider alternatives—which could also increase your chances of turning user testing into a confirmation of your beliefs.

    We also had to learn to make testing efficient, so that it fits into our ongoing process. We now spend no more than two or three days on user testing during a two-week sprint—including writing the plan, preparing a prototype in Axure or Proto.io, testing, analyzing data, and writing the report. Collaborative research helps us keep each individual contributor’s time focused, saving us from spending time filtering information through deliverables and handoffs, and increasing the quality of our learning.

    Make time for research

    Fitting research into every sprint isn’t easy. Sometimes I wish someone would just hand me the research results so I could focus on designing, rather than data-gathering. But testing your own work regularly can be one of the most effective ways to overcome bias.

    The hindsight bias is an interesting example. We become more prone to thinking we “knew things all along” as we grow more experienced, and as our perception of the level of our past knowledge increases. This can lead some designers to believe that experience “reduces the need for usability tests.” The risk, however, is that our design experience can make it harder for us to connect empathetically with our target audience—to relate to the struggles they’re going through as they use our product (that’s also why it’s so hard to teach a subject you’ve gained mastery of).

    According to researchers like Paul Goodwin, a professor of management science at the University of Bath, the most effective known way we can overcome hindsight bias is by continuous education (PDF)—particularly when we work hard to gain new knowledge.

    Having invested effort to acquire new knowledge, you’re less likely to conclude that you “knew it all along.” In contrast, people perceived they had more prior knowledge when they received new knowledge passively and effortlessly.

    Actively engaging in user testing is the most effective way of learning I know. It’s also a great way to avoid arrogance and relate to the people we are building for. Minimizing bias takes practice, honesty, and collaboration. But it’s worth it.

  • Laura Kalbag on Freelance Design: Breaking Stuff 

    Do you know that horrible fear when you’ve broken something on a client project and you have no idea how to fix it? I do… Sometimes I’ll have been wading through templates on a site, getting it all up to scratch, then suddenly I’m faced with a page of doom—a whole page of garbled semi-English that sort of resembles an error message, but nothing I’ve ever seen before.

    As a freelancer, I’ve always been proud to have the time to dedicate to learning. Keeping up with the industry, and being able to level up my skills on each new project, is very important to me.

    But sometimes I struggled when I pushed myself that little bit too far. A few times I’ve had to request a lifeline from kind people on Twitter to pull me out of a hole. And then I feel a bit daft, having to admit my inadequacies on a social network in order to save myself from a worse situation.

    Some of us designers write code, and some of us don’t. For some designers, the limit is HTML and CSS. They’ll write markup, but they won’t write JavaScript. For others, it’s front-end technologies. They’ll work on the client-side, but avoid anything with databases and other back-end technologies.

    Most of us seem to have a boundary somewhere that defines what we think we can’t do. Working for and by yourself, you are limited by your own experience and skills.

    Testing the limits

    For me, it was the all-powerful and uncommunicative command line. It terrified me. I thought I would probably find a way of deleting everything on my hard drive if I made a typo in the command line.

    My fear of the command line was burdensome when it came to using Git. A lot of people I knew used Git on the command line, but I preferred to use a GUI tool. I found it easier to understand the concepts of staging, branches, pushing, and deploying with a visual representation of the actions.

    However, when I was using Git with the rest of the ind.ie team, trying to debug issues when I’d committed files to the wrong branch, I was assisted by developers who would fire up Terminal (the command line tool) to look at the problem.

    The wonderful thing about working with these developers is that they’d explain what they were doing as they went along. I wasn’t expected to sit quietly to the side until they’d used magic to fix my problem. I would stay in my seat, and they would dictate to me what I should type. Typing for myself, and understanding what I was typing, I was learning to do it for myself.

    Learning from other people in this way is a rich and rewarding experience. I started being able to use Git on the command line with confidence. Having seen Andy, one of the developers I was working with, look up some of the less-obvious Git commands on the web, I suddenly didn’t feel so exceptionally useless. It gave me the confidence to do the same without feeling like I was a failure because I didn’t know all the commands by heart.

    My safety net

    My developer safety net made me more willing to try new things. Now, when I’d come up against intimidating error messages, I had people who could easily rescue me in five minutes, rather than having to put out a call of shame to Twitter.

    But my confidence wasn’t exclusive to ind.ie. Feeling more secure in my new abilities improved my confidence in my client work. I knew I was now able to do loads of stuff with Git, so why could I not handle some of these other problems?

    One day I found myself debugging a JavaScript error through comparing the code with another page that was working. I fixed it! Me! Doing JavaScript! My confidence grew that little bit more.

    Stepping over the line

    Job titles can be used to put us in our place. I’ve been told I’m just a designer, so I shouldn’t do development. You’ve been told you’re just a developer, so someone else will handle the design. It’s too easy to forget that we’re working on this web platform together, and a crossover of skills is incredibly valuable.

    Technical problems shouldn’t just be reserved for those with technical job titles. As designers, it’s our job to be familiar with our platform. Print designers know a lot about paper and inks, and architects know about building materials and regulations. Web designers should understand their medium, even if they sometimes need a hand with the tricky stuff. Other industries have their parallels: prepress technicians and building contractors are available to help designers pick up the technical details.

    Exploring the working environment

    You’ll get a lot more out of your job if you don’t feel like your job title has put you in a box. It’s fun to learn new things, and explore unknown territories. Get in an environment that pushes you, but gives you a safety net. You owe it to yourself to learn more, be ambitious, be better at what you do, and strive to be the best you can be at your craft.

    You wouldn’t like it if someone else said you were “just a designer,” so don’t say it to yourself.


  • Before You Hire Designers 

    Before you hire a designer, set up the situation this person needs to be effective. Bringing any employee into an unprepared environment where they don’t have the tools or authority to succeed is unfair to them and a huge waste of your hard-earned money. It also burdens the other employees who aren’t sure what to do with this new person.

    A few years ago, I made plans with a friend for breakfast. She was late. When she finally got there, she apologized, saying she’d been cleaning up for the housecleaner.

    “Why in the world would you clean up for a housecleaner?!?” I asked.

    “So she can actually clean, you idiot.”

    This made no sense to me, but I let it go. Otherwise, we would’ve argued about it for hours. About a year later, I got busy enough with work that my house looked like it could star in an episode of Hoarders, so I hired a cleaner. After a few visits, I found myself cleaning up piles and random junk so that she could get to the stuff I actually wanted her to get to.

    I called my friend and said, “I get why you had to clean up for the cleaner now.”

    “I told you you were an idiot.”

    (My friends are great.)

    The moral of this story is you can’t drop a designer into your environment and expect them to succeed. You’ve got to clearly lay out your expectations, but you also have to set the stage so your designers come in and get to the stuff you need them to do.

    Introducing a new discipline to your workplace

    Let’s assume you don’t have a designer on staff. People have been going about their business and getting their work done, and now you’re introducing a designer. Even if your employees have been begging you to hire a designer, this creates a challenge. People are creatures of habit and comfort. As difficult as they claimed their jobs were without a designer, having one still means giving up control of things. This isn’t easy. All the complaining about having to do someone else’s job is about to turn into complaining about giving their work to someone else. People are awesome.

    A designer will absolutely change what your company produces, and they’ll also affect how your company operates. You’ll need to adjust your workflows for this new person, as well as being open to having them adjust your workflow once they arrive.

    Before you throw someone into the mix, sit the company down and explain why you’re hiring a designer, how the company benefits, and what the designer’s role and responsibilities are. Explain how adding this skill set to your group makes everyone’s job easier. (Including possibly going home earlier!) Thank them for going without a designer for so long. Talk to them about things that they no longer need to undertake because of the new designer. Tell them to expect some bumps as the designer gets integrated into the fold.

    Then back your designer up when those bumps occur.

    Your designer can’t do shit without support from the person up top. If their job is to go in and change the way people work, the way the product behaves, and the way people interact with each other (all of which design will do), that’s gonna ruffle a few feathers. When a colleague runs into your office and says, “The designer is changing things!” a well-placed “That’s exactly what I’m paying the designer to do” sets the perfect tone. Remember, designers aren’t out there doing it for their own well-being. They’re your representative.

    As tough as introducing a designer may be, it’s infinitely easier than introducing a designer into a workplace where a bad designer has been nesting. We’re talking industrial-sized smudge sticks. I once took a job where coworkers would walk to my desk and ask me to whip up signs for their yard sales. When I informed them that wasn’t my job, they replied that the previous designer always did that stuff. I reminded them that the previous designer got fired for not meeting his deadlines. Eventually, they stopped asking. Had I been more willing to bend to their requests, we would’ve forever established that designers are the people who make yard sale signs for coworkers.

    Clear the table of any shenanigans like that before your new designer starts. Delivering this message is much easier coming from you. Don’t pass it off to the new person.

    Understanding what designers are responsible for

    This may sound obvious: a designer is responsible for design, right? By design, I’m talking about not just how something looks, but also how it manifests the solution to the problem it solves. Remember that nice young designer who worked at a big company—the one who wasn’t invited to strategy meetings? By the time work got to him, the decisions were set down to the smallest details and all he did was execute. He wasn’t designing. He was executing on someone else’s design.

    In truth, he needed to assert himself. But this chapter is about you. Design is the solution to a problem, something you pay a professional to handle. A designer is, by definition, uniquely qualified to solve those problems; they’re trained to come up with solutions you may not even see. Your designer should champ at the bit to be involved in strategic discussions.

    Make sure to use your designer’s skill set completely. Make sure they’re involved in strategy discussions. Make sure they’re involved in solving the problem and not executing a solution that’s handed to them. Most of all, make sure they see this as part of their job. If they don’t, your design will only ever be as good as what people who aren’t designers think up.

    Giving designers the authority and space they need

    Just as it’s absolutely clear what authority your office manager, accountant, and engineers carry, make sure your company understands what authority your designer has. Let’s go ahead and extend the definition of authority to “things they own.” In the same way the bookkeeper owns the books and the engineer owns the code. (Yes, I get that technically you own it all. Work with me here.)

    Trust your designers. Give them the authority to make decisions they’re singularly qualified to make. Before you bring a designer into the company, decide what authority they have over parts of your workflow or product. Do they have the last call on user-interface decisions? Do they need to get input from other stakeholders? (Always a good idea.) Do they need approval from every stakeholder? (Always a political shit show. Trust me.)

    The right answer depends on the type of organization you run and the skill level of the designer. But whatever that call is, empower your designer with the maximum amount of agency to do their job well. No one tells the accountant how to do their job, but I’ve been in a hundred workplaces where people told the designer how to do theirs.

    A designer with backbone and experience won’t have any problem carving out the room they need to work, but they can’t do so if you don’t grant them the authority. Otherwise, you run the risk of bringing someone in to follow the whims of those around them. That’s not a full member of the team. That’s a glorified Xerox machine, an asset used by the rest of the company whenever they need some pixels pushed around.

    That’s how someone who’s supposed to work on your website’s UI ends up making Lost Cat flyers for Betty in HR.

    Equipping designers with the tools they need

    This should go without saying, except I once spent the first two weeks at a job spinning through a draconian requisition process to get copies of Photoshop and BBEdit, which the company considered nonessential software. Someone from IT gave me a one-hour demo on how I could harness PowerPoint to do anything I needed Photoshop for. (I know I should’ve stopped him, but at some point my annoyance faded in favor of fascination at how much he’d thought this out.)

    Like any craftsperson, your designer is only as good as their tools. Make sure they have what they need. Yes, it’s fair to ask them to justify their use. No, you don’t need to understand what everything does. Trust that they do.

    Measuring success

    How well you prepare your team for a designer, how well your designer gets along with everyone, and how professionally they behave means exactly jack squat if your designer doesn’t succeed in their goals. Before bringing any employee on board, you should know how you’ll measure their success. Will it be hard metrics? Do you expect sales or conversions on the website to increase a certain number? Is the goal to deliver a big upcoming project on time and under budget?

    Your business needs vary, so I can’t give you a magical equation for design success. But I can say: whatever your success metric is, make sure your designer both knows about it and has the authority to accomplish it.

    I do have a story for you though. I took a contract-to-hire job once, and the creative director sat me down on my first day and told me that he wasn’t sure what to expect of me and how I’d fit in with the rest of the studio. (Someone didn’t get their house in order.) At the end of the contract period, he’d evaluate whether to keep me around. I was young and stupid, so I didn’t press much and decided to blend in as much as possible (rookie mistake). When my contract was up, the creative director called me into his office and said I hadn’t performed the way they’d expected. Which was odd, because neither of us really understood what had been expected. I felt shitty, wondering what I could’ve done better. And honestly, I’m sure the creative director felt shitty too, because he realized he hadn’t properly set expectations for success.

    So yeah. Don’t do that. It should never be a surprise to anyone working for you that they’re doing badly. Or doing well for that matter. Let them know what they need to do to succeed. Let them know they’re succeeding. If they’re not succeeding, help them adjust course. And finally, let them know once they’ve succeeded.

    Writing the job description

    The most important thing about readying for a designer is figuring out how your company or organization benefits from their involvement. What will you be able to do once they’re here? Picture yourselves a year in the future. What do you hope to accomplish? Write those things down. They’re the basis for the job description you’re about to write.

    Make a list of what you need this person to do. Not the technical skills they should have, but the needs you hope those skills will fulfill. Do you need branding? Interface design? Illustrations? Forms? What kind of business are you in? Is it editorial? Are you a retailer that needs a catalog designed? Don’t forget to take care of your mobile needs. Trust me, you have mobile needs. (Trust me, you’ve had them since yesterday.)

    The result of this exercise may look something like this: “We need a designer with mobile experience that can do branding and interface design for complex data.” The longer that list gets, the more you’ll pay for a designer, and this exercise may help you realize that you need more than one person. A capable illustrator who can build a responsive site and understands agile workflow is a rare unicorn indeed.

    Now let’s go find us some designers!

  • Making Our Events More Inclusive For Those Under 21 (and Also Everyone Else) 

    On Saturday, Benjamin Hollway, a 16 year old front-end developer, wrote a post about his recent experiences attending industry events. He’s been coding since he was eight, and earlier this year he was shortlisted for Netmag’s Emerging Talent category. Yet none of the people in this category are able to participate fully in the sort of activities most of us take for granted.

    Last week, Benjamin attended an event I spoke at in London. He’d saved up to buy a ticket and travel up to the conference, and after the event he followed everyone to the after party to chat about the conference and meet some of the speakers. Everyone was allowed in, but he was turned away at the door and had to head back home early.

    This isn’t the first time he’s experienced this, and I remember far too well the same happening to me as well. Four years ago, I wrote about some of the difficulties I’d experienced as a young developer when it came to attending events. A lot of the meetups I wanted to go to were held in bars, and if there was someone checking IDs at the door, I couldn’t go.

    After parties are a really important part of a conference. They’re where we get to network, ask speakers questions about the talk they’ve just given, and generally have a good time meeting like-minded people. But so many of these after parties, and even events, are held in pubs and bars, meaning they’re completely off-limits to young people.

    I feel lucky that I live in a country where I could access most events when I turned 18 (although I have been prevented from going into others that are held in 21-or-over bars). In other countries, I wouldn’t be able to attend some events until I was 21.

    I know a lot of amazingly smart designers and developers who are under 18, and many of them are physically prevented from attending an industry event or after party after traveling all the way up and forking out often hundreds of pounds out of their own pocket to attend. The more young people we encourage to join the fold, the more we are excluding from these events.

    Holding events in age-restricted venues doesn’t just exclude those under 21. It also turns away people who don’t drink for medical and personal reasons, or because of their faith, such as Muslims. They can’t simply wait until they get older before they can attend, some of people will never be able to attend.

    If you’re an event or meetup organizer, please don’t exclude young designers and developers by holding your event in age-restricted venues. When London Web Standards realized that young developers who wanted to go couldn’t attend, they switched to holding their events in offices, making them accessible to both young people and people who would be excluded because of their faith, or for other reasons. They were delighted when young developers started to turn up to their events.

    There are a lot more creative things to do around an event that don’t involve hanging around at a noisy bar, which is something Rachel Andrew wrote about last year:

    Photo or history walks around cities can be attractive to a lot of people in our industry and need no more organizing than someone who knows the area and can take attendees around local landmarks and interesting spots for photographs. New Adventures earlier this year had a photo walk, and a typography walk round Brighton was organized around Ampersand conference.

    Finally, how about taking Benjamin’s suggestion and asking young people to speak at your event? They have a huge amount to offer, and will help suggest ways to make your event more open, not just to those under 18, but also to groups of people you may not have even considered.

    Oh, and if your event is open to young people, please add it to the Lanyrd list I’ve created for events open to those under 21 so that others can find it.

  • Shellshock: A Bigger Threat than Heartbleed? 

    Time to update those Linux servers again. A newly-discovered Linux flaw may be more pervasive, and more dangerous, than last spring’s Heartbleed.

    A newly discovered security bug in a widely used piece of Linux software, known as “Bash,” could pose a bigger threat to computer users than the “Heartbleed” bug that surfaced in April, cyber experts warned on Wednesday.


    Hackers can exploit a bug in Bash to take complete control of a targeted system, security experts said. The “Heartbleed” bug allowed hackers to spy on computers, but not take control of them.

    “Bash” Software Bug May Pose Bigger Threat Than “Heartbleed”, Re/code

    This new vulnerability, being called Shellshock, has been found in use on public servers, meaning the threat is not theoretical. A patch has been released, but according to Ars Technica, it’s unfortunately incomplete.

  • Antoine Lefeuvre on The Web, Worldwide: The Culinary Model of Web Design 

    We call ourselves information architects, web designers or content strategists, among other job titles in the industry, including the occasional PHP ninja or SEO rockstar. The web does owe a lot to fields like architecture, industrial design, or marketing. I still haven’t met an interaction cook or maitre d’optimization, though. No web makers turn to chefs for inspiration, one might say.

    Well, some do. Let me take you, s’il vous plaît, to Lyon, France, where people think sliced bread is the greatest thing since the internet.

    Just a hundred miles from the web’s birthplace at CERN in Geneva lies Lyon, France’s second biggest city. It’s no internet mecca, but that doesn’t mean there are no lessons to be learned from how people make the web there. Unlike many places in the world where the latest new thing is everyone’s obsession, entrepreneurs in Lyon are quite interested in… the nineteenth century! What they’re analyzing is their city’s greatest success, its cuisine.

    If Lyon’s food scene today is one the world’s best—even outshining Paris’ according to CNN, this is thanks to the Mères lyonnaises movement. These “mothers” were house cooks for Lyon’s rich people, who decided to emancipate and launch their own start-ups: humble restaurants aiming at top-quality food, not fanciness. The movement begun in the nineteenth century only grew bigger in the twentieth, when the Mères passed on their skills and values to the next generation. Their most famous heir is superstar chef Paul Bocuse, who has held the Michelin three-star rating longer than any other, and who began as the apprentice of Mère Eugénie Brazier, the mother of modern French cooking and one of the very first three-star chefs in 1928. “There’s a real parallel between the ecosystem the Mères started and what we want to achieve,” says Grégory Palayer, president of the aptly named local trade association La Cuisine du Web. To recreate the Mères’ recipe for success, the toqués—the nickname meaning both “chef’s hat” and “crazy” that’s given to La Cuisine du Web members—have identified its ingredients: networking, media support, funding, and transmitting skills and knowledge. Not to mention a secret plus: joie de vivre. “Parisians and Europeans are often surprised to see we can spend two hours having lunch,” says Grégory. “This is how we conduct business here!”

    Lyon’s designers too have their nineteenth-century hero in Auguste Escoffier, the celebrity chef of his age. He began his career as a kitchen boy in his uncle’s restaurant and ended up running the kitchens in London’s most luxurious hotels. Renowned as “the Chef of Kings and the King of Chefs,” Escoffier was also a serial designer: his creations include Peach Melba, Crêpe Suzette, and the Cuisine classique style. He even experimented in a culinary form of design under constraint while in the army during the 1870 Franco-Prussian War, using horse meat for ordinary meals to save scarce beef for the wounded, and inventing 1,001 recipes with turnip, the only readily available vegetable on the front lines. Escoffier did much to improve and structure his industry. He was the first head of the WACS, the chefs’ W3C, and revolutionized not only French cooking, but the way restaurants worldwide are run, by championing documentation, standardization, and professionalism.

    In his talk “Interaction Béchamel” at the Interaction 14 conference in Amsterdam, Lyon’s IxDA leader Guillaume Berry explained how the life and work of Escoffier could influence web design. Guillaume comes from a family of food lovers and makers. Himself a visual designer and an amateur cook, he is greatly inspired in his daily work by cuisine. “It’s all about quality ingredients and preparing them. I’ve realized this while chopping vegetables—a task often neglected or disliked.” The web’s raw ingredients are copy, images, videos: “Even a starred chef won’t be able to cook a proper dish with low-quality ingredients. Don’t expect a web designer to do wonders without great content.”

    Just as Escoffier took Ritz customers on a kitchen tour, Guillaume recommends explaining to your clients how their site or app has been cooked. The more open and understood our design processes are, the more their value will be recognized. Have you ever been running late and prepared dinner in a rush? I have and it was, unsurprisingly, a disaster. So tell your clients their website is nothing but a good meal; it takes time to make it a memorable experience.

    Looking back at other industries helps us see what’s ahead in ours. What could be the web’s answer to slow food, organic farming, or rawism? “How many interactions a day is it healthy for us to have?” asks Guillaume. He adds, “Cooks have a huge responsibility because depending on how they prepare the food they can make people sick.” Are we designers that powerful? Oh yes, and more—we destroyed the world, after all.

    No, the web industry isn’t free of junk food. When we create apps that make a smartphone obsolete after two years: junk food. When we believe email is dead and Facebook is the new communication standard: junk food. When we design only for the latest browsers and fastest connections: junk food.

    If we’re ready to move from “more” to “better,” let’s remember these simple rules from Eugénie Brazier: 1. Pick your ingredients very carefully; 2. Home-made first; 3. A flashy presentation won’t save a poor dish.

  • It Was Just A Thing 

    A little less than two months ago, I wrote about the most dangerous word in software development: just. A lot of assumptions hide behind that seemingly harmless word, but there’s another side to it.

    “It was just a thing we built to deploy our work to staging.”

    “It was just a little plugin we built to handle responsive tab sets.”

    “It was just a way to text a bunch of our friends at the same time.”

    Some of the best and most useful things we build have humble beginnings. Small side projects start with a sapling of an idea—something that can be built in a weekend, but will make our work a little easier, our lives a little better.

    We focus on solving a very specific problem, or fulfilling a very specific need. Once we start using the thing we’ve built, we realize its full potential. We refine our creation until it becomes something bigger and better. By building, using, and refining, we avoid the pitfalls of assumptions made by the harmful use of the word “just” that I warned about:

    Things change when something moves from concept to reality. As Dave Wiskus said on a recent episode of Debug, “everything changes when fingers hit glass.”

    But the people who build something shouldn’t be the only ones who shape its future. When Twitter was founded, it was just a way to text a bunch of friends at once. The way that people used Twitter in the early days helped determine its future. Retweets, @username mentions, and hashtags became official parts of Twitter because of those early usage patterns.

    Embrace the small, simple, focused start, and get something into people’s hands. Let usage patterns inform refinements, validate assumptions, and guide you to future success. It’s more than okay to start by building “just a thing”—in fact, I suggest it.

  • Getting Started With CSS Audits 

    This week I wrote about conducting CSS audits to organize your code, keeping it clean and performant—resulting in faster sites that are easier to maintain. Now that you understand the hows and whys of auditing, let’s take a look at some more resources that will help you maintain your CSS architecture. Here are some I’ve recently discovered and find helpful.

    Organizing CSS

    • Harry Roberts has put together a fantastic resource for thinking about how to write large CSS systems, CSS Guidelines.
    • Interested in making the style guide part of the audit easier? This Github repo includes a whole bunch of info on different generators.

    Help from task runners

    Do you like task runners such as grunt or gulp? Andy Osmani’s tutorial walks through using all kinds of task runners to find unused CSS selectors: Spring Cleaning Unused CSS Selectors.


    Are you interested in auditing for accessibility as well (hopefully you are!)? There are tools for that, too. This article helps you audit your site for accessibility— it’s a great outline of exactly how to do it.


    • Sitepoint takes a look at trimming down overall page weight, which would optimize your site quite a bit.
    • Google Chrome’s dev tools include a built-in audit tool, which suggests ways you could improve performance. A great article on HTML5 Rocks goes through this tool in depth.

    With these tools, you’ll be better prepared to clean up your CSS, optimize your site, and make the entire experience better for users. When talking about auditing code, many people are focusing on performance, which is a great benefit for all involved, but don’t forget that maintainability and speedier development time come along with a faster site.

  • Client Education and Post-Launch Success 

    What our clients do with their websites is just as important as the websites themselves. We may pride ourselves on building a great product, but it’s ultimately up to the client to see it succeed or fail. Even the best website can become neglected, underused, or messy without a little education and training.

    Too often, my company used to create amazing tools for clients and then send them out into the world without enough guidance. We’d watch our sites slowly become stale, and we’d see our strategic content overwritten with fluffy filler.

    It was no one’s fault but our own.

    As passionate and knowledgeable web enthusiasts, it’s literally our job to help our clients succeed in any way we can, even after launch. Every project is an opportunity to educate clients and build a mutually beneficial learning experience.

    Meeting in the middle

    If we want our clients to use our products to their full potential, we have to meet them in the middle. We have to balance our technical expertise with their existing processes and skills.

    At my company, Brolik, we learned this the hard way.

    We had a financial client whose main revenue came from selling in-depth PDF reports. Customers would select a report, generating an email to an employee who would manually create and email an unprotected PDF to the customer. The whole process would take about two days.

    To make the process faster and more secure, we built an advanced, password-protected portal where their customers could purchase and access only the reports they’d paid for. The PDFs themselves were generated on the fly from the content management system. They were protected even after they were downloaded and only viewable with a unique username and password generated with the PDF.

    The system itself was technically advanced and thoroughly solved our client’s needs. When the job was done, we patted ourselves on the back, added the project to our portfolio, and moved on to the next thing.

    The client, however, was generally confused by the system we’d built. They didn’t quite know how to explain it to their customers. Processes had been automated to the point where they seemed untrustworthy. After about a month, they asked us if we’d revert back to their previous system.

    We had created too large of a process change for our client. We upended a large part of their business model without really considering whether they were ready for a new approach.

    From that experience, we learned not only to create online tools that complement our clients’ existing business processes, but also that we can be instrumental in helping clients embrace new processes. We now see it as part of our job to educate our clients and explain the technical and strategic thought behind all of our decisions.

    Leading by example

    We put this lesson to work on a more recent project, developing a site-wide content tagging system where images, video, and other media could be displayed in different ways based on how they were tagged.

    We could have left our clients to figure out this new system on their own, but we wanted to help them adopt it. So we pre-populated content and tags to demonstrate functionality. We walked through the tagging process with as many stakeholders as we could. We even created a PDF guide to explain the how and why behind the new system.

    In this case, our approach worked, and the client’s cumbersome media management time was significantly reduced. The difference between the outcome of the two projects was simply education and support.

    Education and support can, and usually does, take the form of setting an example. Some clients may not fully understand the benefits of a content strategy, for instance, so you have to show them results. Create relevant and well-written sample blog posts for them, and show how they can drive website traffic. Share articles and case studies that relate to the new tools you’re building for them. Show them that you’re excited, because excitement is contagious. If you’re lucky and smart enough to follow Geoff Dimasi’s advice and work with clients who align with your values, this process will be automatic, because you’ll already be invested in their success.

    We should be teaching our clients to use their website, app, content management system, or social media correctly and wisely. The more adept they are at putting our products to use, the better our products perform.

    Dealing with budgets

    Client education means new deliverables, which have to be prepared by those directly involved in the project. Developers, designers, project managers, and other team members are responsible for creating the PDFs, training workshops, interactive guides, and other educational material.

    That means more organizing, writing, designing, planning, and coding—all things we normally bill for, but now we have to bill in the name of client education.

    Take this into account at the beginning of a project. The amount of education a client needs can be a consideration for taking a job at all, but it should at least factor into pricing. Hours spent helping your client use your product is billable time that you shouldn’t give away for free.

    At Brolik, we’ve helped a range of clients—from those who have “just accepted that the Web isn’t a fad” (that’s an actual quote from 2013), to businesses that have a team of in-house developers. We consider this information and price accordingly, because it directly affects the success of the entire product and partnership. If they need a lot of education but they’re not willing to pay for it, it may be smart to pass on the job.

    Most clients actually understand this. Those who are interested in improving their business are interested in improving themselves as well. This is the foundation for a truly fulfilling and mutually beneficial client relationship. Seek out these relationships.

    It’s sometimes challenging to justify a “client education” line item in your proposals, however. If you can’t, try to at least work some wiggle room into your price. More specifically, try adding a 10 percent contingency for “Support and Training” or “Onboarding.”

    If you can’t justify a price increase at all, but you still want the job, consider factoring in a few client education hours and their opportunity cost as part of your company’s overall marketing budget. Teaching your client to use your product is your responsibility as a digital business.

    This never ends (hopefully)

    What’s better than arming your clients with knowledge and tools, pumping them up, and then sending them out into the world to succeed? Venturing out with them!

    At Brolik, we’ve started signing clients onto digital strategy retainers once their websites are completed. Digital strategy is an overarching term that covers anything and everything to grow a business online. Specifically for us, it includes audience research, content creation, SEO, search and display advertising, website maintenance, social media, and all kinds of analysis and reporting.

    This allows us to continue to educate (and learn) on an ongoing basis. It keeps things interesting—and as a bonus, we usually upsell more work.

    We’ve found that by fostering collaboration post-launch, we not only help our clients use our product more effectively and grow their business, but we also alleviate a lot of the panic that kicks in right before a site goes live. They know we’ll still be there to fix, tweak, analyze, and even experiment.

    This ongoing digital strategy concept was so natural for our business that it’s surprising it took us so long to implement it. After 10 years making websites, we’ve only offered digital strategy for the last two, and it’s already driving 50 percent of our revenue.

    It pays to be along for the ride

    The extra effort required for client education is worth it. By giving our clients the tools, knowledge, and passion they need to be successful with what we’ve built for them, we help them improve their business.

    Anything that drives their success ultimately drives ours. When the tools we build work well for our clients, they return to us for more work. When their websites perform well, our portfolios look better and live longer. Overall, when their business improves, it reflects well on us.

    A fulfilling and mutually beneficial client relationship is good for the client and good for future business. It’s an area where we can follow our passion and do what’s right, because we get back as much as we put in.

  • CSS Audits: Taking Stock of Your Code 

    Most people aren’t excited at the prospect of auditing code, but it’s become one of my favorite types of projects. A CSS audit is really detective work. You start with a site’s code and dig deeper: you look at how many stylesheets are being called, how that affects site performance, and how the CSS itself is written. Your goal is to look for ways to improve on what’s there—to sleuth out fixes to make your codebase better and your site faster.

    I’ll share tips on how to approach your own audit, along with the advantages of taking a full inventory of your CSS and various tools.

    Benefits of an audit

    An audit helps you to organize your code and eliminate repetition. You don’t write any code during an audit; you simply take stock of what’s there and document recommendations to pass off to a client or discuss with your team. These recommendations ensure new code won’t repeat past mistakes. Let’s take a closer look at other benefits:

    • Reduce file sizes. A complete overview of the CSS lets you take the time to find ways to refactor the code: to clean it up and perhaps cut down on the number of properties. You can also hunt for any odds and ends, such as outdated versions of browser prefixes, that aren’t in use anymore. Getting rid of unused or unnecessary code trims down the file people have to download when they visit your site.
    • Ensure consistency with guidelines. As you audit, create documentation regarding your styles and what’s happening with the site or application. You could make a formal style guide, or you could just write out recommendations to note how different pieces of your code are used. Whatever form your documentation takes, it’ll save anyone coming onto your team a lot of time and trouble, as they can easily familiarize themselves with your site’s CSS and architecture.
    • Standardize your code. Code organization—which certainly attracts differing opinions—is essential to keeping your codebase more maintainable into the future. For instance, if you choose to alphabetize your properties, you can readily spot duplicates, because you’d end up with two sets of margin properties right next to each other. Or you may prefer to group properties according to their function: positioning, box model-related, etc. Having a system in place helps you guard against repetition.
    • Increase performance. I’ve saved the best for last. Auditing code, along with combining and zipping up stylesheets, leads to markedly faster site speeds. For example, Harry Roberts, a front-end architect in the UK who conducts regular audits, told me about a site he recently worked on:
      I rebuilt Fasetto.com with a view to improving its performance; it went from 27 separate stylesheets for a single-page site (mainly UI toolkits like Bootstrap, etc.) down to just one stylesheet (which is actually minified and inlined, to save on the HTTP request), which weighs in at just 5.4 kB post-gzip.

      This is a huge win, especially for people on slower connections—but everyone gains when sites load quickly.

    How to audit: take inventory

    Now that audits have won you over, how do you go about doing one? I like to start with a few tools that provide an overview of the site’s current codebase. You may approach your own audit differently, based on your site’s problem areas or your philosophy of how you write code (whether OOCSS or BEM). The important thing is to keep in mind what will be most useful to you and your own site.

    Once I’ve diagnosed my code through tools, I examine it line by line.


    The first tool I reach for is Nicole Sullivan’s invaluable Type-o-matic, an add-on for Firebug that generates a JSON report of all the type styles in use across a site. As an added bonus, Type-o-matic creates a visual report as it runs. By looking at both reports, you know at a glance when to combine type styles that are too similar, eliminating unnecessary styles. I’ve found that the detail of the JSON report makes it easy to see how to create a more reusable type system.

    In addition to Type-o-matic, I run CSS Lint, an extremely flexible tool that flags a wide range of potential bugs from missing fallback colors to shorthand properties for better performance. To use CSS Lint, click the arrow next to the word “Lint” and choose the options you want. I like to check for repeated properties or too many font sizes, so I always run Maintainability & Duplication along with Performance. CSS Lint then returns recommendations for changes; some may be related to known issues that will break in older browsers and others may be best practices (as the tool sees them). CSS Lint isn’t perfect. If you run it leaving every option checked, you are bound to see things in the end report that you may not agree with, like warnings for IE6. That said, this is a quick way to get a handle on the overall state of your CSS.

    Next, I search through the CSS to review how often I repeat common properties, like float or margin. (If you’re comfortable with the command line, type grep along with instructions and plug in something like grep “float” styles/styles.scss to find all instances of “float”.) Note any properties you may cut or bundle into other modules. Trimming your properties is a balancing act: to reduce the number of repeated properties, you may need to add more classes to your HTML, so that’s something you’ll need to gauge according to your project.

    I like to do this step by hand, as it forces me to walk through the CSS on my own, which in turn helps me better understand what’s going on. But if you’re short on time, or if you’re not yet comfortable with the command line, tools can smooth the way:

    • CSS Dig is an automated script that runs through all of your code to help you see it visually. A similar tool is StyleStats, where you type in a url to survey its CSS.
    • CSS Colorguard is a brand-new tool that runs on Node and outputs a report based on your colors, so you know if any colors are too alike. This helps limit your color palette, making it easier to maintain in the future.
    • Dust-Me Selectors is an add-on for Firebug in Firefox that finds unused selectors.

    Line by line

    After you run your tools, take the time to read through the CSS; it’s worth it to get a real sense of what’s happening. For instance, comments in the code—that tools miss—may explain why some quirk persists.

    One big thing I double-check is the depth of applicability, or how far down an attribute string applies. Does your CSS rely on a lot of specificity? Are you seeing long strings of selectors, either in the style files themselves or in the output from a preprocessor? A high depth of applicability means your code will require a very specific HTML structure for styles to work. If you can scale it back, you’ll get more reusable code and speedier performance.

    Review and recommend

    Now to the fun part. Once you have all your data, you can figure out how to improve the CSS and make some recommendations.

    The recommendation document doesn’t have to be heavily designed or formatted, but it should be easy to read. Splitting it into two parts is a good idea. The first consists of your review, listing the things you’ve found. If you refer to the results of CSS Lint or Type-o-matic, be sure to include either screenshots or the JSON report itself as an attachment. The second half contains your actionable recommendations to improve the code. This can be as simple as a list, with items like “Consolidate type styles that are closely related and create mixins for use sitewide.”

    As you analyze all the information you’ve collected, look for areas where you can:

    • Tighten code. Do you have four different sets of styles for a call-out box, several similar link styles, or way too many exceptions to your standard grid? These are great candidates for repeatable modular styles. To make consolidation even easier, you could use a preprocessor like Sass to turn them into mixins or extend, allowing styles to be applied when you call them on a class. (Just check that the outputted code is sensible too.)
    • Keep code consistent. A good audit makes sure the code adheres to its own philosophy. If your CSS is written based on a particular approach, such as BEM or OOCSS, is it consistent? Or do styles veer from time to time, and are there acceptable deviations? Make sure you document these exceptions, so others on your team are aware.

    If you’re working with a client, it’s also important to explain the approaches you favor, so they understand where you’re coming from—and what things you may consider as issues with the code. For example, I prefer OOCSS, so I tend to push for more modularity and reusability; a few classes stacked up (if you aren’t using a preprocessor) don’t bother me. Making sure your client understands the context of your work is particularly crucial when you’re not on the implementation team.

    Hand off to the client

    You did it! Once you’ve written your recommendations (and taken some time to think on them and ensure they’re solid), you can hand them off to the client—be prepared for any questions they may have. If this is for your team, congratulations: get cracking on your list.

    But wait—an audit has even more rewards. Now that you’ve got this prime documentation, take it a step further: use it as the springboard to talk about how to maintain your CSS going forward. If the same issues kept popping up throughout your code, document how you solved them, so everyone knows how to proceed in the future when creating new features or sections. You may turn this document into a style guide. Another thing to consider is how often to revisit your audit to ensure your codebase stays squeaky clean. The timing will vary by team and project, but set a realistic, regular schedule—this a key part of the auditing process.

    Conducting an audit is a vital first step to keeping your CSS lean and mean. It also helps your documentation stay up to date, allowing your team to have a good handle on how to move forward with new features. When your code is structured well, it’s more performant—and everyone benefits. So find the time, grab your best sleuthing hat, and get started.