The Wireframe Perfectionist’s Guide

When I was a developer, I often had a hundred questions when building websites from wireframes that I had received. Some of those questions were:

  • How will this design scale when I shrink the browser window?
  • What happens when this shape is filled out incorrectly?
  • What are the options in this sorting filter, and what do they do?

These types of questions led me to miss numerous deadlines, and I wasted time and energy in back-and-forth communication. Sadly, this situation could have been avoided if the wireframes had provided enough detail.

Now that I am a UX designer, I notice that some designers tend to forget that wireframes are equally creative and technical. We are responsible for designing great ideas, but we are also responsible for creating product specifications. I admit that there can be so many details to remember that it’s easy to lose track. To save time and energy for myself, I gathered all of my years of wireframing knowledge into a single checklist that I refer to throughout the process. And now I am sharing this knowledge with you, so that you can get back to being creative.

If you’re starting fresh on a wireframe project, I recommend going through each section’s guidelines like a checklist. If not, feel free to jump to the appropriate section.

  1. Decisions to consider before wireframing1
  2. Detailing the design elements2
  3. Annotating the wireframes3

Considerations Link

Note: These guidelines are more appropriate for wireframes — and prototypes, to an extent — during a production life cycle (i.e. preparing your product to be built). By this point, the main idea has been established, the features have been fairly locked down, and the core layouts are not going to dramatically change. That being said, some guidelines, like in the first section, can be used for conceptual wireframes in a discovery phase. Just be wary of getting too detailed, because your designs might drastically change, and you will have wasted time.

Finally, onto the guide!

Decisions To Consider Before Wireframing

These guidelines ensure that you ask the difficult but crucial questions early on and establish a foundation for a smooth wireframing process.

Device Support Link

Usually, the stakeholders will dictate which devices to support, but sometimes you will have a reasonable suspicion that it will be cross-platform or responsive. Other times, you might have to select the best devices to use with your product. In either case, here’s a list of reference devices:

  • desktop browsers
  • mobile website (browser)
  • native mobile app: Android, iOS, Windows
  • tablet
  • smartwatch: Android Wear, Watch OS(iOS), WebOS, Band (Microsoft)
  • smart TV: Android TV, Tizen OS (Samsung), Firefox OS (Panasonic), WebOS (LG)
  • Facebook applications
  • virtual reality: HTC Vive, Oculus Rift, Samsung Gear VR, Playstation VR
  • kiosks
  • console gaming: Xbox One, Playstation 4, Wii U, Steam

Confirm devices expected to be supported. More often than not, responsive mobile wireframes are requested later in the process or are suddenly included by the client. These late requests can cause massive design reworking when you have already started on the wireframes. So, ensure the following:

  • Align with your team’s expectations.
  • Make sure you have client approval in writing, or refer to a statement of work.
  • While they are not devices, content management systems are frequently forgotten.

Match features to context of use. While composing a review for a product would work in a desktop browser, it might be seldom done on a mobile phone. Review your features one by one and determine whether your users will get added value from each device. If a feature does not match the user’s goals, either change it to be more device-specific or cut it out completely for the device in question. Reducing the design will save you time and money.

Verify design differences on multiple devices. A common scenario is building a desktop application with a mobile and tablet component. Discuss the following with your team and stakeholders:

  • Will the layout be identical (responsive) or completely separate?
  • Are features shared across all experiences, or will there be subsets?
  • Which operating systems are being supported? For instance, Android and iOS apps follow different design patterns.

Maintain documentation on differences in layouts and features, so that you can easily design for them later in your wireframes.

Consider implications of screen orientation. For mobile and tablet, designs can appear different in portrait and landscape modes.

  • Left alone, a landscape layout will appear like the portrait version but with the width stretched out and less horizontal viewing space.
  • Screens can be locked to an orientation. Tread carefully around design layouts that are exclusive to portrait or landscape, because you are forcing users to work a certain way. If in doubt, conduct a usability test.

Maintaining a portrait layout might have worked better here so that users would not have to rotate their phone back and forth on the scheduling screen of Nest’s mobile app. (View large version5)

Scaling the Design Link

A layout and its UI elements can scale in a variety of ways when the window’s size changes. The most popular scaling patterns are:

  • fixed or static
    Remains the same no matter what.
  • fluid or liquid
    Incrementally shrinks or stretches with each pixel.
  • adaptive
    Layout changes at certain breakpoints in the window’s width.
  • responsive
    Follows a mix of fluid and adaptive behavior.

Liquidapsive566 is an interactive tool for visualizing how each scaling pattern affects the layout when the window’s size changes.

Get team consensus. First discuss with your team the best approach, because this will have an impact on the time for you, the developers and the visual designers. Users expect most websites to have desktop and mobile versions, although they don’t always have to share the same set of features.

Align with your developer on mechanics. Consult with your developers on how the design should scale. Also, discuss breakpoints and the scaling behavior for layouts and UI elements that you are unsure of.

Prepare for many sets of wireframes. Responsive and adaptive layouts will need many sets of screens; so, let your project managers know it will require extra time. I usually add an extra 50 to 75% of the total time for each set.

Default Screen Size Resolution Link

Establishing a default screen size is important for everyone on your team because they will need to know what to develop and design for. You also want to avoid accidentally starting too large and then realizing you need to shrink it down.

Start small and prepare for a large size. 1024 × 768 pixels for desktop and tablet and 320 × 480 for mobile are generally safe resolutions to work with. Anything higher can be risky to begin with. It is prudent to start with a low resolution and then scale up so that the design still looks adequate when the window is larger.

(View large version8)

Additionally, consider that many people do not maximize their browser window, so their view of the layout will be even smaller.

Use analytics to guide your decision. Analytics for screen resolutions can reveal interesting trends, which can help you make an informed decision. You might need the data to convince your client of the resolution you are pushing for as well. Remember that it’s better to be inclusive than exclusive.

A list of screen resolution analytics9
Although 1366 × 768 pixels has the highest number of users, 1280 × 800 is the best to start with, despite having a usage of 3.76%. (View large version10)

Going for that larger, prettier resolution might cut off a chunk of your audience. To help with your analysis, here are some scenarios I have seen before:

  • The most popular resolution can sometimes be safe if it shows a trend of continued growth over many years, while the lower resolutions are declining.
  • A group of small resolutions with a low percentage of use could add up to a sizeable population — in which case, choose the lowest resolution.
  • For a large variation in resolutions, go with the lowest one.
  • If at least 5% of users have a a low resolution, such as 1024 × 768, I would err on the side of caution and select that.
  • Viewing trends for the past year is sometimes better than viewing trends since the beginning, because the latter could include resolutions that are no longer relevant. Sanitize your data by removing old data and mobile and tablet resolutions — trends will be easier to identify.

Know your audience and usage environment. Although 1366 × 768 is the most common resolution for the desktop (as of May 2016, according to StatCounter5711 and W3Counter5812), think about your audience’s context of use. For instance, 1024 × 768 makes sense if you’re dealing with users who are on old computers and can’t change their equipment (usually corporate environments).

Level of Fidelity Link

Be clear on your definitions of fidelity because it can mean different things to different people. Below is how I define wireframe fidelity:

Low fidelity has these elements:

  • Focuses on layout and high-level interactions and concepts.
  • UI elements and content can be represented as boxes or lines, with or without label descriptions.
  • Gray-scale.
  • Can be paper sketch.

Low fidelity wireframe example13
Notice how abstract this wireframe is. It’s easy to get carried away with adding more detail, but imagine that people will only be able to see a zoomed-out wireframe.

High fidelity has these elements:

  • Emphasizes visual aesthetics and branding, such as tone, colors, graphics and font style.
  • Can include realistic images and copy.
  • UI elements look realistic and might include aesthetic touches such as textures and shadows.
  • Sometimes known as a mockup.

