Mixing Color for the Web with Sass

Source: A List Apart

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

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

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

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

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

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

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

A hex on hex codes

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

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

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

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

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

Hypothetical site for Gullfoss Travel Supply Co.

Hypothetical site for Gullfoss Travel Supply Co.

Take, for example, this button:

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

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

Traditionally, I would write this in CSS like so:

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

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

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

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

Packing up the color picker for Sass

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

lighten($toolbox, 20%);

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

darken($ol-blue, 30%);

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

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

x = 100% - l

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

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

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

When darkening our colors, $toolbox turns black faster than $ol-blue, because it has a lower base lightness value.

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

Proportional palettes with color scaling

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

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

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

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

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

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

Table showing that when scaling the lightness of our colors, they become proportionally lighter, and therefore more predictable.

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

The darker variations are proportional, too.

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

	background-color: $toolbox;  // fallback
	background-image: gradient(
		scale-color($toolbox, lightness: 50%),
		scale-color($toolbox, lightness: -30%);

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

	background-color: $ol-blue;  // fallback
	background-image: gradient(
		scale-color($ol-blue, lightness: 50%),
		scale-color($ol-blue, lightness: -30%);

	background-color: scale-color($ol-blue, lightness: 50%),  // fallback
	background-image: gradient(
		scale-color($ol-blue, lightness: 60%),
		scale-color($ol-blue, lightness: -20%);

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

Mastering color with mixing

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

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

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

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

mix(black, $toolbox, 30%)

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

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

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

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

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

Color table showing that tinting with a yellow highlight gives the palette a sunnier appearance.

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

Shading with a complementary shadow makes the palette feel more natural.

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

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

New $highlight and $shadow colors.

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

Table showing that a change to the highlight and shadow colors is automatically reflected in your color palette when the Sass is compiled into CSS.

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

Highlights and shadows can be tweaked to achieve just the right mood or story for your site, without making tedious changes throughout your stylesheets.

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

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

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

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

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

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

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

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

Additional considerations for developing your palette

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

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

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

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

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

Read the full article


This week’s sponsor: Pantheon

Source: A List Apart

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

Read the full article


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

Source: A List Apart

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

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

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

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

Slumpy in Seattle

Dear Slumpy:

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

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

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

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

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

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

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

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

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

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

Read the full article


Writing CSS on Growing Teams

Source: A List Apart

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

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

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


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

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

Code review

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

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


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

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

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

Read the full article


Matt Griffin on How We Work: Balancing the Scale

Source: A List Apart

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

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

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

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

Go big or go home

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

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

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

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

Ben Callahan had a similar experience with Sparkbox:

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

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

What you can do with more

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

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

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

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

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

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

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

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

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

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

It’s all about the Benjamins

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

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

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

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

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

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

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

Growing pains

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

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

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

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

More people, more problems

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

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

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

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

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

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

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

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

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

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

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

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

Let’s get small

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

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

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

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

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

You can go your own way

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

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

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

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

What shall we do?

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

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

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

Read the full article


Career Consultation with Dr. Web—Live

Source: A List Apart

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

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

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

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

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

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

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

December 2 event: Ask Dr. Web—Live

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

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

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

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

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

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

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


Drupal and WordPress guides from Pantheon

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

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

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

Read the full article


This week’s sponsor: DreamFactory

Source: A List Apart

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

Read the full article


10 User Research Myths and Misconceptions

Source: UXMatters

By Jim Ross

Published: November 9, 2015

“There are still many misconceptions about how to gain an understanding of users and their needs.”

It’s a fortunate time for the field of User Experience. Never before have so many people become aware of user experience and the importance of understanding users. Yet, there are still many misconceptions about how to gain an understanding of users and their needs. In this column, I’ll explain and dispel the most common myths and misconceptions about user research.

Myth 1: User Research Provides Stunning, New Revelations

Those who are new to user research often overestimate the impact of the information it reveals, assuming research will reveal amazing, hidden truths. In our effort to convince clients and project teams to include user research in a project’s activities, we sometimes oversell its benefits and raise their expectations to a point that reality cannot match.
10 User Research Myths and Misconceptions


Error Messages Are an Anti-Pattern

Source: UXMatters

By Steven Hoober

Published: November 9, 2015

“At the core of user-centered design is the understanding that users are our biggest resource constraint—and the hardest thing to change.”

Since I wrote my article “Mobile Inline Form Validation” for UXmatters back in 2012, I have very rarely used any of those patterns in my own work. Recently, when I created a pattern library for mobile applications for a big, multinational, corporate client, I didn’t include any of those tips. Since the publication of that article, I have identified and begun to follow a few principles that are I hope more user centric.

Don’t See Users As the Source of Errors

If you design systems, you are familiar with constraints. For example, it is hard to add new fields to a database; mobile networks sometimes provide poor connectivity or have slow performance or high latency. Typically, system design takes such constraints—and, of course, costs—into account in determining what a team can build.
Error Messages Are an Anti-Pattern


Creating Good User Experiences by Focusing on Content

Source: UXMatters

By Robert Mills

Published: November 9, 2015

“The more you can embed content strategy into every step of your design process, the better the user experience will be.”

Content is everyone’s business. People in many different roles work toward shared project goals—whether they’re content strategists, UX designers, product managers, or Web developers. The outcome of both business-focused and user-centered goals is the user’s experience, and that user experience should have one thing at its heart: content.

The more you can embed content strategy into every step of your design process, the better the user experience will be. It is essential both that content be useful and that its presentation be usable. After all, it’s the content that brings users to your Web site.
Creating Good User Experiences by Focusing on Content

Older posts «