Many very experienced designers have already developed websites for the past 15 years and contributed a lot to the community by writing plenty of articles or even a few books. Unfortunately, even these veterans already feel that they are being left by the fast-paced improvement in the web development community. We are now seeing new system, best practices and tools being released almost daily. Many of them are quite far removed from the typical web development solutions and technologies.
Luckily, the web development community is not losing and it is not all doom and gloom either. As there are many exciting happening right now, designers should feel good with their job. Looking back at how web designers need to work during the 1990’s, web designers should be very happy with what they have right now.
One problem web developers are facing right now is the ubiquity of connectivity and technology. The Internet is no longer a flashy, brand new technology and everyone is using it unceasingly. Another problem is the rate of innovation. Something new comes out almost weekly that makes the previous big things start to look outdated, unwieldy and boring.
The Internet is being drives by numerous free and open technologies that many of us advocate. They really work and have outlived numerous closed technologies. There’s no doubt that the Internet hast lost much of its appeals to some people and this partly because even experienced web developers have become mainstream. The Web is no longer a playing ground where developers can do they want. They need to consider that the online realm is now a mainstream media, powered by advertising and cross-promotion. Consequently, developers need to be in the productive cycle all the time or they’ll miss the opportunity.
It’s a good thing to know that web developers can still make the Web interesting again. They can share their wisdom by writing on online places frequented by other developers as well.
They should reconsider how to complain. Of course, it feels good to vent on their blogs or on Twitterm but as professionals, developers need to obtain good feedback. It’s useless to advertise on mainstream social platforms saying that the Web is no longer the same and many things have to be fixed. Instead, developers should complain on channels appropriate for them and where what they do can really make things change for the better, There are many collaborative development tools they can use to host issues and get them fixed by others. Getting issues fixed by others are much better than those long-winded explanations in blogs and social media networks.
Developers can also contribute to tools that are appearing all over the Internet. Many of them are open source and require participation from experienced professionals. The sooner professional have real participation, the less likely for them to get left behind.
Unless they are working with startups that need completely new websites, developers are likely to work in organizations that have accumulated plenty of legacy designs. Even if the website is brand spanking new and coded from scratch, developers still need to figure our how they can incorporate elements of old designs. Fragmented legacy elements added to a new website may lead to poor user experience. Developers need to understand the organizations and its users, since designing the right visuals and interactions for it may take exceptional efforts. It may also be necessary to communicate with teams that work on earlier websites for the same organization. This won’t an easy work and developers should find a specific strategy that can help them fix broken user experience. This could start with surface improvements that progress deeper into more structural issues.
The Hierarchy Of Effort
Many large successful companies end up in a situation where they must maintain dozens, if not hundreds, of applications in their product portfolios. These huge suites are the result of mergers, acquisitions, different sets of user needs, legacy services and contracts, and the inefficiencies that naturally develop in huge organizations. Sometimes the reasons for so many different product lines are legitimate; other times, the wide set of offerings doesn’t serve anyone’s needs particularly well. Users will often struggle to learn a suite of related products because of major differences in how they look and operate.
The initiatives to fix these broken experiences are referred to in ambitious and somewhat generic terms, such as “common look and feel,” “unified online experience” and “unified look and feel.” Regardless of the term, the common elements represent a drive to bring consistency to a large set of products in multiple stages of development and spearheaded by a centralized internal group. There’s a sense of urgency; we often meet with some internal resistance; and frequently we’re charged with fixing a previous agency’s failed attempt to deliver design and guidelines that can be metabolized by the client.
The Hierarchy of Effort to Fix a Broken User Experience
One effective approach begins with surface improvements, goes progressively deeper into structural issues and ends with big strategic organizational shifts. We start with the low-hanging fruit and at each step reach higher to develop products that will ultimately deliver great experiences. It’s worth noting that this approach was developed to make it possible for a team to make incremental improvements to products already under development, but also to look ahead to future releases, when rewriting code or rethinking interactions won’t be so disruptive.
If your organization is working on its first product, then this approach would be totally backward. But in a large organization with a lot of history and many products, this approach will help you articulate both a short-term and long-term strategy for building a product portfolio that delivers a user experience that is learnable and builds confidence and a portfolio that makes your work easier and more effective.
Visual Consistency and Simplification
The lowest amount of effort required is at the bottom of the pyramid, so we suggest starting there. Sure, it’s lipstick on a pig, but simply taking a consistent visual approach will help to bring many different products under a shared brand experience.
Assuming you’ve done the groundwork to articulate the design of an ideal experience, the simplest and arguably easiest way to start implementing it is to re-skin the products currently under development. Finding ways to simplify and excise unnecessary information, unifying the information architecture, and adopting standard fonts, colors and controls are all relatively low-effort ways to improve existing products.
This is the foundation. It won’t improve a poorly designed interaction, but it could dramatically increase the appearance of unity to the end user. Products that have a consistent visual language will clearly convey their membership in a single portfolio. The benefit of improving the visual system first is that changing or adjusting the skin of an application is much easier than changing things such as behavior, which will require rethinking and recoding fundamental aspects of the application.
Behavioral Consistency
If your organization has simplified and unified the visual language, the next step is to make the behavior consistent. This is basic stuff: disciplined reuse of patterns instead of applying patterns ad hoc from a grab bag of widgets, and unifying the nomenclature and conceptual frameworks. Hopefully, any individual product will have internally consistent patterns; it’s when you look at sets of applications that were developed by different groups or obtained through acquisitions that you usually see wide discrepancies.
Assuming that the given design expresses high-level principles and provides a basic set of pattern libraries, the goal at this stage is to evaluate individual products and figure out how much work is required to align them. This work entails at the very least replacing widgets in some applications. It usually also entails a decent amount of coding and testing to ensure that the revisions contribute to a consistent experience. Maintaining a shared approach and understanding will require more coordination between development groups.
Behavioral consistency makes it easier for the end user to learn a tool and then to transfer those skills when picking up related tools. The user has to build only a single mental model of how the applications work. This gives them confidence and enables them to pick up new products without facing a steep learning curve and without being confused about how things are done.
Behavioral Optimization
The prior step was done solely to align the behavior of the various products. A deeper level of work is required to optimize the behavior and to make the applications more powerful and easier to use.
This step reworks the products even further. It means evaluating the current products against the user’s needs and goals and looking for ways to eliminate work and to simplify the patterns. This assumes some measure of design effort beforehand to identify the areas where this will make the most difference. It assumes a commitment to user-centered product design, some research, as well as persona’s and scenarios. Without these, you’ve got no way to decide what patterns to simplify, which work to excise, and what user needs to anticipate and solve for.
An optimized experience enables users to perform their tasks with less or more effective work. Any work that’s performed is captured in such a way that users aren’t asked to perform the same task twice. Smart defaults are captured and leveraged to make tasks flow more quickly. Where possible, shift computing work to computers, and judgements to humans. Mine data to see broader patterns and opportunities that allow the system to anticipate and meet needs before they become issues.
This is where you do everything you can to make each application the best it can be. It takes a lot of work, with new interactions introduced and much code rewritten. A considerable investment of time and effort is required.
Unified Experience Strategy
The result of the last iteration is a set of products that do what they do best. The point of this iteration is to rethink how the suite works together. This often means rethinking product strategy.
Designing a unified experience requires looking at the big picture, reevaluating the internal product silos in the organization, and reconsidering the ideal workflow for individuals and between roles. It could lead to collapsing multiple products into one, bridging gaps with new products, eliminating redundancies in capabilities or refocusing the service. This kind of work takes deep organizational commitment and a strong mandate. It takes long-range, instead of short-term, planning. It can’t be done quickly, and doing it well takes organizational honesty and courage.
The real beneficiary of this kind of effort is the end user, because this product strategy is user-centered. The company recognizes that the product exists to help people perform their work and that they might use other tools and services to accomplish their goals. Users don’t exist in isolation; they share work with others. Success isn’t measured by how well they perform a task, but in how competently they traverse a complex and dynamic ecosystem of people, data, devices and services. When a company brings their product line to this stage, both the organization and the product line have been transformed.
UX Culture
All of the prior steps were aimed at fixing a broken user experience. By following them as an iterative path, it becomes possible to greatly improve a severely broken user experience. The way to avoid having to repeat this cycle in a few years is to transform the organization itself. Software and services are conceived and developed in a particular organizational culture, and this has a profound effect on the products. Products coming out of an engineering-oriented organization bear the unmistakable focus on technology; services with a focus on sales deeply communicate this; and products that come out of organizations with a UX bent cannot avoid their focus on a good user experience.
If you want to repeatedly deliver a great user experience, you need to go deeper than applying design to the surface. Your organization needs to understand and commit to making user experience a core priority. Executives have to support or advocate for the unique perspective that design brings; capable designers have to work for a user-centered approach; and a user-centered way of building things has to be integrated into the organization.
A great user experience almost never just happens. Understanding the user and keeping their needs as your priority throughout the design and development stages take deliberate effort. Products and services are created by teams of people who collaborate to bring an idea to life. The output is ultimately shaped by the agreements about what is important, the methods of performing the work and decisions on how to measure things. A shift in organizational culture takes the most effort and the longest time, but it results in the largest, most pervasive and most coherent shift — not just for the organization and its products, but for those who use them.
Isn’t This All Backwards?
“But wait,” you’re thinking. “Isn’t this all backwards? Shouldn’t you design the whole system around the right workflow, optimize the behavior within it, make sure it’s consistent with other products, and finally make sure it’s visually simple and clear?” Yes. Yes, you should, especially if you’re making a brand new product.
But we see again and again that few large companies really have the ability to clear the table, start with a clean slate and build something utterly new and great. Most start with a line of products that cannot be abandoned. They have applications that are supported by various teams around the world, perhaps owned by different subsidiaries and in various states of compliance. While you can design the ideal experience, you can’t just build it. Moving toward something whose design really delivers will take many iterations. This situation isn’t great, but it’s the reality. When you find yourself here, you can’t boil the ocean. You have to start somewhere. In our experience, starting at the bottom is a very practical way to move forward.
Last week at the fabulous Smashing Conference in Freiburg, I gave a new talk, one I’d written just a few hours prior. I chose not to use slides, but instead to speak about three things that I’m incredibly enthusiastic about:
Responsive design is not (just) a design or development problem;
The client participation process is broken;
How to call your client an idiot, to their face.
Here are the (slightly expanded) notes that I made before my talk.
Responsive Design Is Not (Just) A Design Or Development Problem
In all the excitement about responsive Web design over the last few years, someone forgot to tell our bosses and clients, so we’ve been treating responsive design like it’s a design or an implementation problem, whereas in fact it’s as much an issue for business. In fact, it’s an issue for everyone involved: designers, developers, content specialists, the people who commission websites and those who structure the teams who make the websites.
The Traditional Workflow
Here’s a common, if grossly over-simplified, project workflow:
Plan,
Design,
Develop,
Deploy.
Into planning, you might roll up content audits, requirements, user issues, wireframes and the like. (Aside: Perhaps it’s because I’ve had too many bad experiences with too many bad UX specialists, but I’ve a problem with any part of the process that limits our potential for great design. This includes wireframes — typically desktop-only wireframes — that are produced and often signed off by a client long before they arrive in the design studio. Nothing is wrong with UX per se, only when it’s prescriptive and not part of a flexible, iterative design process.)
Design is where you’ll find a myriad of creative activities, including graphic and layout design and more. Here, static design visuals — you might call them comps — have been the traditional currency of the visual designer. They’re what designers use to experiment with creative ideas, then exchange with clients for sign-off, and subsequently deliver to front-end engineers as blueprints for building.
Development is likely the responsibility of front-end engineers. I know from experience that engineers often work separately from designers and might have only limited interaction with them.
As for deployment, I know I’m making light of this, but it’s black magic and I simply don’t understand it.
This waterfall-style process is similar to the old-fashioned pre-press workflow that I remember when I worked in pre-digital photography. It took up to seven people to take a transparency from a camera to a color proof. Each person’s work was an opportunity for sign-off, but more importantly it was an opportunity for billing. The same is mostly true of our Web design processes today.
Compare that to what I’ve cheekily been calling a “post-PC responsive workflow”:
Plan,
Combined and iterative design and development,
Deploy.
In this agile-style iterative process, everyone works more closely together, designing, developing, testing, redesigning and refining.
Design Testing and Device Testing
I find testing my designs on real smartphones and tablets while I’m working to be incredibly useful. This means that I have access to several devices. But how can we afford to buy all of the devices we need? This year, Stephanie Rieger wrote about the range of devices we should use. She included iPhones, iPads, Kindle Fire and three different versions of Android. But I think her advice could be misleading.
Do we really need to own a myriad of smartphones and tablets or do we need just a few to develop an affinity for them? Image: opensourceway.
It’s important to remember that there is a big distinction between two types of testing: design testing and device testing.
Designers need use only a subset of devices, because what matters most is that we develop an affinity for how our designs work on any type of device when we hold it our hands. To be clear, how a menu feels when used on a smartphone is a very different issue from whether it technically works on a particular make or model of smartphone. That’s why designers don’t necessarily need to buy a myriad of smartphones and tablets, just those they need to develop an affinity for.
Responsive Design Requires Rethinking
Businesses (agencies, companies, customers) now need to refactor many aspects of their businesses to allow for better responsiveness. Our clients now need to restructure their buying process. For example, at my agency, Stuff and Nonsense, I still get prospective clients asking us only for static design visuals. They assume we work in Adobe Photoshop, Fireworks or the like and that we deliver static visuals, because that’s what designers have provided them with for well over a decade. That’s why, while many of our clients don’t often expect responsive templates as a deliverable, they love it when they find out that that’s what we deliver.
Design and development teams need to reorganize. It’s a fact that purely visual designers have the most to learn.
Those Photoshop or Fireworks static visuals I spoke about are no longer equipped to provide what we need from them in a responsive context. As I’ve said before, it’s like bringing a knife to a gunfight. More on that in just a minute.
The Client Participation Process Is Broken
I know that most people know me from my writing and speaking about CSS, and some people might not know that I make my living by designing for clients. In the last year, I’ve worked on projects with STV, where I’m part-time the design lead; the Hillsborough Independent Panel, whose report into the tragic deaths of 96 Liverpool fans in 1989 I designed the website for; and the ISO, the International Organisation for Standards.
Every designer should want to make the best work possible, feel proud about that work and make their clients happy. Unfortunately, the ways that designers and developers and our clients have communicated in the past has so often lead to frustration, unhappiness and, most importantly, work that failed to meet everyone’s expectations.
For a designer, sharing regular feedback with clients and involving them in every step of the design process might sound like a risky proposition, but it is necessary and beneficial to the design process — when done properly. Image: opensourceway.
Think of the traditional media that we used to communicate our designs: static wireframes and visuals (comps) that we made using drawing tools such as Photoshop or Fireworks, many of which pre-date the Web. These visuals are like bringing a knife to a gunfight. Think about the aspects of design that a static medium cannot communicate and all of the possibilities for misunderstanding that this creates. Static visuals cannot do any of the following:
Display Web fonts or browser font rendering;
Demonstrate different browsers’ CSS capabilities;
(Easily) demonstrate percentage-based layouts;
(Easily) demonstrate animations, transitions and pseudo-classes (states).
When I say “easily,” I mean not without hours of tedious repetition that we could otherwise spend being creative.
This isn’t to say that designing in a browser is always better. Unlike Stephen Hay, I use Fireworks to design atmosphere (typography, color and texture) and to develop fine design details, an extra layer of polish, after all of the sketching and interactive prototypes are done.
Design Atmosphere
What do I mean by “atmosphere”?
Many people continue to mix layout with other aspects of design. How often has a client said to you, “I don’t like the design” when they really meant, “The sidebar should be on the left, not the right”? That’s why we need a new word for what’s left when we remove layout from a design. I call what’s left “atmosphere” because atmosphere is often about something that you feel but can’t explain, like the atmosphere in a room after two people have been arguing, or like the atmosphere at a great concert or football game.
Worse than being inefficient, static visuals set the wrong expectations in the minds of our clients. I wrote about this very thing back in 2009.
Aside: Why are most websites fixed and centred at 960 pixels? Could it be because a designer showed their client a 960-pixel-wide static visual and asked them to sign off on it? That’s what developers have been told to build. That’s why, in the past, we’ve spent hours hacking HTML, CSS and JavaScript to make rounded corners display in old versions of IE. We sold rounded corners to our clients through those visuals. It’s our own stupid fault. No one else’s.
Even small “snapshots” of the design, such as these from Dribbble, can communicate atmosphere — the visual direction, style and overall feeling — of the new website. Images: Fluid Type, Fig. 49 by Trent Walton.
Work in Photoshop and Fireworks, by all means (I do). Make static visuals as rich and as detailed as you want them to be. Just don’t set the wrong expectations by showing them to your clients as examples of how their website might look across browsers and devices or by using them as sign-off artefacts. The same goes for screenshots of Web pages. Set the right expectations by demonstrating interactive designs made using HTML, CSS and JavaScript.
How To Call Your Client An Idiot, To Their Face, Without Getting Fired, And Then Have Them Thank You For It
One thing I’ve learned over the years is that clients love to feel involved in the design process. Sometimes, though, they make suggestions only so that they feel they have put their stamp on the project. I know that occasionally designers think that such requests aren’t necessary and that sometimes they’re stupid. Don’t worry. You are allowed to say that to clients (more about that later), but better still, avoid the issue entirely. Here’s how…
Don’t email pictures of websites to your clients and then ask for their “thoughts.” Are you mad?! In the same vein, don’t simply upload static visuals to Basecamp and expect constructive feedback without providing some direction on how to receive them.
Don’t wait until after weeks of work before having a “big reveal.” Down this road lies frustration and resentment. Instead, keep clients involved at every step, all the way through the design process, and not only at those traditional sign-off points. That’s why for the last few years I’ve tried hard to physically work alongside my clients as often as possible. When that’s not an option, I set up shared Dropbox folders so that the client can check in on my progress as I work. We even keep a Skype window continually open.
Set up the proper environment to receive structured feedback, and then ban all unstructured feedback you might receive by telephone or email. Insist that your feedback sessions be face to face when possible, and then limit their scope to aspects of the design. For example, ask for answers to specific questions about typeface choices and typography.
At my design agency, I help facilitate structured feedback by organizing feedback workshops with our clients. More on those now.
Please remember: you are the designer. You are the person who has been hired to solve a problem that the client either couldn’t or doesn’t have the time to solve themselves. Your solution to that problem is worth a lot to their business, so never underestimate your role, skills and influence in the design process.
With that in mind, remember that you can set rules about receiving the constructive, structured feedback that’s so important to helping you make a great design.
RULE 1
As mentioned, don’t ask for unstructured feedback out of context. Emailing or uploading static visuals just doesn’t cut the mustard anymore. You must control the discussion, so take the time to explain your designs and the thinking behind the decisions you’ve made. I’ve found that, because of this approach, my clients enjoy learning about what goes into making a design and are far less likely to request unnecessary changes simply to put their mark on the project.
RULE 2
Take control of the environment in which you present your designs. Host feedback workshops or design “crits,” and use them to get to know your clients better and to develop a deeper relationship with them. Make these workshops face to face when possible, and set time and scope limits, even if you hold them over Skype. These workshops work best when everyone is encouraged to be honest and to let their ideas out in the open. That’s why, although it may seem a little old fashioned, it’s important for someone to keep a written record of what everyone has said.
Make it clear to your client that only the people who show up to a workshop may have an opinion about the design. This must include even the CEO, who sometimes makes “helpful” suggestions 24 hours before launch (or when you want to get paid).
RULE 3
Remind everyone to leave their feelings at the door, because in a design crit only the work matters. Personal feelings don’t matter; so, inside the crit, frame the conversation so that your clients can openly express their opinions. Encourage them to speak their minds, to be brutally honest if they need to be and to scribble across your notes and sketches to get their point across. By the same token, you’re free to disagree with any suggestions they make. Be free to say the suggestions won’t work, and suggest better alternatives. This shouldn’t be about ego, only about the integrity of the work.
If you feel they aren’t listening, you’re free to call them an idiot, too, if you must. Say it to their face, and don’t worry about getting getting fired — if you’ve established a good enough relationship with them, they’ll thank you for it, too, because they’ll know you have their interests at heart and are passionate about doing your best for them and their business.(al)
The trouble with a color’s name is that it never really is perceived as the exact same color to two different individuals — especially if they have a stake in a website’s emotional impact. Name a color, and you’re most likely to give a misleading impression. Even something like “blue” is uncertain. To be more precise, it could be “sky blue”, “ocean blue”, “jeans blue” or even “arc welder blue”.
Descriptions vary with personal taste and in context with other colors. We label them “indigo”, “jade”, “olive”, “tangerine”, “scarlet” or “cabaret”. What exactly is “electric lime”? Names and precise shades vary — unless you’re a computer.
Code Demands Precision
When computers name a color, they use a so-called hexadecimal code that most humans gloss over: 24-bit colors. That is, 16,777,216 unique combinations of exactly six characters made from ten numerals and six letters — preceded by a hash mark. Like any computer language, there’s a logical system at play. Designers who understand how hex colors work can treat them as tools rather than mysteries.
Breaking Hexadecimals into Manageable Bytes
Pixels on back-lit screens are dark until lit by combinations of red, green, and blue. Hex numbers represent these combinations with a concise code. That code is easily broken. To make sense of #970515, we need to look at its structure:
The first character # declares that this “is a hex number.” The other six are really three sets of pairs: 0–9 and a–f. Each pair controls one primary additive color.
The higher the numbers are, the brighter each primary color is. In the example above, 97 overwhelms the red color, 05 the green color and 15 the blue color.
Each pair can only hold two characters, but #999999 is only medium gray. To reach colors brighter than 99 with only two characters, each of the hex numbers use letters to represent 10–16. A, B, C, D, E, and F after 0–9 makes an even 16, not unlike jacks, queens, kings and aces in cards.
Being mathematical, computer-friendly codes, hex numbers are strings full of patterns. For example, because 00 is a lack of primary and ff is the primary at full strength, #000000 is black (no primaries) and #ffffff is white (all primaries). We can build on these to find additive and subtractive colors. Starting with black, change each pair to ff:
#000000 is black, the starting point.
#ff0000 stands for the brightest red.
#00ff00 stands for the brightest green.
#0000ff stands for the brightest blue.
Subtractive colors start with white, i.e. with the help of #ffffff. To find subtractive primaries, change each pair to 00:
#ffffff is white, the starting point.
#00ffff stands for the brightest cyan.
#ff00ff stands for the brightest magenta.
#ffff00 stands for the brightest yellow.
Shortcuts in Hex
Hex numbers that use only three characters, such as #fae, imply that each ones place should match the sixteens place. Thus #fae expands to #ffaaee and #09b really means #0099bb. These shorthand codes provides brevity in code.
In most cases, one can read a hex number by ignoring every other character, because the difference between the sixteens place tells us more than the ones place. That is, it’s hard to see the difference between 41 and 42; easier to gauge is the difference between 41 and 51.
The example above has enough difference among its sixteens place to make the color easy to guess — lots of red, some blue, no green. This would provide us with a warm violet color. Tens in the second example (9, 9 and 
are very similar. To judge this color, we need to examine the ones (7, 0, and 5). The closer a hex color’s sixteens places are, the more neutral (i.e. less saturated) it will be.
Make Hexadecimals Work For You
Understanding hex colors lets designers do more than impress co-workers and clients by saying, “Ah, good shade of burgundy there.” Hex colors let designers tweak colors on the fly to improve legibility, identify elements by color in stylesheets, and develop color schemes in ways most image editors can’t.
Keep Shades in Character
To brighten or darken a color, one’s inclination is often to adjust its brightness. This makes a color run the gamut from murky to brilliant, but loses its character on either end of the scale. For example, below a middle green becomes decidedly black when reduced to 20% brightness. Raised to 100%, the once-neutral green gains vibrancy.
A funny thing happens when we treat hex colors as if they were increments of ten. By adding one to each of the left-hand character of each pair, we raise a color’s brightness while lowering its saturation. This prevents shades of a given color from wandering too closely to pitch black or brilliant neon. Altering hex pairs retains the essence of a color.
In the example above, the top set of shades appears to gain yellow or fall to black, even though it’s technically the same green hue. By changing its hex pairs, the second set appears to keep more natural shades.
Faded Underlines
By default, browsers underline text to denote links. But thick underlines interfere with letters’ descenders. Designers can make underlines less obtrusive by scaling back hex colors. The idea is to make the tags closer to the background color, while the text itself gains contrast against the background.
For dark text on a bright background, we make the links brighter.
For bright text on a dark background, we make the links darker.
To make this work, every embedded link needs a inside of every :
a { text-decoration:underline;color:#aaaaff; }
a span { text-decoration:none;color:#0000ff; }
As you can see here, underlines in the same color as the text can interfere with parts of type that drop below the baseline. Changing the underline to resemble the background more closely makes descenders easier to read, even though most browsers place underlines above the letterforms.
Adding spans to every anchor tag can be problematic. A popular alternative is to remove underlines and add border-bottom:
a { text-decoration: none; border-bottom: 1px solid #aaaaff; }
Better Body Copy
A recurring design problem is that a specific color may be technically correct but has an unintended effect. For example, some designs call for headers and body copy to be the same color. We have to keep in mind that the thicker the strokes of large text appears, the darker the small text appears.
h1, p { color: #797979; }
h1 { color: #797979; }
p { color: #393939; }
While technically identical, the body of the copy is narrower, and more delicate letterforms make it visually brighter than the heading. Lowering the sixteens places will make the text easier to read.
How To Warm Up or Cool Down a Background
Neutral backgrounds may be easy to read against, but “neutral” doesn’t have to mean “bland”. Adjusting the first and last byte can make a background subtly warmer or cooler.
#404040 — neutral
#504030 — warmer
#304050 — cooler
Is that too much? For a more subtle shift, use the ones places instead:
#404040 — neutral
#594039 — warmer
#394059 — cooler
Coordinate Colors with Copy-Paste
Recognizing the structure of a hex number’s number/letter pairs gives designers a unique tool to explore color combinations. Unlike color wheels and charts, rearranging pairs in a hex number is a simple process to change hues while keeping values similar. As a bonus, the results can be unpredictable. The simplest technique is to move one pair of characters to a different spot, which trades primary colors.
A common design technique to make text or other visual elements coordinate with a photo is to use colors from within that photo. Understanding hex colors can take that a step further, by deriving new colors that coordinate with the photo without taking directly from the photo.
Going Forward
Don’t let the code intimidate you. With a little creativity, hex colors are a tool at your disposal. If nothing else, next time someone asks if you can solve a problem with code in any language, you can simply say:
“Shouldn’t be harder than parsing hexadecimal triplets in my head.”