Sometimes you need to create a small set of concept wireframes with visual themes to preview the overall look and feel. (Image: Squarespace15) (View large version16)

Medium fidelity has these elements:

  • Varies between low and high fidelity.
  • More realistic UI elements, but not styled.
  • Filler images and copy.
  • Gray-scale.
  • Has some visual design (such as hierarchical typography).

This wireframe uses various grayscale values to convey visual weight, without actually using color. (View large version18)

Indulge your stakeholders. Observe your stakeholders’ behavior to figure out what makes them happy, or have a discussion with them to determine what they expect.

  • Are they the type to hone in on minor irrelevant details? Start with low fidelity, and iterate on that until they are satisfied. Then, move up to medium or high fidelity. Gradually building fidelity over multiple check-ins will make approvals easier, while saving precious design time.
  • Are they the type to react to something flashy? Go with high fidelity, but create only a couple at first, so that the stakeholders get an idea of what to expect.
  • If in doubt, medium fidelity is always a safe bet, although it takes a bit more time.

Confirm the expectations of fidelity. Whichever fidelity you decide on, make sure your team and stakeholders are on the same page — consider giving examples to be sure. It is scary to walk into a meeting with low-fidelity designs when “low fidelity” in people’s mind is actually “medium fidelity.”

Grid Systems and Alignment Link

When used in a wireframe tool, a grid system saves you time by easily aligning your UI through snap-to-grid features. This feature basically keeps your designs looking aligned and polished.

Using a grid system will also help you maintain consistency in the layout and balance the design’s hierarchy. The article “All About Grid Systems19” does a great job of briefly explaining the theory behind grid systems and the key advantages to using them.

For design inspiration, I have used the article “Using Layout Grids Effectively6120” for examples of grid layouts and patterns.

Know your alignment and spacing features. I achieve pixel-perfection by using the alignment and space-distribution features of many wireframe tools. Learn to use the most common keyboard shortcuts, such as centering, space distribution, grouping and ungrouping. It will save you from having to manually polish your layouts.

Omnigraffle's alignment tool21
Shown here is Omnigraffle’s object-alignment module, which is somewhat similar in other tools such as InDesign and Axure. (View large version22)

Perform visual checks. Your visual designer and developer will end up doing most of the actual pixel-pushing, but you’ll want to get it as close as possible; a sloppy design will lose the trust of your user. The key to saving time and cleaning up a design is to stand back a bit from the design and see if any misalignments are visible to the naked eye.

Now that you have checked off all of the pre-wireframing activities, you can start designing the actual wireframes. The next section will focus on polishing the design.

Detailing The Design Elements

Once you have completed the bulk of your main designs, it’s time to include all of the cumbersome details. Go through each of your screens and use the guidelines below as a checklist to fill in anything missing.

Interaction Feedback Link

For any action that a user executes, there should always be feedback to let them know what happened or what the next step is.

Validate forms. Forms will usually have one of these validation responses:

  • Invalid syntax: For email address, phone number, area code, URLs and credit-card numbers.
  • Incorrect login: Include a message for the username or password being incorrect, but also include one for both being wrong.
  • Empty form fields.
  • Required check boxes: For agreeing to terms of service.
  • Age requirement: Dropdown to fill in birth date.

Intermediary messages and modals. Many user actions will generate some form of UI to inform the user of what is happening or to ask them to do something. These can include:

  • confirmation
  • warning or alert
  • success
  • failed action
  • error
  • long-term progress indicator: This is when the user might have to wait for a long behind-the-scenes process to complete (even days long).
  • progress indicator or bar: Include states for zero progress, in progress, completion and failure.
  • spinner: For indeterminate time estimations or short operations.

Write user-friendly messages. No one likes to read an obscure error message like “Exception 0xc000000933” or a generic one like “Login error.” And unless you have a technical writer on the team, you are actually the most qualified person to write user-friendly messaging.

For consistency, I follow these criteria when writing messages:

  • Include the specific problem if possible.
  • Mention the next step to resolve the issue.
  • Keep it brief and concise, about one to two sentences.
  • Explain in colloquial terms.
  • Avoid technical jargon.
  • Maintain a positive and apologetic tone. Pretend you’re a down-to-earth customer service rep.
  • Enhance with the brand’s tone, if there is one.

Implement supportive form-input techniques. Your developer will know clever tricks to show users error messages immediately or to support users with input fields. Below is a list of common techniques to think about:

  • “Remember me” checkbox for logging in.
  • Links for forgotten password or username. Don’t forget the extra screens such as for “Send a reset password to email” and confirmation that the reset was successfully sent.
  • Suggested results upon typing keywords in a search.
  • Validating each keyboard character entered.
  • Character limit, with a counter or some visual representation when reaching a character limit.
  • Dropdown lists that auto-filter items when typing. Select223 is a great plugin for combo boxes.
  • Letting a user know when they have entered an old password.
  • A checklist for password strength or password syntax that marks off syntax requirements as the user types.

This checklist clearly tells you what criteria has been fulfilled for your password. (View large version25)

Interaction States Link

Walk through each of your UI components, and design for best- and worst-case scenarios, as well as any other potential states.

Dropdown lists. While the closed state will already be in your design, include the expanded state in your annotations or on a separate page. Do you have any of the following types of dropdowns?

  • navigation menu
  • combo box (states, date, age)
  • filter
  • sorting
  • context menu

Titles, labels and names. Account for all cases in which the text is exceptionally long in a confined space and can’t break to a new line (for example, in a table). Try to shorten the text as below, and then include the full-length text in a tooltip.

  • Ellipsis: “Deoxyribo…”
  • Truncation: “Deoxy”
  • Abbreviations: “DNA”
  • Names: “G. Washington or George W.”
  • Numbers: “100K,” “50M,” “140+”

Dynamic content. Your developers will need to know how content population scales or behaves in different situations:

  • Pagination: search result listings, forums, news articles
  • Scrolling and loading content
  • Brief paragraph text or tags
  • Galleries: image, video and banner carousels
  • Trees: nested file or folder directories
  • Comments and posts

These states are commonly associated with dynamic content:

  • First, middle and last pages: Pagination controls can sometimes appear different depending on where the user is, and final pages can include a “next step” action to fill in empty space.
  • Standard content length: This is default.
  • Empty or unpopulated content: Empty space can look awkward, so consider a friendly message or a subtle background image to fill the void.
  • Overflowing content: Try using “More…” links or a form of truncation.
  • Nested posts: Stack Exchange has a forum thread26 with a variety of suggestions to nest infinite posts.

Icons with numbers. Icons sometimes include values such as how many notifications or emails the user has. You will want to include states for the following:

  • zero items
  • typical items: double or triple digits
  • large numbers: depending on the design, it could go up to hundreds or thousands, but indicating “100K” or “2000+” is also acceptable.

Form fields. Forms will typically have a few states:

  • enabled: This is the default.
  • disabled: For fields that appear unusable in certain conditions.
  • corrected: Optionally have a different style for fields whose validation error has been corrected.
  • validation error: Some designers place error messages adjacent to the relevant field and/or provide an error list.

Tooltips. Consider adding a tooltip (a brief one to two sentences) for any interactions that fit these criteria:

  • New or uncommon interaction pattern: Helpful text for interactions that users wouldn’t intuitively understand at first glance. Think of different design solutions before using this as a fallback.
  • Advanced areas and actions: Common with programs such as Photoshop and Word, in which advanced functionality improves the user’s productivity or work quality.
  • Less frequent actions: Actions that rarely occur will need help text to jog the user’s memory.
  • Keyboard shortcuts.
  • Shortened content: Abbreviated or truncated text that needs a fully written version.
  • Content preview: Text or images that include previews of content. This is common with listings where users would want to peek at the content before committing to an action that would take them off the page.
  • Reference information: Extra details that quickly support the user with a task (for example, the security number on a credit card).

