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
  • Ask Dr. Web with Jeffrey Zeldman: If Ever I Should Leave You: Job Hunting For Web Designers and Developers 

    In our last installment, we discussed what to do when your boss is satisfied with third-party code that would make Stalin yak. This time out, we’ll discuss when, why, and how to quit your job.

    When is the right time to leave your first job for something new? How do you know you’re ready to take the plunge?
    Wet Behind The Ears

    Dear Wet Behind:

    From frying an egg to proposing marriage, you can never know for sure when it’s the right time to do anything—let alone anything as momentous as leaving your first job. First, search your heart: most times, you already know what you want to do. (Hint: if you’re thinking about leaving your job, you probably want to.) This doesn’t mean you should heedlessly stomp off to do what you want. Other factors must be carefully considered. But knowing what your heart wants is vital to framing a question that will provide your best answer.

    So ask yourself, do I want to leave? And if the answer is yes, ask yourself why. Are you the only girl in a boys’ club? Perhaps the only one with a real passion for the web? Are other folks, including your boss, dialing it in? Have you lost your passion for the work? Are you dialing it in? Is the place you work political? Do your coworkers or boss undervalue you? Have you been there two years or more without a raise or a promotion? Most vital of all, are you still learning on the job?

    Stagnation is fine for some jobs—when I was a dishwasher at The Earth Kitchen vegetarian restaurant, I enjoyed shutting off my brain and focusing on the rhythmic scrubbing of burnt pans, the slosh and swirl of peas and carrots in a soapy drain—but professionals, particularly web professionals, are either learning and growing or, like the love between Annie Hall and Alvy Singer, becoming a dead shark. If you’ve stopped learning on the job, it’s past time to look around.

    Likewise for situations where you face on-the-job discrimination. Or where you’re the only one who cares about designing and building sites and applications that meet real human needs, and of which you can truly be proud. Or where, after three years of taking on senior-level tasks, and making mature decisions that helped the company, you’re still seen as entry-level because you came in as an intern—and first impressions are forever. Or where you will never be promoted, because the person above you is young, healthy, adored by the owner, or has burrowed in like a tick.

    Some companies are smart enough to promote from within. These are the companies that tend to give you an annual professional development budget to attend conferences, buy books, or take classes; that encourage you to blog and attend meet-ups. Companies that ignore or actively discourage your professional growth are not places where you will succeed. (And in most cases, they won’t do that well themselves—although some bad places do attain a kind of financial success by taking on the same kinds of boring jobs over and over again, and hiring employees they can treat as chattel. But that ain’t you, babe.)

    It’s important, when answering these questions about your organization and your place within it, to be ruthlessly honest with yourself. If you work alongside a friend whose judgement you trust, ask her what she thinks. It is all too easy, as fallible human beings, to believe that we should be promoted before we may actually be ready; to think that people are treating us unfairly when they may actually be supporting and mentoring us; to ignore valuable knowledge we pick up on the job because we think we should be learning something different.

    If there’s no one at your workplace you can trust with these questions, talk to a solid friend, sibling, or love partner—one who is brave enough to tell you what you need to hear. Or check in with a professional—be they a recruiter, job counselor, yoga instructor, barista, or therapist. But be careful not to confide in someone who may have a vested interest in betraying your confidence. (For example, a recruiter who earns $100,000 per year in commissions from your company may not be the best person to talk to about your sense that said company grossly undervalues you.)

    Assuming you have legitimate reasons to move on, it’s time to consider those other factors: namely, have you identified the right place to move on to? And have you protected yourself and your family by setting aside a small financial cushion (at least three months’ rent in the bank) and lining up a freelance gig?

    Don’t just make a move to make a move—that’s how careers die. Identify the characteristics of the kind of place you want to work for. What kind of work do they do? If they are agencies, what do their former customers say about them? If friends work for them, what do they say about the place? What’s their company culture like? Do they boast a diverse workforce—diverse psychologically, creatively, and politically as well as physically? Is there a sameness to the kind of person they hire, and if so, will you fit in or be uncomfortable? If you’d be comfortable, might you be too comfortable (i.e. not learning anything new)? Human factors are every bit as important as the work, and, career-wise, more important than the money.

    If five of your friends work for your current employer’s biggest competitor, don’t assume you can walk across the street and interview with that competitor. The competitor may feel honor-bound to tell your boss how unhappy you are—and that won’t do you any good. Your boss might also feel personally betrayed if you take a job with her biggest competitor, and that might be burning a bridge.

    Don’t burn any bridges you don’t have to. After all, you never know who you might work for—or who you might want to hire—five years from now. Leaving on good terms is as important as securing the right next job. Word of mouth is everything in this business, and one powerful enemy can really hurt your career. More importantly, regardless of what they can do for or against your career, it’s always best to avoid hurting others when possible. After all, everyone you meet is fighting their own hard battle, so why add to their burdens?

    This isn’t to say you don’t have the right to work for anyone you choose who chooses you back. You absolutely have the right. Just be smart and empathetic about it.

    In some places, with some bosses, you can honestly say you’re looking for a new job, and the boss will not only understand, she’ll actually recommend you for a good job elsewhere. But that saintly a boss is rare—and if you work for one, are you sure you want to quit? Most bosses, however professional they may be, take it personally when you leave. So be discreet while job hunting. Once you decide to take a new job, let your boss know well ahead of time, and be honest but helpful if they ask why you’re leaving—share reasons that are true and actionable and that, if listened to, could improve the company you’re leaving.

    Lastly, before job hunting, line up those three months’ rent and that freelance gig. This protects you and your family if you work for a vindictive boss who fires employees he finds out are seeking outside jobs. Besides, having cash in the bank and a freelance creative challenge will boost your confidence and self-esteem, helping you do better in interviews.

    A good job is like a good friend. But people grow and change, and sometimes even the best of friends must part. Knowing when to make your move will keep you ahead of the curve—and the axe. Happy hunting!

  • This week's sponsor: Squarespace 

    Make a beautiful website with our sponsor, Squarespace. Keep it simple, or customize your HTML, CSS, and JavaScript with the Developer Platform—you can even get all your content through the JSON API. Get started today.

  • 2015 Summer Reading Issue 

    Summer is halfway over. Have you hid out for a day of reading yet? Grab a shady spot and a picnic blanket (or just park it in front of the nearest AC unit), turn off your notifications, and unwrap this tasty treat: our 2015 summer reader.

    Refresh your mind, heart, and spirit with this curated list of articles, videos, and other goodies from the recent past—from A List Apart and across the web.

    Which web do we want?

    Is the web “a place to connect knowledge, people, and cats,” or do “hordes threaten all that we have built for one another”? Where will native-versus-web fights end up? And why are we all here, doing this work, anyhow?

    From us

    From elsewhere

    Toward an inclusive industry

    This web is what we make of it. We can use it to insult strangers in a comments field, or to fight for greater fairness and opportunity in our world. We are inspired by those who choose the path of inclusion:

    From us

    From elsewhere

    Trying out new techniques

    Today’s code is so complex no individual can master it all—but that also means there’s always something new to learn…like these new, niche, or just plain cool techniques.

    From us

    Speeding up

    Big, lumbering websites, endless load times, and crappy experiences on mobile? No, thanks! Here’s to those in the trenches of performance, fighting the good fight.

    From us

    From elsewhere

    Accessibility for everyone

    “The power of the Web is in its universality,” Tim Berners-Lee once said—and that means working for all kinds of people, with all kinds of abilities. Let’s stop leaving accessibility for last, and instead start from a place that embraces the needs of all our users.

    From us

    From elsewhere

    Working better, together

    What comes after static comps and toss-it-over-the-wall processes? We’re still figuring that out—but one thing’s for sure: people are at the center.

    From us

    From elsewhere

    Becoming mentors

    The more we teach, the more we learn—and the more our industry benefits. Discover the joys of mentoring and the future of web education.

    From us

    From elsewhere

    Getting content right

    In the beginning was content—and it’s the core of every experience we design and build. Connect the right person to the right content at the right time using strategy, design, and writing.

    From us

    From elsewhere

    The evolution of type

    If not yet ubiquitous, sophisticated typography on the web is now at least possible. It continues to evolve apace—virtually anything we could do in print, we can now do on screens.

    From us

    From elsewhere

  • Mark Llobrera · Professional Amateurs: Memory Management 

    When I was starting out as a web designer, one of my chief joys was simply observing how my mentors went about their job—the way they prepared for projects, the way they organized their work. I knew that it would take a while for my skills to catch up to theirs, but I had an inkling that developing a foundation of good work habits was something that would stay with me throughout my career.

    Many of those habits centered around creating a personal system for organizing all the associated bits and pieces that contributed to the actual code I wrote. These days as I mentor Bluecadet’s dev apprentices, I frequently get asked how I keep all this information in my head. And my answer is always: I don’t. It’s simply not possible for me. I don’t have a “memory palace” like you’d see onscreen in Sherlock (or described in Hilary Mantel’s Wolf Hall). But I have tried a few things over the years, and what follows are a few habits and tools that have helped me.

    Extend your memory

    Remember this: you will forget. It may not seem like it, hammering away with everything so freshly-imprinted in your mind. But you will forget, at least long enough to drive you absolutely batty—or you’ll remember too late to do any good. So the trick is figuring out a way to augment your fickle memory.

    The core of my personal memory system has remained fairly stable over the years: networked notes, lots of bookmarks, and a couple of buffer utilities. I’ve mixed and matched many different tools on top of those components, like a chef trying out new knives, but the general setup remains the same. I describe some OS X/iOS tools that I use as part of my system, but those are not a requirement and can be substituted with applications for your preferred operating system.

    Networked notes

    Think of these as breadcrumbs for yourself. You want to be able to quickly jot things down, true—but more importantly, you have to be able to find them once some time has passed.

    I use a loose system of text notes, hooked up to a single folder in Dropbox. I settled on text for a number of reasons:

    • It’s not strongly tied to any piece of software. I use nvALT to create, name, and search through most of my notes, but I tend to edit them in Byword, which is available on both OS X and iOS.
    • It’s easily searchable, it’s extremely portable, and it’s lightweight.
    • It’s easily backed up.
    • I can scan my notes at the file system level in addition to within an app.
    • It’s fast. Start typing a word in the nvALT search bar and it whittles down the results. I use a system of “tags” when naming my files, where each tag is preceded by an @ symbol, like so: @bluecadet. Multiple tags can be chained together, for example: @bluecadet @laphamsquarterly. Generally I use anywhere from one to four tags per note. Common ones are a project tag, or a subject (say, @drupal or @wordpress). So a note about setting up Drupal on a project could be named “@bluecadet @drupal @projectname Setup Notes.txt.” There are lots of naming systems. I used this nvALT 101 primer by Michael Schechter as a jumping-off point, but I found it useful to just put my tags directly into the filename. Try a few conventions out and see what sticks for you.
    Notes naming system screenshot
    My file naming system for text notes.

    What do I use notes for? Every time I run into anything on a project, whether it’s something that confuses me, or something I just figured out, I put that in a note. If I have a commonly-used snippet for a project (say, a deploy command), then I put that in a note too. I try to keep the notes short and specific—if I find myself adding more and more to a note I will often break it out into separate notes that are related by a shared tag. This makes it easier to find things when searching (or even just scanning the file directory of all the notes).

    Later on those notes could form the basis for a blog post, a talk, or simply a lunch-and-learn session with my coworkers.

    Scratch pad

    I have one special note that I keep open during the day, a “scratch pad” for things that pop into my brain while I’m focusing on a specific task. (Ironically, this is a tip that I read somewhere and failed to bookmark). These aren’t necessarily things that are related to what I’m doing at that moment—in fact, they might be things that could potentially distract me from my current task. I jot a quick line in the scratch pad and when I have a break I can follow up on those items. I like to write this as a note in nvALT instead of in a notebook because I can later copy-and-paste bits and pieces into specific, tagged notes.

    Bookmarking: Pinboard

    So notes cover my stuff, but what about everyone else’s? Bookmarks can be extremely useful for building up a body of links around a subject, but like my text notes they only started to have value when I could access them anywhere. I save my bookmarks to Pinboard. I used to use Delicious, but after its near-death, I imported my links to Pinboard when a friend gave me a gift subscription. I like that Pinboard gives you a (paid) option to archive your bookmarks, so you can retrieve a cached copy of a page if link rot has set in with the original.

    Anything that could potentially help me down the line gets tagged and saved. When I’m doing research in the browser, I will follow links off Google searches, skim them quickly, and bookmark things for later, in-depth reading. When I’m following links off Twitter I dump stuff to Pocket, since I have Pinboard set to automatically grab all my Pocket articles. Before I enabled that last feature, I had some links in Pocket and some in Pinboard, so I had to look for things in two separate places.

    Whatever system you use, make sure it’s accessible from your mobile devices. I use Pinner for iOS, which works pretty well with iOS 8’s share sheets. Every few days I sit down with my iPad and sift through the links that are auto-saved from Pocket and add more tags to them.

    Buffers: clipboard history and command line lookup

    These last two tips are both very small, but they’ve saved me so much time (and countless keystrokes) over the years, especially given how often cut-and-paste figures into my job.

    Find a clipboard history tool that works for you. I suggest using the clipboard history in your launcher application of choice (I use Launchbar since it has one built in, but Alfred has one as part of its Powerpack). On iOS I use Clips (although it does require an in-app purchase to store unlimited items and sync them across all your devices). Having multiple items available means less time spent moving between windows and applications—you can grab several items, and then paste them back from your history. I’m excited to see how the recently-announced multitasking features in iOS 9 help in this regard. (It also looks like Android M will have multiple window support.) If you don’t use a launcher, Macworld has a fairly recent roundup of standalone Mac apps.

    If you use the command line bash shell, CTRL+R is your friend: it will allow you to do a string search through your recent commands. Hit CTLR+R repeatedly to cycle through multiple matches in your command history. When you deal with repetitive terminal commands like I do (deploying to remote servers, for instance), it’s even faster than copying-and-pasting from a clipboard history. (zsh users: looks like there’s some key bindings involved.)

    Finding your way

    I like to tell Bluecadet’s dev apprentices that they should pay close attention to the little pieces that form the “glue” of their mentor’s process. Developing a personal way of working that transcends projects and code can assist you through many changes in roles and skills over the course of your career.

    Rather than opting in to a single do-it-all tool, I’ve found it helpful to craft my own system out of pieces that are lightweight, simple, flexible, and low-maintenance. The tools I use are just layers on top of that system. For example, as I wrote this column I tested out two Markdown text editors without having to change how I organize my notes.

    Your personal system may look very different from the one I’ve described here. I have colleagues who use Evernote, Google Docs, or Simplenote as their primary tool. The common thread is that they invested some time and found something that worked for them.

    What’s missing? I still don’t have a great tool for compiling visual references. I’ve seen some colleagues use Pinterest and Gimmebar. I’ll close by asking: what are you using?

  • This week's sponsor: Bushel 

    If you manage and protect Apple devices at work, our sponsor Bushel is here to help make it easier.

  • Developing Empathy 

    I recently wrote about how to have empathy for our teammates when working to make a great site or application. I care a lot about this because being able to understand and relate to others is vital to creating teams that work well together and makes it easier for us to reach people we don’t know.

    I see a lot of talk about empathy, but I find it hard to take the more theory-driven talk and boil that down into things that I can do in my day-to-day work. In my last post, I talked about how I practice empathy with my team members, but after writing that piece I got to thinking about how I, as a developer in particular, can practice empathy with the users of the things I make as well.

    Since my work is a bit removed from the design and user experience layer, I don’t always have interactions and usability front of mind while coding. Sometimes I get lost in the code as I focus on making the design work across various screen sizes in a compact, modular way. I have to continually remind myself of ways I can work to make sure the application will be easy to use.

    To that end, there are things I’ve started thinking about as I code and even ways I’ve gone outside the traditional developer role to ensure I understand how people are using the software and sites I help make.


    From a pure coding standpoint, I do as much as I can to make sure the things I make are accessible to everyone. This is still a work in progress for me, as I try to learn more and more about accessibility. Keeping the A11Y Project checklist open while I work means I can keep accessibility in mind. Because all the people who want to use what I’m building should be able to.

    In addition to focusing on what I can do with code to make sure I’m thinking about all users, I’ve also tried a few other things.


    In a job I had a few years ago, the entire team was expected to be involved with support. One of the best ways to understand how people were using our product was to read through the questions and issues they were having.

    I was quite nervous at first, feeling like I didn’t have the knowledge or experience to adequately answer user emails, but I came to really enjoy it. I was lucky to be mentored by my boss on how to write those support messages better, by acknowledging and listening to the people writing in, and hopefully, helping them out when I could.

    Just recently I spent a week doing support work for an application while my coworker was on vacation, reminding me yet again how much I learn from it. Since this was the first time I’d been involved with the app, I learned about the ways our users were getting tripped up, and saw pitfalls which I may never have thought about otherwise.

    As I’ve done support, I’ve learned quite a bit. I’ve seen browser and operating system bugs, especially on devices that I may not test or use regularly. I’ve learned that having things like receipts on demand and easy flows for renewal is crucial to paid application models. I’ve found out about issues when English may not be the users’ native language—internationalization is huge and also hard. Whatever comes up, I’m always reminded (in a good way!), that not everyone uses an application or computer in the same ways that I do.

    For developers specifically, support work also helps jolt us out of our worlds and reminds us that not everyone thinks the same way, nor should they. I’ve found that while answering questions, or having to explain how to do certain tasks, I come to realizations of ways we can make things better. It’s also an important reminder that not everyone has the technical know how I do, so helping someone learn to use Fluid to make a web app behave more like a native app, or even just showing how to dock a URL in the OS X dock can make a difference. And best of all? When you do help someone out, they’re usually so grateful for it—it’s always great to get the happy email in response.

    Usability testing

    Another way I’ve found to get a better sense of what users are doing with the application is to sit in on usability testing when possible. I’ve only been able to do this once, but it was eye opening. There’s nothing better than watching someone use the software you’re making, or in my case, stumble through trying to use it.

    In the one instance where I was able to watch usability testing, I found it fascinating on several levels. We were testing a mobile website for an industry that has a lot of jargon. So, people were stumbling not just with the application itself, but also with the language—it wasn’t just the UI that caused problems, but the words the industry uses regularly that people didn’t understand. With limited space on a small screen, we’d shortened things up too much, and it was not working for many of the people trying to use the site.

    Since I’m not doing user experience work myself, I don’t get the opportunity to watch usability testing often, but I’m grateful for the time I was able to, and I’m hopeful that I’ll be able to observe it again in the future. Like answering support emails, it puts you on the front lines with your users and helps you understand how to make things better for them.

    Getting in touch with users, in whatever ways are available to you, makes a big difference in how you think about them. Rather than a faceless person typing away on a keyboard, users become people with names who want to use what you are helping to create, but they may not think exactly the same way you do, and things may not work as they expect.

    Even though many of us have roles where we aren’t directly involved in designing the interfaces of the sites and apps we build, we can all learn to be more empathetic to users. This matters. It makes us better at what we do and we create better applications and sites because of it. When you care about the person at the other end, you want to write more performant, accessible code to make their lives easier. And when the entire team cares, not just the people who interact with users most on a day-to-day basis, then the application can only get better as you iterate and improve it for your users.

  • Nishant Kothary on the Human Web: The Dominey Effect: For the Love of the Web, Learn Swift 

    I don’t remember the exact moment I fell in love with the web, but I distinctly remember the website that had a lot to do with it: whatdoiknow.org. It was the personal website of Todd Dominey, a web designer from Georgia (I wrote that from memory without the help of Google).

    By most colloquial measures, whatdoiknow.org wasn’t anything spectacular. But to me, it felt perfect: fixed two-column layout, black text, white background, great typography, lovely little details, and good writing. And, it had this background tile—check it out here, compliments of Wayback Machine (“Give it a second!” to load)—that tapped into some primordial part of the brain that erupts in a dopamine fireworks show at the sight of such things. I’m sure Π is somehow involved.

    It was 2001 (maybe 2002?), I was in college, and I was considering transferring out of computer science into interactive media when I found Dominey’s site. I immediately knew I wanted to make sites like that (even if I wasn’t sure why), so I submitted my CODO documentation, and walked across campus to the Computer Graphics department.

    The universe pushed back, of course.

    “Inadvisable,” advised my academic advisor at the time, because “how can you make money designing things?” It was a different time: B.S.—Before Steve. User experience was in its third trimester, and we’d just started feeling its first kicks. The argument against transferring was effectively the same one faced by liberal arts majors when they tell their parents they are going to major in English and minor in Sociology. The data suggested that I would be far less attractive to employers. But I was drawn in.

    I had no choice but to succumb to the first, but certainly not the last, Dominey moment of my professional life.

    And thus I was introduced to HTML and CSS. It was love at first sight. But unlike a lot of kids who found their home with standards-based front end web design, I’d just walked into a hyperlinked world of Dominey moments. And over the years, I clicked—maybe “tapped” is the more appropriate word for our generation—and followed many of them.

    HTML & CSS naturally led me to the world of graphic design. Photoshop and Illustrator entered my life and elated me. Then I wanted a blog. Moveable Type. This in turn led to CGI scripting, i.e. ASP and PHP. JavaScript entered the party as DHTML. And eventually, Flash—which renewed my interest in programming and mathematics, so that I went back to my old CS department and convinced them to let me finish the degree I’d abandoned while I finished up the other one.

    One by one, the domineys were falling.

    What’s fascinating about these moments, in hindsight, is they were inextricably linked. And much like the web, even when the links disappeared into the horizon as I moved to the next, they affected my career trajectory for the better. It feels magical that my ability to produce letterpress business cards (a Dominey moment) could have any bearing on my public relations skills for convincing the web community that Internet Explorer had had a heart transplant (a part of one of my past jobs). But there’s nothing really magical about that, is there?

    After all, feeling excitement for something new, learning it, getting somewhat good at it, and broadening your horizons can positively affect your career, no matter what you do (h/t to every post written about the benefits of side projects).

    Signal vs. signal

    All that said, the highs from experiencing these moments were inevitably followed by their characteristic comedowns: a mixture of fear, challenge, prejudice, and even dogma. Take my foray into Flash, for instance.

    For a standards-based web guy like me, embracing Flash felt like an either-or proposition as I looked around for mentorship. This phenomenon was a byproduct of the Flash vs. Web debate. You just didn’t come across web standardistas who were equally and openly into Flash—Shaun Inman and Dominey (who created SlideShowPro, a ubiquitous Flash-based slideshow app for a time) were prominent exceptions. Unsurprisingly, what Gruber writes about Apps vs. Web applies almost word for word to Flash vs. Web: “If you expand your view of ‘the web’ from merely that which renders inside the confines of a web browser to instead encompass all network traffic sent over HTTP/S, the explosive growth of native mobile apps is just another stage in the growth of the web. Far from killing it, native apps have made the open web even stronger.”

    When you take these sort of necessary but paralyzing debates and couple them with the insecurity you feel in answering the tap of a Dominey moment, it doesn’t take much to talk yourself out of it. And that problem never really goes away.

    Even today, having quit my job to go out on my own, the pushback is strong. What has changed though, thanks to a healthy amount of experience, reading, thinking, and counsel, is my ability to negotiate the arguments from others and myself as I embrace my next moment, inspired by the ongoing app revolution and the pleasure I derive from developing in Apple’s new language: Swift.

    My ability to steer around the doldrums of doubt wasn’t always there, though. Long ago, and often along the way as well, I needed a little nudge from a friend or mentor to get me going.

    So finally, on the topic of apps and Swift: let me give you a quick nudge.

    A Swift nudge

    If you’re a web programmer (or a budding programmer of any kind, or just someone who wants to get into programming), and looking at an app on your device (Instagram, Pinterest, Paper, and iMovie come to mind for me) made you think, “I want to build something like that,” I have this to say to you: learn Swift today.

    Don’t think twice about it.

    This must seem like a bizarre recommendation to make to a group of “people who make websites.” But I’ve never quite taken that tagline literally, and I know far too many of you feel the same (whether you’ll admit it in public or not). We are people who make the web, and as luck would have it we are people who particularly understand designing for mobile.

    After immersing myself in it for a year, I find Swift to be deeply web in its soul. From its expressive, functional syntax and its interpretive playgrounds to its runtime performance and recent foray into open source, Swift is the web developer’s compiled language (with the mature and convenient safeguards characteristic of the compiled environment).

    Everything you need to get you started is here. It’s free. And the community is amazing.

    As you may expect, the universe will push back on you embracing this moment. It will manifest in myriad ways—from the age old question of web vs. native to debates about Swift performance, syntax, and Apple’s intentions.

    Ignore that pushback. (Or don’t: do your due diligence, and form your own opinion.)

    But whatever you do, if you’ve got that thumping feeling, don’t ignore it. And try to not forget that you’re here because long ago you too embraced a Dominey moment.

    As far as I can tell, it’s worked out pretty well for all of us.


    • 1. Full disclosure: I do not know nor have I ever met Todd Dominey (but I’d buy him a drink anytime).
  • This week's sponsor: Pantheon 

    Build, launch, and manage all your Drupal and Wordpress sites with help from our sponsor, Pantheon​. Register for a weekly demo today!

  • Performance: Showing Versus Telling 

    When discussing performance, we tend to focus on technical challenges. But the social work—getting our colleagues to care about performance—is in fact the hardest and most crucial component of performance optimization. We simply can’t maintain the speed of our sites’ user experience over time without organizational leaders, design and developer peers, and clients who recognize the importance of performance work.

    We have to show two groups of people why they should care about performance:

    • Very Important People—like managers, executives, and clients—care about engagement metrics. They also take a lot of pride in their business and how it performs compared to competitors.
    • Fellow developers and designers—your peers—care about their workflow and shipping good work. They want to create a user experience that they’re proud to show off.

    The two groups definitely overlap; developers and designers care a lot about engagement metrics, for example. There are a number of great ways to showcase performance numbers, like Lonely Planet’s public dashboards. At Etsy, we even publish a quarterly report showing performance changes over time, and what triggered those changes. When convincing others to care about performance, however, it’s easy to get mired in numbers and graphs. Effecting a genuine culture shift is much more difficult.

    Furthermore, performance is unfortunately a fairly invisible part of the user experience. When you’ve done a good job, users don’t even notice it! But slowness creates a really painful experience. In his book High Performance Browser Networking, Ilya Grigorik outlines metrics for humans’ perception of speed:

    • 100 milliseconds of response time feels instantaneous to a user.
    • 100–300 milliseconds creates a small, but perceptible, delay.
    • 300 milliseconds–1 second feels like “the machine is working.”
    • 1 second constitutes a noticeable delay for a user. Just a single second of wait time will interrupt thought flow, and the user will probably start mentally context-switching.

    Put yourself in your fellow designers’ or developers’ shoes. How boring would it be for them to scan that list of numbers? If a Very Important Person doesn’t already care about performance as a part of the overall user experience, how would numbers (or charts that represent those numbers) help them start to care?

    Take your message to the next level. Help those around you feel the impact that performance has on your overall user experience. Showing is so much more compelling than telling; showcasing the real user experience is much more powerful than staring at numbers or bar charts. So how can we show performance?

    The power of visualizing performance

    Etsy’s Performance team commandeered a wall monitor in the office to tell our performance story. Its fullscreen Chrome window historically has cycled through the typical performance-related information: metrics, graphs, some explanation. But this dashboard’s newest superpower is the ability to show videos of how etsy.com loads on different connection speeds, and how our users around the world experience our site.

    To create this kind of dashboard, visit WebPageTest.org and kick off a test of your site.

    Screenshot from WebPagetest.org with example settings selected for a performance test run.
    Screenshot from WebPagetest.org with example settings selected for a performance test run.

    You can choose:

    • Test location. Compare the geographical location where your files are hosted to a location halfway around the world!
    • Connection speed. Compare a cable connection to a shaped 3G connection!
    • Capturing video. This is what we’ll be downloading next!

    When you see the results of the test, including a waterfall chart and metrics explaining how long it took for your page to render, you can choose to watch a video of the test, or examine the test results in Filmstrip View.

    How to share in an email

    The Filmstrip View allows you to see a PNG of how your site loads over time with thumbnails of each time interval. There are additional customization options for your Filmstrip so you can best convey the story of how your site is loading over time. Filmstrips are great for showing the performance of your site in a static medium like email.

    Screenshot from WebPagetest.org in Filmstrip View, showing how the site loads over half-second intervals.
    Screenshot from WebPagetest.org in Filmstrip View, showing how the site loads over half-second intervals.

    How to create a video dashboard

    Meanwhile, on the Watch Video page, you have options for downloading and embedding your video. Go ahead and download it, then run additional tests set with other location and connection speed options, and grab those videos, too.

    At Etsy, we’ve saved the videos to a central location and created a simple HTML page that reloads every few seconds to show the videos on repeat. Whenever Etsy’s homepage undergoes a major change, we update the videos manually.

    So how can we target our two main audiences in need of convincing that performance work is important? Create different sets of videos that resonate.

    • Compare your site to your competitors’ sites. Fewer emotions are more powerful than pride. How will the Very Important People feel if a competitor’s site is faster?
    • Compare the before and after of performance work. Want to demonstrate the payoff of performance work to Very Important People? Need to convince your peers that performance work is worth celebrating? Show a page before its performance was improved, and have it load right next to a post-improvement video.
    • Compare the mobile and desktop experiences, and the global experience. Help those around you feel how your users on different platforms, all over the world, experience your site. Choose pages that particular designers or developers you speak with are working on, touching again on that pride point.

    Moving away from raw numbers and graphs and toward showing video may help you in your quest to create a culture of performance. Helping those around you feel the effects of performance on the overall user experience makes it much easier to get the buy-in you need to make your site fast—and keep it fast. Many people have had success convincing their peers and VIPs to care about performance using comparison videos; I can’t wait to hear your success story, too.

  • The Risky Business of Onboarding 

    Introducing potential new users to a product can be tricky. Visitors are just passing by, only willing to interact if they can immediately see a new product’s value. And even if they do sign up, they may not come back. It’s not enough simply to capture an email address—you have to thoughtfully design a process that gets and holds attention, turning new visits into repeated engagement.

    I encountered just how difficult onboarding can be when we decided to redesign our signup process at Blendle, a startup that sells individual articles from newspapers and magazines. Our old signup was full of bugs, falling behind on design changes made in the rest of the product, and, most importantly, both data and our users told us that new users were left confused after signing up. Our redesigns looked good, but I wanted to dig deeper. I wanted to know what makes a truly great onboarding process.

    A 30-day experiment

    I’m a builder. I like fast iterations. I like to ship. I don’t naturally gravitate toward long research processes, reports, complex numbers, and spreadsheets. So to collect as much research as quickly (and interestingly) as possible, I decided to inspect and review one onboarding experience every day for 30 days in a row. The questions I wanted to answer:

    • Is there such a thing as the perfect onboarding experience?
    • What are the most important things to consider when designing and building a smooth signup process?
    • What can Blendle (and everyone else) learn from products that are already out there?

    A month later, I had 30 blog posts reviewing well-known products like Facebook, Twitter, Vimeo, and Instagram, alongside newer products like Botify, Staply, and Meerkat. I took screenshots and wrote down my thoughts for each step in every product. I also built a spreadsheet to quantify the experiences through the number of steps, required fields, supported social media platforms, and other parameters. (While this method obviously would not yield significant and statistically correct data, it is informative, and a huge improvement over decisions based on gut feelings.)

    With that data, I was able to create a framework for onboarding experiences in three stages: identifying, teaching, and engaging. With this framework, you can reevaluate your onboarding experience based on observable patterns, just as we did at Blendle—hopefully attracting, and retaining, more new users.

    Stage 1: Identifying

    If you stripped down an onboarding process as far as you could, what would be the one thing you would keep? The user needs a way to sign up—a form to collect a name or email address, a way for users to identify themselves.

    While the signup form may be the most boring part of your product to work on, a skillfully crafted form can help users set up a new account in seconds, and even bring some joy to their day. Take a quick look at how GitHub is doing this:

    Animated screenshot of GitHub’s signup form, which provides real-time feedback for errors in the username, email, and password fields.

    Notice how I get feedback as I’m completing the fields. It is really gratifying to watch the red error flag turn green when my input is correct. It also gives me really specific feedback about the errors in my password.

    Some products request user identification as a single field, while others use a multipage form. Multiple studies have been done on the positive impact of having a shorter form and how form fields impact conversion. When encouraging potential users to set up a new account, is it really necessary to ask for a birth date or preferred country? Probably not—and short and sweet seems to get better results.

    One way to reduce mandatory fields is to allow users to sign up with a service profile they already have. For example, Prismatic enables potential new users to sign up via their Twitter or Facebook accounts:

    Screenshot of Prismatic’s signup form, showing a choice of social login buttons or email signup.
    Crystal-clear first step: either fill out an email address or pick one of the social networks. No fluff.

    Adding these social login buttons should always be a conscious choice. Research your audience to find out which networks they use, and keep a close watch on your conversion rate to see how it compares to a normal signup. Mailchimp, for example, found that social login buttons didn’t actually help their onboarding process, so they removed them.

    Ultimately, the identifying phase is about determining how much—or ideally how little—information you need from users. Here’s the technique we used to figure out what questions to ask in Blendle’s onboarding:

    • Start by making a list of everything you would like to know from new users.
    • For every field, write down why you need this information.
    • Next, write down why a user would benefit from sharing that data with you.
    • Cross off everything that doesn’t show a clear benefit to both you and your users.

    Alternatively, ask yourself this question: what is the absolute minimum you need to know from your users in order to let them in?

    Evaluate your onboarding process

    • Try to look at your form with a fresh pair of eyes. Are any fields potentially unclear or confusing to new users?
    • Do you absolutely need to know everything you’re asking new users? Could some fields be removed, or reserved for later in the use cycle?
    • Test and validate your error messages. Do they explain what’s wrong and how your user can fix the problem?
    • If a user triggers a validation error on one of the fields, is the data on all other fields preserved? Users don’t like to start over because of a single error.
    • Can you include instant feedback for each field to mark progress and prevent wasted time? This is especially important for users on slower internet connections.
    • Does it make sense to incorporate social media logins for your product?

    Stage 2: Teaching

    Teaching is the second layer of the onboarding experience. Guiding a new user’s first dive into your product helps ensure they aren’t overwhelmed, and that they know how to get the most value out of what you are offering.

    The signup process at GitHub does this well, by keeping things simple and ending on this screen:

    Screenshot of the final screen in GitHub’s onboarding process, showing four additional steps users can take to start using the service.

    Nothing is mandatory here, but they’ve added explanatory content to show new users how to get started. It’s short and can be dismissed with a single click.

    Instapaper’s onboarding uses Instapaper to explain how Instapaper works: they have folded their introduction into an article that appears in the user’s account after a signup:

    Screenshot of the final screen in Instapaper’s onboarding process, showing instructions, in article form, for using the service.

    Since Instapaper is targeted at people who like to read, this seems to be a good fit. It would be even better to have a trigger in place to suggest clicking to read the article, demonstrating the actions for using the service.

    Slack’s onboarding takes that idea even further. An interactive tutorial via Slackbot, the service’s help entity, shows a new user how to complete their profile while also learning how to use the tool’s chat functions:

    Screenshot of a chat window with Slackbot, Slack’s interactive onboarding tutorial.

    Slackbot’s lighthearted, personal tone creates a positive first experience while simultaneously filling out the user’s data fields.

    Evaluate your onboarding process

    • What are your product’s most important or most frequently used features?
    • Which features are the most difficult to use?
    • Which features might make a new user feel comfortable?
    • Can the functionality of your product actually be used to introduce the product or demonstrate its features (à la Instapaper or Slack)?
    • Which feature has the most impact on growing the product?
    • Which feature best shows off the product’s value?

    Stage 3: Engaging

    Finding yourself as a new user in an application with thousands of options, buttons, settings, and tooltips can be overwhelming. Simultaneously, users who haven’t begun to use the product yet can end up in zero data state. This combination can make it really hard for users to discover the value of your product—and keep coming back to it.

    This is an opportunity to separate a great onboarding process from a basic one. By asking a couple of strategic questions while signing up, it is possible to skip zero data state and make the user feel right at home at the end of creating their account.

    For example, Meetup asks new users to select categories of interest at the end of the onboarding process:

    Screenshot of Meetup’s interest-selection stage in their onboarding process.

    Meetup can then use this data to recommend meetups that are most likely to appeal to the user.

    The more data you collect during onboarding, the more you’ll be able to demonstrate value, and the more likely users will return. In other words: a good onboarding might be the very best thing you can do to set yourself up for success.

    Triggers are another potential method for encouraging repeated use. In Hooked, Nir Eyal explains how to build habit-forming products using internal and external triggers. External triggers can be push notifications, emails, overheard conversations, phone calls, Facebook messages, or tweets. Internal triggers, such as wanting to check our inboxes to see if we have new email, originate in our own brains. (If you manage to add an internal trigger, people will return to your product without you having to nudge them.)

    A carefully crafted onboarding helps the user open their account while setting up meaningful external triggers to be used post-signup. Prismatic does this by asking the user to select topics of interest during signup, much like Meetup does:

    Screenshot of Prismatic’s interest-selection stage in their onboarding process.

    They then use this data to send the new user a weekly email with a well-curated selection of articles, encouraging return visits.

    Another way to potentially drive engagement is through social connections. Interactions with friends can be just as meaningful or even better than recommendations based on selected interests. Twitter does this by regularly emailing users with activity from their network. Facebook and Twitter both let users know when someone from their network signs up for their products. The more friends a user has on a shared product, the more relevant and personal their interactions are, and the more likely they are to continue to use the product.

    This brings us to a difficult part in the framework: on the one hand, you want to eliminate as many form fields as possible. On the other hand, you want to collect users’ data and expand their networks in order to enhance their experience. You can balance these competing goals by clearly communicating why you need each piece of data. Keep the complete process as short as possible, but spread out separate questions over multiple pages. Make each step as enjoyable as possible; you might even try adding some meaningful, functional animation where this makes sense.

    Evaluate your onboarding process

    • What information do you need in order to eliminate zero data state?
    • What sorts of external triggers can you build into the product?
    • What data does the user need to share in order to set up meaningful triggers?
    • Can you integrate activity from users’ friends or network to create additional triggers?
    • If you need to collect a lot of data to provide better engagement, can you spread your fields across multiple pages or signup stages? Can you present the information requests in a more engaging way?

    Onboarding never ends

    Screenshot of the first page in Blendle’s onboarding process, showing thumbnails of publications.
    This is the view that greets you when visiting Blendle for the first time. It says: “Good evening! Welcome to Blendle. Which papers and magazines would you like to read?”

    Blendle’s new onboarding process is doing well, with a steady conversion rate of 5 percent (if you’re interested, I wrote a review). Of course, this is not enough for us; we’re continuing to improve and explore how we can keep delivering a delightful experience to our new users. The three-stage framework helps us check our design decisions going forward.

    Onboarding experiences should be continuously improved and updated, just like any other aspect of a product. The fourth product I reviewed during my experiment was Twitter; I hadn’t seen their onboarding since signing up for my account five years ago, and the process felt like it hadn’t changed since. Facebook seems to have the exact same problem. This was a common pattern I saw: the product may be moving forward with great speed, but the onboarding process is left to collect dust because it isn’t deemed as worthy as other, more visible design concerns.

    Take the time to go back to your own product onboarding experience and evaluate where improvements can be made—especially if you haven’t looked at it in a while. Use the questions in the framework to examine how you’re dealing with identifying new users, teaching them how to use your product, and engaging them to return. By reevaluating your process—and ensuring that it continually evolves—you can continue to improve users’ experience with your product from the moment they first encounter it.

  • On Our Radar: Four-and-a-Horse Stars 

    In “Death to Icon Fonts,” Seren Davies makes a strong case for using SVGs instead of icon fonts, which pose problems for people with dyslexia.

    Seren provided several eye-opening examples of accessibility issues caused by icon fonts. I learned, for example, that many people with dyslexia use a special system font that breaks icon fonts. I’m glad that Seren is bringing this topic to our attention and am looking forward to hearing more from her. —Yesenia Perez-Cruz, acquisitions scout

    Your weekend reading

    1. Ada’s List cofounder, Anjali Ramachandran sends out Other Valleys, one of my most-religiously read TinyLetters. Other Valleys focuses on technologies coming from, well, not Silicon Valley and other places we tend to look for “the next big thing.” I don’t know how she does it, but every week (every week!) I learn about some awesome new startup doing interesting, meaningful work. Sign up—you won’t be disappointed. (Oh, and if you want to catch up on past letters, or get a sense of what you’re in for, she has a blog archive of every issue.) —Marie Connelly, blog editor
    2. The web has been buzzing about WebAssembly, a portable format and execution model designed to serve as a compilation target for the web. Brendan Eich, creator of Javascript, discusses misconceptions and explains why we need WebAssembly in an interview with Eric Elliott. —Michelle Kondou, developer
    3. The Responsive Issues Community Group has always aimed to change the rules of web standards, but operates largely outside of the rules itself—and that isn’t fair. What we should be doing is reshaping web standards to match the realities of web development today, not working around them. To that very end, join me in welcoming the brand new Web Platform Incubator Community Group (WICG): a group dedicated to guiding designers and developers from ideas to implementations, and to fixing the way the web standards game is played. —Mat Marquis, technical editor
    4. I love it when people find innovative ways to improve systems and open career paths. Nigerian talent incubator Andela trains developers, provides them with an income and benefits as they learn, places them with Fortune 500 companies, and continues to support them through professional development and coaching. With more funding this year, it’s set to expand into Kenya. —Rose Weisburd, columns editor
    5. There’s a price for the pace of rapid development, and that price is massive technical debt on legacy systems patched with duct tape. (Shiny, modern duct tape, but duct tape nonetheless.) Zeynep Tufekci’s “Why the Great Glitch of July 8th Should Scare You” should, well, scare you. Replacing decades-old systems holds about as much appeal for corporations as promising to fix bridges and tunnels does for political candidates. —Tim Murtaugh, technical director

    Overheard in ALA Slack

    “I’m only into animals riding other animals now.”

    Your Friday gif

    You were saying?
  • The Latest Flash 0-day is no Joke 

    I’m guessing there’s a better than decent chance that you’ve already heard about this, but this is such a bad one I thought I would just make sure: The appropriately-named Hacking Team was hacked earlier this week, and in the 400 gigs of data stolen from them was a previously unknown 0-day Flash exploit. The exploit allows web sites to execute arbitrary code on vulnerable machines.

    The Hacking Team makes a living selling tools that allow their clients, mainly governments and law enforcement, to surveil internet users and snoop on encrypted internet traffic. An important part of their service is collecting unknown exploits and keeping them a secret so they don’t get patched, and can continue to be exploited.

    Flash gets updated a lot, often for security purposes. What usually happens is a security firm, or a hacker looking for a bounty, or Adobe itself will find a vulnerability, and the Flash team will quietly patch their software before the exploit becomes widely known. This time, the exploit is already out there, and is quickly making its way into malware tools.

    So, I assume you’re already multi-tasking and disabling Flash in your browsers. (Here’s how to disable Flash in Chrome. And Safari. And Firefox. And IE.)

    And now you should go patch Flash.

  • This week's sponsor: GraphicStock 

    Graphics, photos, and vectors—oh my! Get a week’s worth of free image downloads from our sponsor GraphicStock.

  • Designing for Non-Native Speakers 

    For the past few years, I’ve worked on sites and web apps that have large user groups of non-native speakers of English. That has given me a chance to look at how they are accepted (or rejected) by people who don’t speak English as a first language.

    Some curious facts emerge when you compare the languages most sites use, versus the languages most internet users speak. While around half of all web pages are in English, only about 28 percent of the people using the internet speak English as a first language. Interesting, right? There are billions of people who use and browse the English web, but are not native speakers.

    Asking for fully translated and localized sites is a mammoth task, one only large international conglomerates can afford. Instead, we can take some other simple steps to make our sites accessible for non-native speakers. We can focus on clear language, interfaces, and prompts, to help users as they navigate a largely English-speaking web.


    A few years back, my coworkers and I were planning the design and launch of a marketing site for one of our new English language courses for adults. We started to gather copy and content. The majority of it described the features of the course and the resources available to teachers. We needed to keep in mind that many of the teachers for this course were not native speakers of English.

    In order to get an objective idea of how complex our copy was, we ran it through the Flesch-Kincaid Readability Test. The test measures how difficult a passage in English is to understand, and assigns a score or US-reading level. You can do this with the “Show readability statistics” tool in Word, or by copy and pasting your content into an online tool. Our marketing copy was topping out around the 13th grade level, meaning you needed at least a year of college to understand what we were saying about our product! We should have been sticking to a level of 6th-8th grade to make sure our content was clear and accessible to our customers. No one wants to stumble through dense text just to get info on a new product!

    In order to remedy this we needed to take a few basic steps, focusing on our copy, and our UI. First, we ran Flesch-Kincaid scores for all the content. We compared the passages that had lower scores with those that came in very high. Based on that, and what our marketing team needed, we decided to go for a reading level of around 9th-10th grade—clear, but not dumbed down for English teachers. We then created a content map, basically a spreadsheet with all the copy, its location in the site, the reading level, and a few other bits of information. For every place the readability was poor, we edited it down and ran it through the test again, until we were satisfied.

    Standardized interface language

    Another area where sites and web apps can trip up non-native speakers is in the interface language. Users with varying levels of comprehension employ all kinds of strategies to understand what they are reading. While there are many standard commands like “save” and “help,” other processes, like “upload image from computer” when written poorly, can be confusing for non-native speakers. We should aim to provide them with simple, standardized commands that they can easily read and remember, wherever they are on the site.

    So how can we do this? I have found that creating a spreadsheet or list of all your interface language and sharing that with your design team is a great way to maintain a sitewide standard.

    This strategy is not only relevant for non-native speakers. All users, regardless of their comprehension levels, need consistent messaging and instructions on your sites and web apps. By focusing first on those with the most pressing needs, you make your site usable for a much wider variety of users.

    Support tools

    Sometimes though, simplified language is not enough. When we pair icons and text, we increase the speed at which recognition happens. It is an attempt to build a common language, one that is less dependent on English comprehension. But this is easier said than done. Look at these icons in Chinese mobile apps, and try to figure out how many you recognize.

    Perhaps we need to offer an additional layer of context in these situations. Let’s start with onboarding. As non-native speakers download and enter your app or site for the first time, it is a great idea to provide small popups or a series of screens with animations to show the functionality. This handholding at the beginning of the experience can provide a sense of clarity and comfort even without a full understanding of the language you are using.

    Tooltips next to key actions can also be helpful. At first glance you may think, “If it were designed correctly, you wouldn’t need tooltips!” which is true for native English speakers. But if, like me, your customers are not always native English speakers, then small, unobtrusive explanations next to key actions can provide that continued layer of help that your users need. Some web apps like LayerVault even use progressive reduction, where increased use means less explicit help is displayed, but if a user returns after a long period away, this contextual support is added back into the UI.

    Non-native speakers of English often need a little extra help to get through English web interfaces. That is OK. If they are a significant part of your customer base, these are some simple ways to support them, making a more powerful online experience possible. Aligning your readability level with your users’ reading comprehension level, standardizing your interface, and expanding the range of help options available to users are all things you can do now—you don’t need to wait until the future when you have the time and money for a complete overhaul of your content. By planning and delivering these discrete steps, you can do a lot right now to help all your users, whether they are native speakers or not.

  • Feedback Phases and Personas 

    A few weeks ago, I released my first solo app on the App Store, Parking. It’s a small project, but I still sought the help of a few friends before launch for testing and feedback.

    Getting valuable feedback is a delicate and very important thing. A little bit of planning ahead of time can go a long way—I don’t recommend sending a beta out to a dozen friends with no thought other than, “Let’s see what they think of it!”

    I structure a few phases of feedback, each with defined goals that help work my way toward the final product. For each phase, I try to provide testers enough guidance on what type of feedback I’m seeking, while trying to avoid restricting their free flow of thoughts.

    A big focus of mine is introducing new testers at each point—continually having fresh eyes on the product helps immensely. It exposes things that users who are familiar with the product will glance over as part of the rough edges inherent to beta stages.

    Beyond the benefit of fresh eyes, I try to map the personas and areas of focus of my testers to the goals of each phase. For the testing and feedback process of Parking, I identified five personality types (with five corresponding phases).

    The domain experts

    These people are masters of the domain in which you’re working—whether that means the platform or environment, or the audience or market you’re targeting. It’s a good idea to have these people helping out from early on (they’re the first group I bring in), because they can validate the core pieces of your work before it’s too late in the process to make major revisions.

    The idea people

    This group is a fantastic follow-up to the domain experts. It’s made up of people who understand what you’re building, and are great at brainstorming everything from an entirely new feature to a smaller, but useful addition. Don’t bring this group in too late either, or else their great ideas won’t see the light of day.

    The meticulous

    These people don’t miss a thing. They evaluate every last detail, every little decision, and will give you a wall of feedback. It’s critical to bring this group in after the core of your product is built and polished with the help of domain experts and idea people, or else this group’s detail-focused evaluations won’t be useful.

    It’s especially important to be respectful of this group’s time—they’re going to put a lot of effort into pouring over your work and providing feedback, so make sure you can put that feedback into action quickly.

    The breakers

    These people can break anything. I’m sure you know a few people like this, if you aren’t one yourself. After polishing the details with the help of the meticulous, have this group help break as much as possible, and then make sure those breakages are fixed, or handled gracefully. This group is the most frustrating by far (in a good way, I promise), but the stability of your product will thank them, and so will you.

    The slightly different

    This is a group of people that will use your product slightly differently than you imagined, or use technology as a whole in a way unfamiliar to you (whether that means different contexts, locations, devices, or something else). It’s a tough group to put together, but it’s vitally important to expand the way you think about what you build. A different way of using technology brings a different perspective. This group will often see that you’re incredibly close to something they would find very useful—something you’re missing out on altogether—and that can open your product up to an entirely new segment of the market. This is the last group I bring in, once core features are implemented, polish is applied, and bugs are fixed.

    Those are the five personas I’ve identified and structured feedback around, though some people may cross over between groups, and that’s great! I often find a strong correlation between the meticulous and the breakers, for instance.

    As always, be pragmatic. Feedback phases matched to personas has improved my process, but your product may call for something different. Find what works for you, but be thoughtful about constructing an environment for feedback that works to make your product better.

  • Rachel Andrew on the Business of Web Dev: Software Audits for the Tiny Business 

    In the dot com boom, I headed up a technical team. One of my responsibilities was the hardware and software needed by our team and other teams in the company. Back then, software was typically boxed and came with packs of licenses. I had an internal software audit routine to check that all of our computers were correctly licensed.

    In my own business, I’m part of a two-person team. Many of our software licenses are purchased far less formally and are for one user only. We also rely on a huge amount of Software as a Service, where there is no box or permanent license to use the service. As owner-managers, we sometimes buy something using a personal email address or bank card, despite it being for company use. Also, we contract third parties to do work for us, and they purchase software or create accounts on our behalf. With no physical boxes, or volume licenses to keep track of, small companies now develop websites and software in a far more informal way.

    It’s a common pattern we see at Perch: the company contacting us has had a website developed, and sometime later the person who developed the site and bought the software license leaves the company. The company has no idea how to access the license information, and password reset attempts go to a now-dead email address. Sometimes the account is linked to a personal email address, or was even bought by a third party who had been contracted to build the site.

    With accounts spread around between owners, employees, and contractors, businesses can easily leave themselves exposed. Services get canceled because no one saw the reminder that a credit card had expired. Domains fail to auto-renew, leaving the company in danger of losing them. Software purchased via an employee or contractor becomes inaccessible due to that person leaving. Therefore, I propose that every business needs a software and services audit. Collate all of this information, then make sure it is accessible to you and other trusted team members.

    What should we audit?

    What should you take a look at? To get you started, I’ve listed a few key areas that most web agencies and software businesses will recognize. Once you start this process, you will no doubt think of more. (If you think of something other business owners might forget, add it to the comments.)

    Domains and DNS

    Does the company own all of the domains you use, or are any linked to personal accounts?

    Can you move all of the domains and DNS management to one location? Services such as DNSimple offer domain hosting and DNS management, and can be a better choice than having domains registered alongside your webhosting.

    Do you have a solid way to track expiration dates? Are domains set to auto-renew with up-to-date payment details? Do all of the domains have correct contact details?


    How many email accounts are being used in your business? Are you, or your employees, using personal addresses for company business?

    Is important and valuable information stored in your email, or in the email of employees? For example, if you work with clients by email, who has the history of the conversations?

    Is email securely backed up?

    Software used on your websites

    Many websites rely on paid software-whether that is a full CMS like Perch, or paid add-ons to WordPress. Who owns those licenses?

    Which email address is linked to these licenses? The developer might use it to let you know of important security updates to the software.

    Do you have access details for any account on the third-party website?

    Do you know where and how to get support for any of the components of your website that haven’t been developed in-house?

    If you develop websites for clients, you may be able to help them to manage this better by providing a handover pack on payment that includes all of the key details and clarifies their significance.

    Recurring payments

    Go through your bank and card statements. What does your business pay for, monthly or yearly? Cancel anything you don’t use.

    For services you do use, check if you can save money and bookkeeping by switching to an annual plan.

    Check that the plan you are on is up to date and still the right one for you. SaaS companies often introduce new levels of service—you might save money or get new functionality by switching.

    Keep a list or spreadsheet of services and the date on which you last checked them. You can repeat this process every six months, to make sure you don’t pay for things that you are not using.

    Start with one small thing

    Auditing everything you use in your business is likely to save you time and stress in the long run, but with our limited time it’s an area we can find easy to avoid. You don’t need to do this all at once. Next time you have a couple of spare hours, pick off one area and start there.

    In a couple of hours you could list all of your domains, check when they expire and make sure that you can access the registration for each. You may need to add another to do to your list to consolidate them at one provider, or to update contact details. However, you have moved forward just by knowing what the status of your domains is. You are already less likely to have the nasty surprise of waking up to find a website offline due to the domain expiring.

    Let me know in the comments if this is an area you struggle with; or if you have found good ways to store, maintain, and share this kind of information.

  • This week's sponsor: TeamGantt 

    Our sponsor TeamGantt wants to help you organize your projects better. Check out their 30-day free trial to get started.

  • Container Queries: Once More Unto the Breach 

    We’re a perseverant crew, the RICG. Responsive images were dead and buried forever in particularly dramatic fashion—what—two, three times there? “Dead and buried forever” refused to stick, though, thanks to all of you. Every time responsive images were knocked down, they got up a little stronger than before.

    It isn’t hard to see why the going was so tough. Changing up a feature as old—and in software terms, as stable—as the img element was no small request. But designers and developers had spoken: we wanted a feature that stood to save our users a tremendous amount of bandwidth, and we carved out a seat at the same table as browser representatives and long-established standards bodies to make that feature happen. It was a long and failure-riddled process, but it’s what got us to the solutions we have today: not just one new element, but a whole suite of enhancements to the img element as well. Now we have options for smarter asset delivery based on any combination of viewport size, pixel density, and file format support.

    After all that hard-won progress, there was no sense in packing up our GitHub organization and going home. We’ve changed the “I” in “RICG” from “Images” to “Issues,” and set our sights high right out of the gate: we aim to change the way we all write CSS.

    The trouble with media queries

    Styling a module meant to occupy multiple containers with viewport-based media queries means scoping that module’s styles to all the containers that it might occupy. That sentence isn’t the easiest thing in the world to parse, but it’s something I’m betting we’re all familiar with in practice.

    The ideal responsive website is a system of flexible, modular components that can be repurposed to serve in multiple contexts. Using pattern libraries and tools like Pattern Lab by Brad Frost and Dave Olsen, we should be able to style the most fundamental parts of a website in a vacuum, assemble them into cohesive modules independent of the page, and then include them in the page layout in whatever contexts they were meant to occupy. But the reality isn’t as clear-cut as it might sound.

    For the sake of discussion, let’s say we’ve been tasked with building a landing page for a store that sells Whitworth-based tools, a measurement system known only to those brave enough—or foolhardy enough—to own a very old vehicle of British make. I count myself among the latter group.

    It’s a pretty simple design. The whole page is made up of product modules that occupy a large central container, and one identical “featured item” module that occupies a secondary container. The overall page layout only changes at a single breakpoint, where the “featured item” container shifts to a sidebar. Here’s a very sparse demo illustrating that layout change. The CSS for this is an easy read:

    .col-b {
    	clear: both;
    	float: left;
    @media( min-width: 960px ) {
    	  .col-b {
    		clear: none;
    	.col-a {
    		width: 70%;
    	.col-b {
    		width: 27%;
    		float: right;

    We really only have to deal with the modules in two different contexts, and only at our highest breakpoint: the primary container and featured containers are the same width until the featured container turns into a sidebar. We’ll put a class of .featured on that container so we can scope our styles to it later on.

    Now that we have the page layout squared away, we can focus on the layout of the individual modules. They’ll switch between a vertical and a horizontal layout, whichever is best for the available space:

    The vertical layout really doesn’t need much finessing in CSS. The natural flow of our markup does most of the work for us; we’ll just make a few small tweaks to constrain the size of our product images and center them beyond that size:

    .mod img {
    	display: block;
    	margin: 0 auto;
    	width: 100%;
    	max-width: 250px;

    The styles for the horizontal layout aren’t too much harder. For now, we’ll focus on the primary container—so we won’t scope these styles to our .featured class. Since we want the modules to go back to the vertical layout above 800px for the three-across layout, we’ll only apply the horizontal layout styles between 400px and 799px:

    @media( min-width: 400px ) and ( max-width: 799px ) {
    	.mod img {
    		float: left;
    		width: 30%;
    		max-width: 999px;
    	.mod .mod-header,
    	  .mod .mod-desc {
    		float: right;
    		width: 68%;
    		padding-left: 2%;

    Here’s how those styles play out in a real page. They work just fine, up to a point—in our “featured item” container, where there will only ever be one module at a time, things fall apart a little at medium breakpoints:

    Not ideal, but fixable. We’ll just write a new media query to overlap with the one we wrote for the modules in the primary container, then scope all our styles to the .featured class we put on that secondary container element:

    @media( min-width: 40em ) and ( max-width: 60em ) {
    	.featured .mod img {
    		float: left;
    		width: 30%;
    	.featured .mod .mod-header,
    	  .featured .mod .mod-desc {
    		float: right;
    		width: 68%;

    Well, okay. This works just fine—as you can see here—but it’s a little gross, code-wise. Not a DRY approach to writing CSS, by a long shot.

    This is still bearable when we’re working with such a simple design, but it can get a lot worse when we start fine-tuning details. For example, the vertical layout calls for the “add to cart” button to appear on the right side of the module, but there isn’t enough room when we switch to the three-across layout at medium breakpoints:

    If we finesse our styles so the “add to cart” and “quantity remaining” modules deliberately break below the product prices at these sizes—aligned to the left, instead of floating in space on the right—our stylesheet tangles a little more.

    Switching between left and right alignment for these elements is simple in terms of the styles themselves: we’re really only dealing with text-align and float properties on the “quantity remaining” and the “add to cart” button. For the media queries that control those simple styles, though, we have a whole list of considerations to work around. We’ll need to add two breakpoints to both of the existing breakpoints that handle vertical alignment. Those styles will impact our “featured” module as well, so we’ll need to override those new styles using our scoping class, with media queries to match. Since the featured module has a little more space to work with than the modules lined up three-across, the “add to cart” button can move back to the right sooner in that context, at the highest breakpoint—yet another breakpoint. But wait, there’s more: these styles aren’t future-proof. If we should ever want to add a module to a new context, we’ll have to copy and paste all our styles over again, with a new scoping class and a fistful of new media queries. If the size of the page layout changes in any way—more or less padding, margins, any size-based styling change to the layout elements—we’ll have to adjust all of those many, many media queries. We now have to find a new viewport size where our breakpoints make sense. Our decisions are disconnected from our layout.

    This page comes nowhere near the level of complexity we might encounter in a real project, but we already have a tough stylesheet to maintain.

    Enter element queries

    All this complication comes from our reliance on the viewport to make our styling decisions. Media queries work just fine for our high-level page layout, but they’re nowhere near as useful for modular components. What we really need is the ability to style page components based on the space they occupy rather than the size of the viewport.

    “Element queries” assume a syntax that does exactly that. We’re accustomed to writing a media query for styles that apply only when the viewport is greater than 40em, like this:

    @media( min-width: 40em ) {

    Instead, imagine a syntax where the query itself is scoped to an element and populated with styles that only apply when that element is larger than 40em:

    .mod:media( min-width: 40em ) {

    Well, this would change almost everything we’ve written for our Whitworth page so far. We might still use media queries for our page’s one major layout change, where we go from a linear layout to a larger primary element and a sidebar; basing that on the viewport size makes sense. Once we started building our modules themselves, though, this new syntax would allow us to write all the styles they could ever need just once:

    .mod img {
    	display: block;
    	margin: 0 auto;
    	width: 100%;
    	max-width: 250px;
    .mod:media( min-width: 425px ) img {
    	float: left;
    	width: 30%;
    	max-width: 9999px;
    .mod:media( min-width: 425px ) .mod-header,
    .mod:media( min-width: 425px ) .mod-desc {
    	float: right;
    	width: 68%;
    	padding-left: 2%;

    That’s it, those are all the styles our module layouts will need—see for yourself in this demo, which uses a JavaScript shim to make this theoretical syntax work for real. When the module is larger than 425px, the browser uses the horizontal layout. If the module is smaller than 425px, the browser uses the vertical layout. The styling is now 100% dependent on the container that the module occupies—if it has enough space for the horizontal layout, those are the styles that get used. If we changed the three-across layout to two-across with each module occupying half the container, or we introduced a completely new and unpredictable context for one of these modules, we wouldn’t need to change a thing about their styling. Imagine how much more useful a pattern library would be if we removed the contextual dependency from these kinds of standalone modules: you’d be able to grab any component from the page and move it to any container in the page, without needing to rework hundreds of lines of CSS—without reworking any CSS at all.

    For fine-tuning details like the position of the “add to cart” button and quantity remaining, things wouldn’t really get any more complex. Since we wouldn’t be dealing with scoping or finessing module breakpoints to match the viewport-based layout breakpoints, we’d only have one concern: “Is the module too small to have the price and ‘add to cart’ button side by side?” A little experimentation tells us that there’s enough room for both elements as long as the module is larger than 320px, and that’s where we’ll put our module-based breakpoint:

    .mod:media( min-width: 320px ) .mod-cost {
    	float: left;
    .mod:media( min-width: 320px ) .mod-buy {
    	float: right;
    .mod:media( min-width: 320px ) .buy-remaining {
    	text-align: right;

    From dozens of lines of redundant CSS, media queries, and overrides to nine lines containing the styles we need. More important, nothing would break if any other styles on the page should change. You can try this out for yourself by fiddling with styles in your browser’s dev tools in this demo, which is using a script that mimics element query behavior—it isn’t something you’d want to use on a production website, but it’s a great way to get your head around the concept.

    If this syntax existed, we’d be finished with this Whitworth project in just a few lines of CSS.

    But element queries can’t exist—at least, not the way we’d been thinking about them. Just like the first version of the picture specification, element queries are dead and buried forever. But like the search for responsive images, we’re not about to let that stick—not when we have such a clear problem to solve.

    Exit element queries

    This concept isn’t a hard sell—not for us developers, anyway—but neither were responsive images. Once we get into the gritty implementation details, though, things change.

    The first step for the RICG was framing out a Use Cases and Requirements document for element queries, describing and diagramming the problem—not proposing a solution, just providing a clear problem to be solved. So far it’s shaping up to be a lot more focused than the Use Cases and Requirements document for responsive images because it really only sets out to solve one overarching issue.

    As word of this document got around, people started thinking through the problem a little further, just like we’d hoped. That led many of us to the same conclusion, before we’d even started tinkering with a proposed specification: element queries can never work.

    This has been documented in more detail elsewhere, but the gist is this: we’re using CSS to control CSS, and that means we can cause infinitely looping style changes. If we can tell an element to restyle itself using an element query, what happens if we use that element query to change the element’s width to one where the element query no longer applies?

    .our-element:media(min-width: 500px) {
    	width: 499px;

    Well, since the query no longer matches, the new width is no longer applied. Since that new width is never applied, the element query would match again, so the new width would be applied, so the query would no longer match, so the new width wouldn’t be applied—and so on unto infinity. We’ve achieved a TARDIS-caliber paradox with just a few lines of CSS, and there’s no predictable way for the browser to handle it. Should the browser, upon encountering one of these situations, throw the element query styles away entirely? Only throw away the new width? Uninstall itself from the user’s machine? Start a small-to-medium-sized fire? Nothing sounds particularly appealing about any of this, least of all from a browser maker’s standpoint. They’ll never let something with this kind of error potential see the light of day. Game over.

    Exciting news, right? We figured out that element queries were impossible in a fraction of the time it took to figure out that responsive images were impossible. The first time, I mean.

    Okay, hear me out on this. “Element queries” are over, sure, but the problem hasn’t changed—the Use Cases and Requirements document isn’t going anywhere. This still needs to be solved, and now we know how not to solve it: elements can’t be restyled based on their own properties.

    Enter container queries

    To solve the problem outlined in the Use Cases and Requirements document, we need to reframe the way we talk about a potential solution. Since a solution can’t allow an element to restyle itself, we can build that constraint into the specification: queries attached to an element can only influence the styling of that element’s child elements.

    Armed with our new knowledge of the impossible, the search for element queries has been reframed as container queries.

    What would this change about our Whitworth project? Well, nothing—we were only styling the child elements of .mod anyway, not .mod itself. It might just mean a few behavioral changes in terms of how the browser treats these elements. The browser couldn’t allow an element with an attached query to be influenced by the size of its child elements, for example. We might end up with an implicit browser-level overflow style on any element with a query attached, to prevent the infinite looping behavior—much more predictable than the browser picking and choosing bits of our stylesheets to avoid melting down.

    So, how do we keep things moving forward from here? By finding the next impossible-to-solve issue. So far, “container queries” have held up to more scrutiny than “element queries” did—but talk is cheap. This recursion issue is a big one, but it still only scratches the surface of the potential issues we could run into as a solution starts to materialize.

    We’ll make a lot more progress by experimenting with this pattern, which isn’t the easiest thing to do when we’re dealing with syntaxes that don’t exist yet. That’s how we ended up with the very first version of Scott Jehl’s Picturefill, lo those many years ago. Without tinkering—without actually using something resembling the picture markup pattern—we couldn’t make much sense of the spec we were just starting to write. So in the same vein, the RICG has started up a repository for container query demos, using the same shim as our Whitworth demos. Now we can all try this syntax out for ourselves, and help find the issues we’ll run into when using this kind of CSS pattern for real—the sorts of problems you can only find by building something. Clone the repo, copy the demo-template directory into /demos, give your demo a name, and build something using container queries. Be sure to let us know how it goes, whether good or bad.

    Exit container queries..?

    As the first version of the container query spec comes together, well, its days may very well be numbered, too. The Use Cases and Requirements document isn’t going anywhere, though; the problem we need to solve is out there, looming, demanding that it be solved somehow.

    The answer may be this very first proposal, for all we know. It might be something completely different—something we haven’t even begun to consider. But the RICG isn’t a decision-maker in the world of web standards, and we don’t aim to be one. We want to be a rallying point—to provide ways for designers and developers who might not want to wade through arcane listservs and IRC channels to get involved in the standards that affect their daily work.

    There’ll be plenty more work to do after this, and we’ll need all of you to get it done. With your help—with thousands of designer and developer voices contributing to the search—it’s only a matter of time until we find the answer together. We’ve done it before, and we’ll do it again.

    Stiffen the sinews; summon up the blood. Banish the phrase “element queries” from your vocabulary forever. Let’s get to work on container queries, regardless of what name or form they might take in the future.

  • Create a Content Compass 

    Project types

    Chapter 2 mentioned that breaking off a small project might make sense, rather than tackling all the content across your organization at once. Make sure you remember where your project falls in your organization or client’s entire content universe.

    Your project’s place in the organization’s content universe affects what you’re able to control or influence. It also is affected by the formal and informal strategies guiding content efforts throughout the organization.

    Content strategy for an entire organization and across all channels is super complex and very steeped in business management and operations. For the purposes of this book, I focus on the three main project types I’ve encountered most: function, property, and subset.


    Function refers to a functional unit within an organization, such as sales, marketing, communications, customer service, or human resources. Of course, every organization is set up a bit differently, so yours could have different names for similar functions.

    Very often, my client is a senior leader within one of these functions who wants help with content strategy across all the content types and delivery channels. Marketing is probably the most common.

    Diagram showing that customer experience is an example of a functional unit within an organization.


    Property refers to a single digital destination, such as a website or an application, or even a social media channel, such as Facebook. Most of my digital property projects are for new website launches or existing website refreshes or redesigns. They could be a client’s primary web presence or a secondary web property for a product, service, event, or other singular purpose.

    Other times, I’ll be asked to help specifically with a mobile site or mobile application. (Don’t get me started on mobile websites, but do read Karen McGrane’s book, Content Strategy for Mobile.)

    Diagram showing how a website is an example of a single digital property targeted for a project.


    Subset refers to any defined portion of content on a digital property. You can define that subset by where it lives in the site, such as the Help section or the About Us section. Or, you may define it by whom the content is for (current customers, prospective customers, and so on) or what the content is about (products, company information, area of expertise, and so on).

    Diagram showing how the help section of a website is an example of a subset of digital content.

    Core strategy statement

    The core strategy statement is the central component of your content compass. It answers the fundamental questions for providing the right content, to the right people, at the right time, for the right reasons. Table 11.1 summarizes the four questions a core strategy statement must answer.

    Content product What content should we produce, procure, curate, and share?
    Audience Who, specifically, is that content for?
    User needs Why do those audiences need or expect that content from us?
    Business goals What outcomes does providing this content help us achieve?

    Table 11.1 Core content strategy statement questions

    What does a core strategy statement look like?

    Core strategy statements come in many formats, and there’s no one right way to document one. A few key characteristics and concepts will help you craft an effective statement.

    First, it must resonate with and be memorable for the people who need to know and use it so that they can apply the key concepts to make content decisions.

    One way I’ve tested my statements is to present them to my colleagues with details about the four questions they answer and then ask them to recap the strategy. If people who don’t have much context for the project can get the gist and explain it back to me, it’s usually in pretty good shape.

    Second, it needs to be prescriptive enough to allow you to say no. One way to check it is to look at your past 10 content projects. If you would have decided not to do some of those projects if you had had the statement at the time, it’s probably strong enough.

    Let’s look at an example that my boss and CEO of Brain Traffic, Kristina Halvorson, has used in presentations (I changed it up a little).

    To reduce customer service center costs, we will provide user-facing, task-based support content that makes our professional customers feel confident when configuring products for their clients.

    Now let’s break that down a bit into the four key components. The business goal for this project is to decrease service center costs (by allowing people to self-serve). To do that, they’ll produce user-facing content that’s focused on tasks users want to complete. The content’s audience is the professional customers, meaning people who are quite experienced and who install the organization’s products for clients. The user need provides help with those installations.

    The strategy statement with portions mapped to the business goal, the content product, the audience, and the user needs.

    Next up, use the statement to make some content decisions. Use the list of content projects and ideas, such as in Table 11.2, and decide whether your organization should do them.

    Yes No Idea
        Repurpose word-for-word content from the customer service call center knowledge base.
        Reorganize help content based on analytics data about frequency of use and search terms.
        Display an interactive timeline showing how product X was developed on the help landing page.
        Conduct user interviews of a survey with professional customers to find out if they are getting what they need from help content.
        Feature professional customer profiles throughout the help section.
        provide a video from our CEO about how important it is for customers to be able to self-serve on our site.

    Table 11.2 Ideas for consideration

    Here’s what I decided and why:

    • No to repurposing knowledge base content word for word because the internal knowledge-base content probably isn’t written in a user-facing way.
    • Yes to using analytics to reorganize the help section because that data can help ensure the content is organized the way users think about the content.
    • No to the interactive timeline because, while interesting, it would get in the way of tasks the user wants to complete while looking for support content.
    • Yes to doing some user interviews because finding out what’s working and not working from a user perspective could help make the content more useful.
    • No to featuring profiles about professional customers throughout the help section because it’s not the kind of information users would be coming to the help section to read.
    • No to the video message from the CEO because demonstrating the care for self-service is more important than talking about it.

    How do you craft a core strategy statement?

    The best part about putting together your core strategy statement is that you already have all the information you need from the discovery phase. Even better, your stakeholders have already agreed on the important aspects: who the content is for, why they need it, and what the organization is trying to achieve.

    Now you just need to put all that together and add some specificity about the kind of content to produce, through either a collaborative or individual approach.

    Collaborative approach

    With the collaborative method to crafting a core strategy statement, you hand out a Mad Lib worksheet to the stakeholders. They then work individually to fill in the blanks. This is one I’ve adapted from a version Sara Wachter-Boettcher created:

    <Organization, Department, Property, Section> helps our company accomplish <this goal> and <this goal> by providing <descriptive phrase> and <descriptive phrase> content that makes <this audience> feel <this emotion or adjective> and <this emotion or adjective> so they can <complete this task> or <complete this task>.

    If I’m doing this exercise in-person, I have each person read their statement out loud with no discussion. Then, I’ll ask them to talk about the similarities and differences, the words or phrases that resonated most or didn’t seem quite right, and anything else that stood out to the group.

    From there, I take a stab at combining everything into a single statement and getting agreement from stakeholders on the aggregated version. You don’t need to wordsmith it at this point; just get the concepts down. You can make it an editorial masterpiece later (or not).

    If you have time, brainstorm a list of recent content projects, and ask participants to say whether they would still do the projects given the statement they just created together. This is a great way to demonstrate how it works and set expectations about how it might affect future work.

    If you can’t get the group together, you can send the Mad Lib out via email to stakeholders. The first time I did this, I was skeptical, but it actually worked fairly well.

    You don’t get the benefit of the resulting discussion with the email approach. But you can go back to stakeholders to work through disagreements before you.

    Individual approach

    Some projects don’t have enough days in the timeline or dollars in the budget to craft the statement collaboratively with stakeholders. That’s OK. You can do it yourself.

    I’m more of an internal processor of information, so my method is typically to grab my notebook or insights spreadsheet and start reading through my notes. I jot down the things that stick out related to content, audience, business goals, and user needs. I’ll start writing multiple versions of the core strategy statement until I feel I nailed it. That usually involves several renditions and pieces from each getting pulled together, edited, discarded, and massaged.

    That approach works for me, but sometimes I get stuck and need to do something a bit more methodological. In those cases, I still grab my notebook or insights spreadsheet.

    But I transfer the key insights to sticky notes, note cards, or slips of paper. Then, I categorize those insights into the four categories: business goals, content product, audience, and user needs. Next, I review each category to see what key themes or ideas emerge. And finally, I take those themes and work out the core strategy statement, which typically goes through several revisions.

    Diagram of the process of crafting a strategy statement, showing how stakeholder insights are categorized, enabling themes to emerge, which lead to the statement draft.

    Messaging framework

    A messaging framework clarifies what you want your audiences to know and believe about you, and tries to prove that this message is true.

    As a component of your content compass, the messaging framework helps ensure that every piece of content you create supports the framework. If it doesn’t, it doesn’t belong or needs to be revised.

    What does a messaging framework look like?

    As with a core strategy statement, you can document your messaging framework multiple ways. I tend to create something somewhat visual to show a hierarchy or progression. Other practitioners I know use bulleted lists.

    I write the framework from the user’s perspective. Other practitioners write it in the organization’s voice. It really doesn’t matter, as long as you adhere to the following:

    • Make sure everyone who needs it has it.
    • Actually use it to make decisions about content.
    • Keep in mind that the messages are for you and the people in your organization who work on content.

    One of the reasons I like to write the messaging framework from the users’ perspective is because it’s a nice foil to the core strategy statement. The core strategy statement is primarily written for the business. By writing the messaging framework from the users’ mindset, you have a well-rounded compass by which to set the direction for content and stay on track over time.

    This example builds upon the core strategy statement and details the first impression you want professional customers to have when they visit the support section, why your support section is valuable to them, and how you’re demonstrating that value with your content. Notice that the proof statements are related to what the content communicates and how it’s organized (substance and structure).

    Diagram showing an example of a messaging framework, progressing from first impression to value statement to proof.

    How do you develop a messaging framework?

    You probably won’t be surprised to read that you can do pretty much the same things you do for the core strategy statement. Like right down to the collaborative and individual approaches.

    Mad Libs, again, work well in a collaborative setting. Some ideas for Mad Libs to have stakeholders fill out for each component of the framework include:

    First impression
    When a user first lands on the site, we want them to feel <blank> and <blank>.

    Value statement
    After spending a few minutes on our site, users should feel <blank> because they understand we provide <blank> and <blank>.

    Our content demonstrates that we provide just what our users need because <blank>, <blank>, <blank>, and <blank>.

    Once you’ve collected the Mad Libs, you can use the data to determine the patterns and themes and form those into the message framework. I go through that process in much the same way I create the core strategy statement—either processing the information in my head or using sticky notes to organize the data.

    If you’re not able to get input from your stakeholders in the form of the Mad Libs, don’t worry. Chances are, you have all the information you need from your stakeholder interviews.

    Grab your notebook or discovery insights spreadsheet. Better yet, do the Mad Lib and use your discovery insights to develop your messaging framework.

    Show the way

    Now that you have the two key components of your content strategy in place—core content strategy and messaging framework—you can tell your content people about them. Schedule some time with the key teams who work on content—from creating it to reviewing it to publishing it—to go over your content compass and how to use it.

    The next chapter discusses developing a plan for measuring the effectiveness of your content strategy and resulting content efforts. Your content compass will help you decide what to measure.

    Copyright © Brain Traffic, Inc. and Meghan Casey. All rights reserved by Pearson Education, Inc. and New Riders.

  • On Our Radar: Precious Humans 

    Molly Holzschlag is a great educator, tough fighter, and vital friend of what folks are now calling “the open web,” and she needs our help.

    Molly Holzchlag and Jeffrey Zeldman
    Molly Holzchlag and Jeffrey Zeldman.

    She took over as project leader when I left The Web Standards Project in 2002. In that role, Molly did hugely important (and often thanklessly unheralded) work bringing improved compliance, plus a renewed respect for web standards, to some famously intractable browser companies. She also directed The Web Standards Project’s important and multi-dimensional educational outreach effort.

    Between those efforts, her two decades of public speaking, and the dozens of web development books she has written, Molly has contributed meaningfully to the foundational thinking and understanding of tens of thousands of web developers, designers, and engineers. If you don’t know her name and her work, you don’t fully understand this industry.

    Molly has been diagnosed with chronic pancytopenia, a life-threatening blood disorder, and her insurance is about to disappear. She’ll need the support of friends and strangers to afford lifesaving blood treatments and medications. Pray for her, chant for her, help her if you can. —Jeffrey Zeldman, founder and publisher

  • Your weekend reading

    1. I’m a big fan of the Library of Congress Flickr feed (mostly for the old-timey photographs of the type that Shorpy cleans up and posts) and recently they’ve been posting old graphic posters from the collection. Like this poster for a 1938 photography exhibition in New York City. The description for each piece links back to the Library of Congress, where they often have very high-resolution images available to download. —Mike Pick, creative director and designer
    2. This week, Wired talked up new startup Doxa, which aims to use an “OKCupid-like” algorithm to match women with tech companies where they’re likely to thrive. It’s an interesting approach to getting beyond “diversity” percentages, and it’s nice to see Wired lead with the truth: “Tech has a diversity problem.” But I was more convinced by Danilo Campos’s take: that “shoving underrepresented people into the existing startup order”—even using smart algorithms—won’t make those organizations actually ready to support diverse employees. “If you’re serving at a place where no one in leadership understands your needs, getting accommodation for those needs can become challenging—or even alienating, when you’re misunderstood,” he writes. In other words, crunching survey data to help women find a better fit might be nice, but real change happens when leadership teams are as diverse as the people they’re trying to hire. —Sara Wachter-Boettcher, editor-in-chief
    3. Richard Rutter has Kickstarted a book he’s writing on web typography. I remember first reading an article Richard wrote for us on the topic back in 2007, and this book has been in the works since before then. Richard lives and breathes this stuff: he helped set up Fontdeck, and has also run several installations of Ampersand Conference. I have a feeling this book is going to be the canonical reference on web typography for years to come. —Anna Debenham, technical editor
    4. I was doing some reading on SVG this week for a project we’re working on. I came across Jake Giltsoff‘s SVG on the Web, a single-purpose site outlining the use of the SVG format. Giltsoff went into quite a bit of depth, addressing the use of SVG as an image type from a development perspective, and responsive approaches to using the format. It’s a bookmark-worthy resource for in-depth or at-a-glance referencing. —Erin Lynch, production manager
    5. I was privileged to hear Leslie Jensen-Inman speak last week, and she explained how adding a single question to the daily stand-ups at Center Centre has helped the team create an environment that is enthusiastically supportive of ongoing learning. “What is the most important thing I learned since the last time we met and how will what I learned change the way I approach things in the future?” In Leslie’s Meet for Learning, she goes into more detail about the ways this open-ended question has changed their work culture for the better. —Aaron Parkening, project manager

    Overheard in ALA Slack

    “I watched a chipmunk suck water out of my friend’s Camelback at the Grand Canyon.”

    Your Friday gif

    A glitchy image of a screen that says “Learn to Use the Internet, Level 2”
  • Rian van der Merwe on A View from a Different Valley: Unsuck the Enterprise 

    There’s something strangely appealing about trying to make enterprise software not universally despised. I guess I believe in a utopian vision where enterprise software is useful, usable, and (gasp!) enjoyable.

    But until we get there, I think we can all agree that enterprise software mostly still sucks. And I think it sucks mainly for two reasons:

    1. A lack of empathy for end users.
    2. Too much legacy.

    The lack of empathy issue is an understandable outcome of the process. See, we have this piece of software that we sell to company leaders, who care about things like control, configurability, compliance, and how many features the thing has. But the piece of software is mostly used by people who have very different needs.

    The people who use the software every day only care about one thing: getting stuff done effectively. And if they can’t do that, a really ugly death spiral happens. As more people realize they can’t get anything done with the software, fewer people want to use it, until eventually no one uses it anymore.

    In short, a buyer-focused product strategy builds for features and timelines. A user-focused product strategy builds for the Job-to-be-Done. Those are very different things.

    Second, there’s too much legacy that drags large corporations down. There are waterfall processes masquerading as “agile,” well-established and well-defended functional silos, and many layers of bureaucracy. The result is something Jon Kolko sums up well in “Dysfunctional Products Come from Dysfunctional Organizations”:

    The dysfunction in the organization becomes the dysfunction in the product, and that gets passed on to the customers.

    How can we unsuck this predicament? Four things have helped me, and continue to help me as we make this transition toward designing in leaner, more empathetic ways.

    Show the business value of design

    The 2014 Design Value Index report just came out, and it showed something quite compelling about design-led companies:

    The Design Value Index (DVI), a market capitalization-weighted index comprised of design-driven companies, shows … 10-year returns of 219% over that of the … S&P 500 from 2004 - 2014.

    Good Design Drives Shareholder Value

    From “Good Design Drives Shareholder Value” by Jeneanne Rae

    So we know design-led companies make more money. But is it also possible for design to save on development costs?

    This chart is based on data from the book Software Engineering: A Practitioner’s Approach, and it shows how much cheaper it is to make changes to software before or during development. This quote from Marty Cagan also makes the point really well:

    Instead of using one prototyper for a few weeks, [many companies] use the full engineering team for full release cycles to build the software that is then QA’ed and deployed into production systems. This is why it typically takes so many companies three or more releases over one to two years to get something usable and useful. They are using the engineering organization to build a very, very expensive prototype, and they use their live customers as unwitting test subjects.

    This is a way to tie user-centered design to both revenue increase and cost reduction. That’s an essential (and compelling) combination to get people to take design and user empathy seriously.

    Shrink user-centered design to fit

    The biggest reservation that teams at enterprise software companies usually have about research and user experience work is that it takes too long and costs too much. Our job is to show teams that we can still get enormous value from UX methods, even if the budget is relatively small.

    That’s the beauty of user-centered design: it shrinks to fit. Can’t do an ethnographic study? Do some phone interviews. Can’t build out a full HTML prototype? Make a clickable prototype in Axure, or heck, make a paper sketch. Can’t do a full usability study? Go to Starbucks Stumptown¹ and ask someone if you can buy them a coffee in exchange for some feedback:

    Big budgetMedium budgetSmall budget
    ExploreEthnographic studyPhone interviewsAsk a friend
    PrototypeHTMLClickable prototypePaper sketch
    User testingFormal usability testingRITEShow someone at a coffee shop

    Turn sales into a product design function

    This is a big one. I’ve seen enough animosity between sales teams and product teams to last a lifetime. And both sides usually have legitimate points.

    Product teams usually complain that the sales team sells stuff that doesn’t exist in the product—and even worse, promises release dates—which means they have no flexibility to base their roadmaps on user feedback and strategic direction.

    Sales teams usually complain that product teams don’t see them as partners, and ignore their feedback constantly. This is a huge mistake, because sales teams often know the product’s capabilities and shortcomings the best of anyone in the organization. They should absolutely be part of the development process.

    How do you do this? What’s worked for me is to provide a framework that allows both teams to speak a common language. For me, that framework, is Jobs-to-be-Done, and more specifically, the Product Forces Framework.

    Product forces diagram, based on jobstobedone.org

    For someone to move from their existing behavior (a product they’re currently using) to new behavior (switching to a new product), there are two types of forces at work: progress-making forces, and progress-hindering forces.

    Progress-making forces move people from their existing behavior to the new behavior, and consist of the push of the current situation (things they’re not happy with in the current product) and the pull of the new idea (things that sound appealing about the new product).

    Progress-hindering forces hold people back from switching to new behavior. They consist of allegiance to the current behavior (things they really like about the current product) and the anxiety of the new solution (worries about learning curves and not being able to accomplish their goals with the new solution).

    For someone to switch from an existing product to a new product, the progress-making forces have to be stronger than the progress-hindering forces. This might seem obvious, but applying this model to your product planning can inject an extremely healthy dose of reality. Is the product really that much better than a current solution? What does the new product have to do to overcome people’s allegiance to what they’re currently using?

    This is not only a very good sales strategy, it’s also a good way to gather product feedback and come to agreement on what will make the product better (and help it sell better!).

    As for putting a stop to selling features that don’t exist yet… I’ll be honest, that can take some time. But the more the sales team and the product team collaborate (keep reading for more on that) and have a common language, the better this will get as well. There is hope.

    Break down silos through collaboration

    “Collaboration” has become a pretty overused word, and it’s now difficult to know exactly what we mean by it. So let’s be clear: just because you sat in a meeting with a different team doesn’t mean you collaborated. Collaboration, to me, means that you made something together. There is always some output during collaboration—from a solid idea that a designer can go work on, to personas that everyone worked on together, to piles of sticky notes that eventually become a customer journey map.

    This kind of collaboration is especially important in the enterprise, where a designer’s role is often mostly about facilitation.

    There are several techniques to encourage real product collaboration:

    • Product discovery aligns teams on the user needs, business goals, and core competencies of the organization. It then goes through a process of divergent thinking (trying as many options as possible to solve a problem) and convergent thinking (narrowing down to the best options). The process also lets a team build consensus about the most important things to work on. For more, see my A List Apart article “Usable yet Useless: Why Every Business Needs Product Discovery.”
    • Design studio gives teams an opportunity to try a wide variety of design options, and come to an agreement on the best solution to go with. It uses the entire team to iterate quickly to a hypothesis that can be prototyped and tested with users. For more on how to run a design studio, see Design Studio Workshop: Adding Up the Benefits.
    • User research might seem like a solitary sport, but it’s not. Taking team members along on field visits and usability testing gives them a real sense of how users interact with the product. It also has the power to make them depressed about how difficult something is to use. But most people break through that really quickly, and move on to solving the problem effectively.

    If I can further summarize a way to bring empathy-driven design to an enterprise, here are the methods that I try to communicate to teams I work with:

    1. Show them why it’s important.
    2. Show them it’s not going to make their lives difficult.
    3. Give them a framework that covers the whole product.
    4. Make them part of the process.

    So if you’re someone who works in enterprise software, come a bit closer—I need to tell you something…

    I know the work can be difficult. I know there are an infinite number of factors involved in getting product live, and sometimes what gets launched isn’t what you had in mind. I know there are sleepless nights about this sometimes. But don’t give up. Don’t think that enterprise design has to be boring or tasteless. With a little bit of effort and a lot of tenacity, it’s possible to create great enterprise product. We need you to make it happen, though. Who else is going to do it?


    • 1. Gotta represent Portland!
  • This week's sponsor: Squarespace 

    Websites for designers, by designers. Our sponsor Squarespace is offering readers 10% off with code ALISTAPART.