File uploads. When the user uploads a file in the browser, there are a few states to design for:

  • File upload dialog: Usually provided by default in the OS or browser, but include your custom design if you have one.
  • Upload progress bar.
  • Upload completion bar: For having reached 100%.
  • Canceling in-progress upload: Cancelling an upload in progress can take time.
  • Success: Appears after the progress bar goes away. Include the file name that was uploaded and a way to remove the file.
  • Remove confirmation: Confirmation to remove the uploaded file.

Gestures Link

There is typically one way your users will physically interact with your UI, but there can also be multiple gestures per interaction, as with a responsive design or buttons with keyboard shortcuts. For each user action, look for the other gestures below and note the differences in your annotations later.

  • click
  • double-click
  • right-click
  • swipe or flick
  • pinch and spread
  • press
  • hover
  • drag and drop
  • keyboard input
  • keyboard shortcut
  • link to external website
  • link to default application: email, phone number, map.

A wireframe for smart TVs that shows annotations with multiple gestures27
This smart TV wireframe shows how various remote-control buttons interact with a UI element. (View large version28)

Be sensitive to cross-device interaction. If you are working on a responsive website, be aware of gestures that will not translate smoothly:

  • Hovering: Some designers replace this with a touch gesture. But watch out for actions that already use touch for something else.
  • Dragging and dropping: An alternative design is best.
  • Uploading files: Not a common mobile task; consider removing it for mobile.

Supplementary Areas and Pages Link

Aside from your core design, other miscellaneous areas tend to be forgotten, such as:

  • 404 error page
  • Internet or service down
  • Logging in: Include CAPTCHA and social log-ins if necessary.
  • Forgotten username or password: Do not forget the successful “we sent you an email to reset” message.
  • Settings and configuration
  • Terms and conditions
  • Privacy policy
  • Email: Such as confirming the creation of an account or resetting the password.

User Types Link

You may have users who see a different design or receive an interaction specifically for them. Include extra wireframes to show what each user sees.

  • New users: Users who just created an account.
  • Guests: Users who have no account yet.
  • First-time visitors: You might have a screen that is only seen once.
  • Returning visitors
  • Existing or logged-in users
  • Admins and super-users
  • Other roles

Copy Link

Consider how much time you have and what would be useful to your audience. You can also mix and match styles, like using real text for the home-page banner but filler for other areas. Listed below are various styles, with their key advantages.

Lorem ipsum (such as the kind produced by Dummy Text Generator29) is great for:

  • previewing how short or long paragraphs will appear,
  • showing a page with filled-in content,
  • when you have no budget for copywriting.

Wireframe with lorem ipsum text30
Even the navigation titles can be lorem ipsum if you’re still working on them. (View large version31)

Generic labels that describe the final copy are good for:

  • knowing what it should say but not having time to write it out,
  • giving direction to your writer,
  • avoiding political battles with branding team members or stakeholders,
  • steering stakeholders away from nitpicking about copy.

Wireframe with generic labels32
Describe what would be in a paragraph, and then repeat it for length. If you’re unsure, use lorem ipsum instead. (View large version33)

Realistic copy that closely reflects the content’s intent is helpful for:

  • increasing the fidelity and realism of a polished design.
  • showing the proper language and tone to use in the final copy.
  • conducting usability tests on the home page design.

Wireframe with realistic text34
If you are using realistic copy, fight for doing only top-level pages, like a landing page. (View large version35)

Demonstrations Link

Demonstrating how an interaction works will reduce miscommunication with the developer and ensure that it is technically feasible. Typically, the developer will feel more confident about deciding which plugin or implementation to use. But if you feel technically savvy, then it would be really helpful for you, as the architect, to take the first step. Below are some useful tips.

Search for plugins. If you are working online, you can often find the latest and trusted plugins being used by the development community on GitHub3736. Search for something like “accordion” to browse through accordion plugins. If you are working on other devices, such as Android mobile or Apple Watch, search the web for official design guideline documentation.

Select relevant plugins. Developers consider community approval, constant updates and framework compatibility to be important when selecting a plugin. On GitHub3736, you can sort for “most stars” and “recently updated.” Also, look for demo links in the documentation or website to see how it will work, and then share it with your developer to see if it is viable.

Build a demonstration. If you are building a custom interaction or flow that does not yet exist, think about using prototyping tools or coding it yourself if you are technically savvy. Some prototyping tools with motion design features include Principle6338, Flinto6439 and Axure40. Some that might require a bit of programming knowledge are Origami6641 and Framer6742.

If you can actually code, then CodePen43 is useful for building something quickly and easily.

Once you feel content with the level of polish in your design, finish up with annotations.

Annotating The Wireframes

At this point, most of your design will be complete, and you are ready to annotate your work.

Placing Annotations Link

Being strategic in where and how you place your annotations on the page can improve your workflow and overall quality.

Determine a location. There are different advantages to where you place annotations. See which style below would be most useful to you:

  • Left or right column: Allows the reader to focus on the design or on reading the annotations.
  • Inline: Promotes a more connected reading experience by linking explanations directly to UI elements.
  • Marked tooltips: Similar to inline annotations. Prototyping software such as Axure allows you to place markers directly in the design that can be clicked on to reveal the annotation.
  • Separate page: Gives ample, dedicated space to view the design and annotations.

Wireframe of inline annotations44
I drew lines directly from an interaction to show the gesture used and what the resulting state would be. (View large version45)

Load in wireframe images. Designing for a large resolution can leave little space for annotations. Instead, you could wireframe your layouts with the accurate resolutions, and have another document where you drop the same wireframe images into a fixed-size container. This gives you consistent space for annotations, without having to worry about how big the design is.

I’ve created a template46 (Zip, 1.51 MB) that enables you simply to export wireframe images to the image folder and then drag and drop the same images to an annotated InDesign document. As long as you use the same file names for your export, you can continually overwrite the old wireframe images, and they will automatically update in the InDesign document.

Writing Annotations Link

Follow these technical writing rules when revising your annotations:

  • Avoid being wordy. Be direct and concise. Excise words and sentences that do not add any information or that are redundant. Your team and stakeholders want to quickly and easily get the information they need.
  • Avoid figures of speech and metaphors if your audience might be foreign.
  • Stick to simple vocabulary so that everyone can understand, but use technical terms if the audience would understand them.
  • Favor the active voice over the passive voice to cut down wordiness and to be clearer in your explanations. Purdue OWL has an article47 showing examples of the active and passive voice.

Write for developers. Although stakeholders will enjoy story-driven annotations, developers will prefer straightforward, technical explanations. Be extremely detailed about how an interaction works, and include values if necessary. Write your annotations so that anyone could take the design and build it without needing to talk to you.

To compare and contrast, the annotation below is written for a stakeholder who is working on conceptual wireframes (notice the second-person usage and descriptive wording):

As you scroll toward the bottom of the page, you will seamlessly receive more search results so that you can continue reading without needing to perform another action.

Here is the same example written for a developer:

When scroll bar reaches last search result (about 25% height from bottom):

  • Dynamically load 10 more search results below current list.
  • If end of search results is reached, remove “Load more…” button.
  • Show spinner when loading; remove when finished.
  • Use fade-in and fade-out animation when loading results.

List multiple gestures, states and demos. For each action, indicate the gesture(s), label each annotation by its state, and include demo links if available. If there are multiple states, define their conditions or business logic.

Wireframe with multiple interaction states48
My wireframe shows a variety of styles for describing states and gestures. (View large version49)

UX Integration Link

One of the most common challenges for UX designers is convincing other people of your design decisions. There is a tendency among people to feel that your decisions are arbitrary. If you can muster the time, I have found it helpful to connect previous UX work to a finished design. It goes a long way to reminding your team or stakeholders of the evidence that supports your design.

Site map. In each wireframe, show where this particular screen lives in your site map. Don’t show the entire site map, though, just the immediate parents, siblings and children. You can also refer to page IDs if you are using them in your site map.

Personas and user goals. Include a label of the persona and the major user goals, tasks or behaviors that the screen is targeting. Alternatively, include user story statements and/or features from a feature priority matrix.

User flows. Show the reader which step in the flow they are looking at. Include a portion of the user flow (enough for context), as opposed to the entire flow.

Wireframe with user flows embedded50
The flow below shows where the user is currently, but also shows the previous and next steps. (View large version51)

User research findings. Include user research findings (as bullet points) that directly support your design decisions. These could come from user interviews, ethnographic studies, analytics, competitive analysis, surveys, focus groups or usability tests.

Open questions. If you still need more information from stakeholders, developers or subject-matter experts, provide a list of questions under the annotation to give the reader context. Putting questions in the wireframe has several advantages:

  • reader will see that you are thinking deeply about the design,
  • promotes iteration and reduces anxiety about finalizing the design.
  • convenient for bringing up in presentations.

Usability testing questions. Your designs are not always going to be perfect from the first iteration. Minimize design “paralysis analysis” by choosing a hypothetical direction and then conducting usability tests to guide your design changes. List your user-testing questions so that people can see your thought process and so that you can keep track of contentious topics for your usability test plan.

Wireframe with usability testing questions52
I maintained a list of hypothetical questions on the side to show that I still need user feedback to move forward. (View large version53)

Wireframe Meta Data and Versioning Link

Inevitably, you will iterate through many versions of your wireframes. Including wireframe meta data and keeping track of changes will be helpful not only to other people, but also to you in the long run. Forming this habit takes time, but it’s well worth it.

Include a table of contents. A table of contents is especially important in production wireframes because there will be many pages. Also, InDesign can re-update your table of contents based on any new page changes. Setting up header styles can be finicky, so feel free to use my template54 (ZIP, 1.51 MB) if you need a quick start.

Add a footer. The footer is the best place to include ancillary information about your wireframes. It also keeps your document together in case you print the wireframes and pages go missing. Consider including the following information:

  • Document name: Could simply include the project’s name, deliverable type and version number.
  • Page number
  • Confidential labels: Some companies require that you label documents “Private” or “Confidential.”

Track wireframe revisions. It can be difficult for readers to know what has changed when your wireframes have over 100 pages. So, ahead of your table of contents, include a table of revisions containing the following details:

  • date,
  • name of the person who made the revisions,
  • brief notes or bullet points about what has changed.

Maintain file versioning. Every time you work on a new batch of wireframes (i.e. sending it out to people), create a copy of the previous file before working on the new one. Then, rename it and include at least these details:

  • Brand or client’s company name: Optional if it doesn’t make sense or if the file name gets too long.
  • Project name
  • Type of deliverable: wireframes, in this case
  • Version number: lead with two 0’s for proper file sorting, because “1” can get incorrectly sorted with “10” and “100.”
  • Your name or initials: If you expect to collaborate with another designer
  • Delimiters: Use underscore or hyphen, instead of a space, which sometimes causes issues with file systems.

It could look like this: Google_Youtube_Wireframes_001.graffle.

Or, if you’re collaborating, it could look like this: Apple-iTunes-Wireframes-EL-001.sketch.

Final Thoughts Link

Striving for perfection is a great goal, but be practical with your time, too. Most real-world projects don’t have ample timelines, so figure out your priorities, and use the guidelines that make sense.

My goal is to help fill in the gaps of every UX designer’s wireframing process with all of the knowledge I’ve gained over the years. I hope it helps you to perfect your wireframes.

I love to help people out, so let me know in the comments below or contact me if you have questions. Also, please share and spread the love if you’ve found this helpful!

Resources Link

  • Annotation wireframe template55, Edric Lapniramai (ZIP, 1.51 MB)
    An InDesign template for dropping in wireframe images and managing annotations.
  • Liquidapsive566
    A website that shows exactly what happens with various scaling methods.
  • StatCounter5711
    A website that tracks currently used screen resolutions.
  • W3Counter5812
    Another website that tracks popular screen resolutions.
  • Purdue Online Writing Lab59
    Guidelines for technical writing techniques.
  • “All About Grid Systems60,” Rachel Shillcock, Envato Tuts+
    An article on the theory behind grid systems.
  • “Using Layout Grids Effectively6120,” Designers Insights
    A brief article on some example layout grids and how to use them.
  • Plugin search62, GitHub
    A well-known source-code repository host that you can use to search for popular UI plugins.
  • Principle6338
    A prototyping tool for the Mac that enables you to fine-tune animations and transitions.
  • Flinto6439
    Similar to Principle but a bit simpler with its motion design features.
  • Axure65
    A comprehensive prototyping tool that closely mimics what can be done with JavaScript.
  • Origami6641
    A prototyping tool that works from iOS and Android code.
  • Framer6742
    A prototyping tool that gives you greater control over the code for your transitions.
  • Codepen68
    A pure online code editor where you can quickly and easily test HTML, CSS and JavaScript animations.


  1. 1 #decisions-to-consider-before-wireframing
  2. 2 #detailing-the-design-elements
  3. 3 #annotating-the-wireframes
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19–webdesign-14471
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60–webdesign-14471
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68

↑ Back to top Tweet itShare on Facebook


CSS Inheritance, The Cascade And Global Scope: Your New Old Worst Best Friends

I’m big on modular design1. I’ve long been sold on dividing websites into components, not pages, and amalgamating those components dynamically into interfaces. Flexibility, efficiency and maintainability abound.

But I don’t want my design to look like it’s made out of unrelated things. I’m making an interface, not a surrealist photomontage.

As luck would have it, there is already a technology, called CSS, which is designed specifically to solve this problem. Using CSS, I can propagate styles that cross the borders of my HTML components, ensuring a consistent design with minimal effort. This is largely thanks to two key CSS features:

  • inheritance,
  • the cascade (the “C” in CSS).

Despite these features enabling a DRY2, efficient way to style web documents and despite them being the very reason CSS exists, they have fallen remarkably out of favor. From CSS methodologies such as BEM and Atomic CSS through to programmatically encapsulated CSS modules, many are doing their best to sidestep or otherwise suppress these features. This gives developers more control over their CSS, but only an autocratic sort of control based on frequent intervention.

I’m going to revisit inheritance, the cascade and scope here with respect to modular interface design. I aim to show you how to leverage these features so that your CSS code becomes more concise and self-regulating, and your interface more easily extensible.

Inheritance And font-family Link

Despite protestations by many, CSS does not only provide a global scope. If it did, everything would look exactly the same. Instead, CSS has a global scope and a local scope. Just as in JavaScript, the local scope has access to the parent and global scope. In CSS, this facilitates inheritance.

For instance, if I apply a font-family declaration to the root (read: global) html element, I can ensure that this rule applies to all ancestor elements within the document (with a few exceptions, to be addressed in the next section).

html { font-family: sans-serif;
} /* This rule is not needed ↷
p { font-family: sans-serif;

Just like in JavaScript, if I declare something within the local scope, it is not available to the global — or, indeed, any ancestral — scope, but it is available to the child scope (elements within p). In the next example, the line-height of 1.5 is not adopted by the html element. However, the a element inside the p does respect the line-height value.

html { font-family: sans-serif;
} p { line-height: 1.5;
} /* This rule is not needed ↷
p a { line-height: 1.5;

The great thing about inheritance is that you can establish the basis for a consistent visual design with very little code. And these styles will even apply to HTML you have yet to write. Talk about future-proof!

The Alternative Link

There are other ways to apply common styles, of course. For example, I could create a .sans-serif class…

.sans-serif { font-family: sans-serif;

… and apply it to any element that I feel should have that style:

<p class="sans-serif">Lorem ipsum.</p>

This affords me some control: I can pick and choose exactly which elements take this style and which don’t.

Any opportunity for control is seductive, but there are clear issues. Not only do I have to manually apply the class to any element that should take it (which means knowing what the class is to begin with), but in this case I’ve effectively forgone the possibility of supporting dynamic content: Neither WYSIWYG editors nor Markdown parsers provide sans-serif classes to arbitrary p elements by default.

That class="sans-serif" is not such a distant relative of style="font-family: sans-serif" — except that the former means adding code to both the style sheet and the HTML. Using inheritance, we can do less of one and none of the other. Instead of writing out classes for each font style, we can just apply any we want to the html element in one declaration:

html { font-size: 125%; font-family: sans-serif; line-height: 1.5; color: #222;

The inherit Keyword Link

Some types of properties are not inherited by default, and some elements do not inherit some properties. But you can use [property name]: inherit to force inheritance in some cases.

For example, the input element doesn’t inherit any of the font properties in the previous example. Nor does textarea. In order to make sure all elements inherit these properties from the global scope, I can use the universal selector and the inherit keyword. This way, I get the most mileage from inheritance.

* { font-family: inherit; line-height: inherit; color: inherit;
} html { font-size: 125%; font-family: sans-serif; line-height: 1.5; color: #222;

Note that I’ve omitted font-size. I don’t want font-size to be inherited directly because it would override user-agent styles for heading elements, the small element and others. This way, I save a line of code and can defer to user-agent styles if I should want.

Another property I would not want to inherit is font-style: I don’t want to unset the italicization of ems just to code it back in again. That would be wasted work and result in more code than I need.

Now, everything either inherits or is forced to inherit the font styles I want them to. We’ve gone a long way to propagating a consistent brand, project-wide, with just two declaration blocks. From this point onwards, no developer has to even think about font-family, line-height or color while constructing components, unless they are making exceptions. This is where the cascade comes in.

Exceptions-Based Styling Link

I’ll probably want my main heading to adopt the same font-family, color and possibly line-height. That’s taken care of using inheritance. But I’ll want its font-size to differ. Because the user agent already provides an enlarged font-size for h1 elements (and it will be relative to the 125% base font size I’ve set), it’s possible I don’t need to do anything here.

However, should I want to tweak the font size of any element, I can. I take advantage of the global scope and only tweak what I need to in the local scope.

* { font-family: inherit; line-height: inherit; color: inherit;
} html { font-size: 125%; font-family: sans-serif; line-height: 1.5; color: #222;
} h1 { font-size: 3rem; }

If the styles of CSS elements were encapsulated by default, this would not be possible: I’d have to add all of the font styles to h1 explicitly. Alternatively, I could divide my styles up into separate classes and apply each to the h1 as a space-separated value:

<h1 class="Ff(sans) Fs(3) Lh(1point5) C(darkGrey)">Hello World</h1>

Either way, it’s more work and a styled h1 would be the only outcome. Using the cascade, I’ve styled most elements the way I want them, with h1 just as a special case, just in one regard. The cascade works as a filter, meaning styles are only ever stated where they add something new.

Element Styles Link

We’ve made a good start, but to really leverage the cascade, we should be styling as many common elements as possible. Why? Because our compound components will be made of individual HTML elements, and a screen-reader-accessible interface makes the most of semantic markup.

To put it another way, the style of “atoms” that make up your interface “molecules” (to use atomic design terminology3) should be largely addressable using element selectors. Element selectors are low in specificity4, so they won’t override any class-based styles you might incorporate later.

The first thing you should do is style all of the elements that you know you’re going to need:

a { … }
p { … }
h1, h2, h3 { … }
input, textarea { … }
/* etc */

The next part is crucial if you want a consistent interface without redundancy: Each time you come to creating a new component, if it introduces new elements, style those new elements with element selectors. Now is not the time to introduce restrictive, high-specificity selectors. Nor is there any need to compose a class. Semantic elements are what they are.

For example, if I’ve yet to style button elements (as in the previous example) and my new component incorporates a button element, this is my opportunity to style button elements for the entire interface.

button { padding: 0.75em; background: #008; color: #fff;
} button:focus { outline: 0.25em solid #dd0;

Now, when you come to write a new component that also happens to incorporate buttons, that’s one less thing to worry about. You’re not rewriting the same CSS under a different namespace, and there’s no class name to remember or write either. CSS should always aim to be this effortless and efficient — it’s designed for it.

Using element selectors has three main advantages:

  • The resulting HTML is less verbose (no redundant classes).
  • The resulting style sheet is less verbose (styles are shared between components, not rewritten per component).
  • The resulting styled interface is based on semantic HTML.

The use of classes to exclusively provide styles is often defended as a “separation of concerns.” This is to misunderstand the W3C’s separation of concerns5 principle. The objective is to describe structure with HTML and style with CSS. Because classes are designated exclusively for styling purposes and they appear within the markup, you are technically breaking with separation wherever they’re used. You have to change the nature of the structure to elicit the style.

Wherever you don’t rely on presentational markup (classes, inline styles), your CSS is compatible with generic structural and semantic conventions. This makes it trivial to extend content and functionality without it also becoming a styling task. It also makes your CSS more reusable across different projects where conventional semantic structures are employed (but where CSS ‘methodologies’ may differ).

Special Cases Link

Before anyone accuses me of being simplistic, I’m aware that not all buttons in your interface are going to do the same thing. I’m also aware that buttons that do different things should probably look different in some way.

But that’s not to say we need to defer to classes, inheritance or the cascade. To make buttons found in one interface look fundamentally dissimilar is to confound your users. For the sake of accessibility and consistency, most buttons only need to differ in appearance by label.

<button>create</button> <button>edit</button> <button>delete</button>

Remember that style is not the only visual differentiator. Content also differentiates visually — and in a way that is much less ambiguous. You’re literally spelling out what different things are for.

There are fewer instances than you might imagine where using style alone to differentiate content is necessary or appropriate. Usually, style differences should be supplemental, such as a red background or a pictographic icon accompanying a textual label. The presence of textual labels are of particular utility to those using voice-activation software: Saying “red button” or “button with cross icon” is not likely to elicit recognition by the software.

I’ll cover the topic of adding nuances to otherwise similar looking elements in the “Utility Classes” section to follow.

Attributes Link

Semantic HTML isn’t just about elements. Attributes define types, properties and states. These too are important for accessibility, so they need to be in the HTML where applicable. And because they’re in the HTML, they provide additional opportunities for styling hooks.

For example, the input element takes a type attribute, should you want to take advantage of it, and also attributes such as aria-invalid6 to describe state.

input, textarea { border: 2px solid; padding: 0.5rem;
} [aria-invalid] { border-color: #c00; padding-right: 1.5rem; background: url(images/cross.svg) no-repeat center 0.5em;

A few things to note here:

  • I don’t need to set color, font-family or line-height here because these are inherited from html, thanks to my use of the inherit keyword. If I want to change the main font-family used application-wide, I only need to edit the one declaration in the html block.
  • The border color is linked to color, so it too inherits the global color. All I need to declare is the border’s width and style.
  • The [aria-invalid] attribute selector is unqualified. This means it has better reach (it can be used with both my input and textarea selectors) and it has minimal specificity. Simple attribute selectors have the same specificity as classes. Using them unqualified means that any classes written further down the cascade will override them as intended.

The BEM methodology would solve this by applying a modifier class, such as input--invalid. But considering that the invalid state should only apply where it is communicated accessibly, input--invalid is necessarily redundant. In other words, the aria-invalid attribute has to be there, so what’s the point of the class?

Just Write HTML Link

My absolute favorite thing about making the most of element and attribute selectors high up in the cascade is this: The composition of new components becomes less a matter of knowing the company or organization’s naming conventions and more a matter of knowing HTML. Any developer versed in writing decent HTML who is assigned to the project will benefit from inheriting styling that’s already been put in place. This dramatically reduces the need to refer to documentation or write new CSS. For the most part, they can just write the (meta) language that they should know by rote.

Layout Link

So far, we’ve not written any component-specific CSS, but that’s not to say we haven’t styled anything. All components are compositions of HTML elements. It’s largely in the order and arrangement of these elements that more complex components form their identity.

Which brings us to layout.

Principally, we need to deal with flow layout — the spacing of successive block elements. You may have noticed that I haven’t set any margins on any of my elements so far. That’s because margin should not be considered a property of elements but a property of the context of elements. That is, they should only come into play where elements meet.

Fortunately, the adjacent sibling combinator7 can describe exactly this relationship. Harnessing the cascade, we can instate a uniform default across all block-level elements that appear in succession, with just a few exceptions.

* { margin: 0;
} * + * { margin-top: 1.5em;
} body, br, li, dt, dd, th, td, option { margin-top: 0;

The use of the extremely low-specificity lobotomized owl selector8 ensures that any elements (except the common exceptions) are spaced by one line. This means that there is default white space in all cases, and developers writing component flow content will have a reasonable starting point.

In most cases, margins now take care of themselves. But because of the low specificity, it’s easy to override this basic one-line spacing where needed. For example, I might want to close the gap between labels and their respective fields, to show they are paired. In the following example, any element that follows a label (input, textarea, select, etc.) closes the gap.

label { display: block } label + * { margin-top: 0.5rem;

Once again, using the cascade means only having to write specific styles where necessary. Everything else conforms to a sensible baseline.

Note that, because margins only appear between elements, they don’t double up with any padding that may have been included for the container. That’s one more thing not to have to worry about or code defensively against.

Also, note that you get the same spacing whether or not you decide to include wrapper elements. That is, you can do the following and achieve the same layout — it’s just that the margins emerge between the divs rather than between labels following inputs.

<form> <div> <label for="one">Label one</label> <input id="one" name="one" type="text"> </div> <div> <label for="two">Label two</label> <input id="two" name="two" type="text"> </div> <button type="submit">Submit</button>

Achieving the same result with a methodology such as atomic CSS9 would mean composing specific margin-related classes and applying them manually in each case, including for first-child exceptions handled implicitly by * + *:

<form class="Mtop(1point5)"> <div class="Mtop(0)"> <label for="one" class="Mtop(0)">Label one</label> <input id="one" name="one" type="text" class="Mtop(0point75)"> </div> <div class="Mtop(1point5)"> <label for="two" class="Mtop(0)">Label two</label> <input id="two" name="two" type="text" class="Mtop(0point75)"> </div> <button type="submit" class="Mtop(1point5)">Submit</button>

Bear in mind that this would only cover top margins if one is adhering to atomic CSS. You’d have to prescribe individual classes for color, background-color and a host of other properties, because atomic CSS does not leverage inheritance or element selectors.

<form class="Mtop(1point5) Bdc(#ccc) P(1point5)"> <div class="Mtop(0)"> <label for="one" class="Mtop(0) C(brandColor) Fs(bold)">Label one</label> <input id="one" name="one" type="text" class="Mtop(0point75) C(brandColor) Bdc(#fff) B(2) P(1)"> </div> <div class="Mtop(1point5)"> <label for="two" class="Mtop(0) C(brandColor) Fs(bold)">Label two</label> <input id="two" name="two" type="text" class="Mtop(0point75) C(brandColor) Bdc(#fff) B(2) P(1)"> </div> <button type="submit" class="Mtop(1point5) C(#fff) Bdc(blue) P(1)">Submit</button>

Atomic CSS gives developers direct control over style without deferring completely to inline styles, which are not reusable like classes. By providing classes for individual properties, it reduces the duplication of declarations in the stylesheet.

However, it necessitates direct intervention in the markup to achieve these ends. This requires learning and being commiting to its verbose API, as well as having to write a lot of additional HTML code.

Instead, by styling arbitrary HTML elements and their spacial relationships, CSS ‘methodology’ becomes largely obsolete. You have the advantage of working with a unified design system, rather than an HTML system with a superimposed styling system to consider and maintain separately.

Anyway, here’s how the structure of our CSS should look with our flow content solution in place:

  1. global (html) styles and enforced inheritance,
  2. flow algorithm and exceptions (using the lobotomized owl selector),
  3. element and attribute styles.

We’ve yet to write a specific component or conceive a CSS class, but a large proportion of our styling is done — that is, if we write our classes in a sensible, reusable fashion.

Utility Classes Link

The thing about classes is that they have a global scope: Anywhere they are applied in the HTML, they are affected by the associated CSS. For many, this is seen as a drawback, because two developers working independently could write a class with the same name and negatively affect each other’s work.

CSS modules10 were recently conceived to remedy this scenario by programmatically generating unique class names tied to their local or component scope.

<!-- my module's button -->
<button class="button_dysuhe027653">Press me</button> <!-- their module's button -->
<button class="button_hydsth971283">Hit me</button>

Ignoring the superficial ugliness of the generated code, you should be able to see where disparity between independently authored components can easily creep in: Unique identifiers are used to style similar things. The resulting interface will either be inconsistent or be consistent with much greater effort and redundancy.

There’s no reason to treat common elements as unique. You should be styling the type of element, not the instance of the element. Always remember that the term “class” means “type of thing, of which there may be many.” In other words, all classes should be utility classes: reusable globally.

Of course, in this example, a .button class is redundant anyway: we have the button element selector to use instead. But what if it was a special type of button? For instance, we might write a .danger class to indicate that buttons do destructive actions, like deleting data:

.danger { background: #c00; color: #fff;

Because class selectors are higher in specificity than element selectors and of the same specificity as attribute selectors, any rules applied in this way will override the element and attribute rules further up in the style sheet. So, my danger button will appear red with white text, but its other properties — like padding, the focus outline, and the margin applied via the flow algorithm — will remain intact.

<button class="danger">delete</button>

Name clashes may happen, occasionally, if several people are working on the same code base for a long time. But there are ways of avoiding this, like, oh, I don’t know, first doing a text search to check for the existence of the name you are about to take. You never know, someone may have solved the problem you’re addressing already.

Local Scope Utilities Link

My favorite thing to do with utility classes is to set them on containers, then use this hook to affect the layout of child elements within. For example, I can quickly code up an evenly spaced, responsive, center-aligned layout for any elements:

.centered { text-align: center; margin-bottom: -1rem; /* adjusts for leftover bottom margin of children */
} .centered > * { display: inline-block; margin: 0 0.5rem 1rem;

With this, I can center group list items, buttons, a combination of buttons and links, whatever. That’s thanks to the use of the > * part, which means that any immediate children of .centered will adopt these styles, in this scope, but inherit global and element styles, too.

And I’ve adjusted the margins so that the elements can wrap freely without breaking the vertical rhythm set using the * + * selector above it. It’s a small amount of code that provides a generic, responsive layout solution by setting a local scope for arbitrary elements.

My tiny (93B minified) flexbox-based grid system11 is essentially just a utility class like this one. It’s highly reusable, and because it employs flex-basis, no breakpoint intervention is needed. I just defer to flexbox’s wrapping algorithm.

.fukol-grid { display: flex; flex-wrap: wrap; margin: -0.5em; /* adjusting for gutters */
} .fukol-grid > * { flex: 1 0 5em; /* The 5em part is the basis (ideal width) */ margin: 0.5em; /* Half the gutter value */

logo with sea anemone (penis) motifFukol’s distinctive logotype

Using BEM, you’d be encouraged to place an explicit “element” class on each grid item:

<div class="fukol"> <!-- the outer container, needed for vertical rhythm --> <ul class="fukol-grid"> <li class="fukol-grid__item"></li> <li class="fukol-grid__item"></li> <li class="fukol-grid__item"></li> <li class="fukol-grid__item"></li> </ul>

But there’s no need. Only one identifier is required to instantiate the local scope. The items here are no more protected from outside influence than the ones in my version, targeted with > *nor should they be. The only difference is the inflated markup.

So, now we’ve started incorporating classes, but only generically, as they were intended. We’re still not styling complex components independently. Instead, we’re solving system-wide problems in a reusable fashion. Naturally, you will need to document how these classes are used in your comments.

Utility classes like these take advantage of CSS’ global scope, the local scope, inheritance and the cascade simultaneously. The classes can be applied universally; they instantiate the local scope to affect just their child elements; they inherit styles not set here from the parent or global scope; and we’ve not overqualified using element or class selectors.

Here’s how our cascade looks now:

  1. global (html) styles and enforced inheritance,
  2. flow algorithm and exceptions (using the lobotomized owl selector),
  3. element and attribute styles,
  4. generic utility classes.

Of course, there may never be the need to write either of these example utilities. The point is that, if the need does emerge while working on one component, the solution should be made available to all components. Always be thinking in terms of the system.

Component-Specific Styles Link

We’ve been styling components, and ways to combine components, from the beginning, so it’s tempting to leave this section blank. But it’s worth stating that any components not created from other components (right down to individual HTML elements) are necessarily over-prescribed. They are to components what IDs are to selectors and risk becoming anachronistic to the system.

In fact, a good exercise is to identify complex components (“molecules,” “organisms”) by ID only and try not to use those IDs in your CSS. For example, you could place #login on your log-in form component. You shouldn’t have to use #login in your CSS with the element, attribute and flow algorithm styles in place, although you might find yourself making one or two generic utility classes that can be used in other form components.

If you do use #login, it can only affect that component. It’s a reminder that you’ve moved away from developing a design system and towards the interminable occupation of merely pushing pixels.

Conclusion Link

When I tell folks that I don’t use methodologies such as BEM or tools such as CSS modules, many assume I’m writing CSS like this:

header nav ul li { display: inline-block;
} header nav ul li a { background: #008;

I don’t. A clear over-specification is present here, and one we should all be careful to avoid. It’s just that BEM (plus OOCSS, SMACSS, atomic CSS, etc.) are not the only ways to avoid convoluted, unmanageable CSS.

In an effort to defeat specificity woes, many methodologies defer almost exclusively to the class selector. The trouble is that this leads to a proliferation of classes: cryptic ciphers that bloat the markup and that — without careful attention to documentation — can confound developers new to the in-house naming system they constitute.

By using classes prolifically, you also maintain a styling system that is largely separate from your HTML system. This misappropriation of ‘separate concerns’ can lead to redundancy or, worse, can encourage inaccessibility: it’s possible to affect a visual style without affecting the accessible state along with it:

<input id="my-text" aria-invalid="false" class="text-input--invalid" />

In place of the extensive writing and prescription of classes, I looked at some other methods:

  • leveraging inheritance to set a precedent for consistency;
  • making the most of element and attribute selectors to support transparent, standards-based composition;
  • applying a code- and labor-saving flow layout system;
  • incorporating a modest set of highly generic utility classes to solve common layout problems affecting multiple elements.

All of these were put in service of creating a design system that should make writing new interface components easier and less reliant on adding new CSS code as a project matures. And this is possible not thanks to strict naming and encapsulation, but thanks to a distinct lack of it.

Even if you’re not comfortable using the specific techniques I’ve recommended here, I hope this article has at least gotten you to rethink what components are. They’re not things you create in isolation. Sometimes, in the case of standard HTML elements, they’re not things you create at all. The more you compose components from components, the more accessible and visually consistent your interface will be, and with less CSS to achieve that end.

There’s not much wrong with CSS. In fact, it’s remarkably good at letting you do a lot with a little. We’re just not taking advantage of that.

(vf, al, il)

  1. 1
  2. 2’t_repeat_yourself
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11

↑ Back to top Tweet itShare on Facebook


Spotify Playlists To Fuel Your Coding And Design Sessions

Some like it loud, others need some steady beats to stay focused, others calm tunes. A while ago we asked on Twitter1 and Facebook2 what music the web community is listening to when coding and designing.

The answers were as diverse as the community itself and certainly too good to live an existence only in a Twitter discussion. That’s why we’ve compiled those hand-crafted playlists, favorite artists, and loved soundtracks in this article to see which tunes fuel the web, and, well, first and foremost, to provide you with some new ear candy to get you through lengthy coding and design sessions, of course. Get your headphones ready!

(Image credit: Corey Blaz3)

Get Into The Flow Link

Positive psychology describes flow as the mental state when you get fully immersed in what you’re doing, feeling energized, focused, and involved. These playlists will tickle your brain to help you reach that much sought-after state.

Design Vibes Link

Curated by Sherzod Max | 564 songs | 58h 37min | Listen on Spotify64

No words to distract you, only steady vibes.

Design Vibes Playlist5
(Listen on Spotify64)

Hardstyle Playlist Link

Curated by Jesse Stoots | 755 songs | 56h 56min | Listen on Spotify97

Q-Base, Defqon, and Qlimax. Beats that help you get into the flow.

Hardstyle Playlist8
(Listen on Spotify97)

Brain Food Link

Curated by Spotify | 139 songs | 9h 39min | Listen on Spotify1210

Low-key electronic to stimulate your brain.

Brain Food Playlist11
(Listen on Spotify1210)

Soundtrack to the Film Blade Runner Link

Artist: Vangelis | 12 songs | 57min | Listen on Spotify1513

Classical compositions meet synthesizers. Melodic.

Blade Runner Playlist14
(Listen on Spotify1513)

Soundtrack to the Film Drive Link

Curated by Servaas Vehmeijer | 31 songs | 2h 30min | Listen on Spotify1816

A small but fine list. Get into the flow with some electronic beats, work your way through and get to the epic, musical-like finale.

Drive Movie Soundtrack17
(Listen on Spotify1816)

Design & Build Link

Curated by Manik Rathee | 225 songs | 16h 06min | Listen on Spotify2119

This one won’t get boring. Sometimes full of energy, sometimes calm.

Design And Build Playlist20
(Listen on Spotify2119)

Coding And Crushing It Link

Curated by Noel Tock | 127 songs | 8h 38min | Listen on Spotify2422

Orchestra meets film music.

Coding And Crushing It Playlist23
(Listen on Spotify2422)

Soundtrack to the Film TRON: Legacy Link

Artist: Daft Punk | 22 songs | 58min | Listen on Spotify2725

A mix of electronic music and 70s-inspired sci-fi sounds.

TRON Movie Soundtrack26
(Listen on Spotify2725)

Soundtrack to the Film The Big Short Link

Artist: Nicholas Britell | 23 songs | 38min | Listen on Spotify3028

A surprising mix — sometimes energetic and upbeat with a bit of 70’s funk, sometimes darker and moody.

The Big Short Movie Soundtrack29
(Listen on Spotify3028)

Hyperspatial Detours Link

Artist: Café Del Mar | 7 songs | 21min | Listen on Spotify3331

Chillout music from the famous Café Del Mar.

Hyperspatial Detours Playlist32
(Listen on Spotify3331)

Stay Focused Link

Staying focused over a long period of time can be hard. The following playlists cater for some background music without being too obtrusive.

Futurebeats Link

Curated by Kyle Hovey | 2,908 songs | 207h 11min | Listen on Spotify3634

Experimental and electronic beat music.

Futurebeats Playlist35
(Listen on Spotify3634)

Deep Focus Link

Curated by Spotify | 112 songs | 8h 29min | Listen on Spotify3937

Atmospheric rock to stay calm and concentrated.

Deep Focus Playlist38
(Listen on Spotify3937)

Reading Soundtrack Link

Curated by Spotify Sweden | 66 songs | 4h 09min | Listen on Spotify4240

Instrumental film music.

Reading Soundtrack41
(Listen on Spotify4240)

4AM Comedown Link

Curated by Spotify UK | 50 songs | 3h 43min | Listen on Spotify4543

Chilled out dance.

4AM Comedown Playlist44
(Listen on Spotify4543)

Bring Me To Sleep Link

Curated by Quoc Nguyen | 10 songs | 31min | Listen on Soundcloud4846

Well, it shouldn’t bring you to sleep, but sometimes peaceful sounds from piano, violins, and guitar might be just what you need.

Bring Me To Sleep Playlist47
(Listen on Soundcloud4846)

Soundtrack For Study Link

Curated by Filtr Canada | 76 songs | 3h 36min | Listen on Spotify5149

Movie hits to help you focus and concentrate.

Soundtrack For Study50
(Listen on Spotify5149)

Acoustic Covers Link

Curated by Spotify | 118 songs | 7h 01min | Listen on Spotify5452

Words can be distracting when you need to focus on a task. So how about some acoustic covers?

Acoustic Covers Playlist53
(Listen on Spotify5452)

Soundtrack to the Film Interstellar Link

Artist: Hans Zimmer | 16 songs | 1h 11min | Listen on Spotify5755

Interstellar Movie Soundtrack56
(Listen on Spotify5755)

Stress-Free Classicals Link

Curated by Can Artuc | 49 songs | 3h 36min | Listen on Spotify6058

Classic, calm piano and orchestra pieces. Satie, Händel, Chopin, Schubert, and more.

Stress-Free Classicals Playlist59
(Listen on Spotify6058)

Chill Out Music Link

Curated by Spotify | 90 songs | 6h 35min | Listen on Spotify6361

Relaxing tunes.

Chill Out Music Playlist62
(Listen on Spotify6361)

Spa Treatment Link

Curated by Spotify | 84 songs | 6h 10min | Listen on Spotify6664

Pleasant background music that doesn’t distract.

Spa Treatment Playlist65
(Listen on Spotify6664)

Intense Studying Link

Curated by Spotify | 100 songs | 13h 46min | Listen on Spotify6967

Mostly classical music to help you concentrate.

Intense Studying Playlist68
(Listen on Spotify6967)

Boost Your Energy Link

The day has already been long and you need a little energy booster? How about one of these?

Liquid Drum & Bass Link

Curated by Björn Zuithoff | 8,959 songs | 847h 52min | Listen on Spotify7270

A huge Liquid Drum & Bass playlist to keep you fueled with energy.

Liquid Drum And Bass Playlist71
(Listen on Spotify7270)

Coding & Designing 0.3 Link

Curated by Ross Dalaire | 27 songs | 1h 59min | Listen on Spotify7773

Electronic beats to push you forward. If you like the playlist, also make sure to check out Coding & Designing 0.274 and Coding & Designing 0.175.

Coding And Designing Playlist76
(Listen on Spotify7773)

Soundtrack to the Film Pacific Rim Link

Artist: Ramin Djawadi | 26 songs | 1h 1min | Listen on Spotify8078

You’re on a quest to conquer this weird browser bug? This is your march music.

Pacific Rim Movie Soundtrack79
(Listen on Spotify8078)

Rock Hard Link

Curated by Spotify | 101 songs | 6h 19min | Listen on Spotify8381

The title says it all. If you like it loud, this one’s for you.

Rock Hard Playlist82
(Listen on Spotify8381)

Punk Essentials Link

Curated by Spotify France | 77 songs | 4h 03min | Listen on Spotify8684

The best of punk rock.

Punk Essentials Playlist85
(Listen on Spotify8684)

Starred Link

Curated by Julian Norton | 29 songs | 1h 58min | Listen on Spotify8987

A good mix to re-load your battery.

Starred Playlist88
(Listen on Spotify8987)

Walking Like A Badass Link

Curated by Spotify UK | 60 songs | 2h 56min | Listen on Spotify9290

Rocking riffs and pounding drums.

Walking Like A Badass Playlist91
(Listen on Spotify9290)

Kesä2016 Link

Curated by Annukka Leppänen | 43 songs | 2h 26min | Listen on Spotify9593

“Kesä” means summer in Finish, and this playlist certainly brings you in a good mood with dancehall, hip hop, and reggae.

Kesä Playlist94
(Listen on Spotify9593)

What do you usually listen to when doing coding and design work? Let us know in the comments below!

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 58
  59. 59
  60. 60
  61. 61
  62. 62
  63. 63
  64. 64
  65. 65
  66. 66
  67. 67
  68. 68
  69. 69
  70. 70
  71. 71
  72. 72
  73. 73
  74. 74
  75. 75
  76. 76
  77. 77
  78. 78
  79. 79
  80. 80
  81. 81
  82. 82
  83. 83
  84. 84
  85. 85
  86. 86
  87. 87
  88. 88
  89. 89
  90. 90
  91. 91
  92. 92
  93. 93
  94. 94
  95. 95

↑ Back to top Tweet itShare on Facebook


Web Development Reading List #159: Code Splitting, A New Bundler, And Blake2x

Today, too many websites are still inaccessible. In our new book Inclusive Design Patterns, we explore how to craft flexible front-end design patterns and make future-proof and accessible interfaces without extra effort. Hardcover, 312 pages. Get the book now →


  • Firefox 50 was released this week1. The new version comes with support for the once option for Event Listeners, the referrerpolicy attribute and a fix for dashed and dotted borders. On the other hand, box-sizing: padding-box was removed. The upcoming version, Firefox 512, which is currently in beta, will introduce a couple of changes, too: <img> with empty src will now fire an error event and JavaScript will be blocked if it’s served with a wrong MIME type. Furthermore, the non-standard Web Payments API will be removed, Accept header for XHR will be simplified, and SHA-1 certificates issued by public CA will no longer be accepted.

Tools & Workflow Link

Security Link

  • blake2x6 is a new hashing function that is even better than blake2. It does not only allow hashes of any arbitrary size but also has a key derivation function and a deterministic random bit generator.
  • What to do if a third party causes your site to throw mixed content warnings? Thanks to the upgrade-insecure-requests headers you can fix your site by applying the header via your Content Security Policy7.

Mixed content warning8
Troy Hunt explains how you can fix a mixed content problem caused by a third party9. (Image credit: Troy Hunt10)

JavaScript Link

CSS/Sass Link

Indigogo’s messed up print layout14
Aaron Gustafson’s tweet about Indigogo’s messed up print layout15 reminded Manuel Matuzovic that print style sheets are still a thing16. (Image credit: Aaron Gustafson17)

Work & Life Link

  • Do you have a plan for your hiring interviews? The people at GitLab certainly have, and they share it with the public: Read their Hiring Guide18 to get some useful advice on writing job ads, handling rejections, and conducting interviews.
  • Garann Means quit the web industry about two years ago. Now she shares what that really meant to her19, why she did it, and why it’s important that we think very carefully about it before we take this step for real. It’s easy to joke about leaving the industry, but the consequences are real and might differ a lot from what we expect.
  • Theo Nicolaou wrote about web development and pressure20. Even if we don’t read articles every day, work on side-projects all the time, or contribute to open-source projects regularly, the web will still be here tomorrow, and we can still help to move it forward and make an impact. We need to remind ourselves that sometimes it’s okay to just do something different, to relax or go out with friends.
  • “You Are Not Paid to Write Code21.” Tyler Treat wrote about our job as developers and why we introduce the possibility of failure into a system every time we write code or introduce third-party services. Our job is to find solutions that (if possible) don’t require a new system and to keep out everything else from a codebase unless it’s really necessary.

And with that, I’ll close for this week. If you like what I write each week, please support me with a donation22 or share this resource with other people. You can learn more about the costs of the project here23. It’s available via email, RSS and online.

— Anselm

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23

↑ Back to top Tweet itShare on Facebook


Anselm Hannemann

Anselm Hannemann is a freelance front-end developer and architect and cares about sustainable front-end experiences and ethical choices in life. He curates the WDRL, a weekly handcrafted web development newsletter that thousands of developers love and subscribe to.