Web Layout Best Practices: 12 Timeless UI Patterns Explained (2026)

12 timeless web layout patterns including cards, grids, F-pattern, Z-pattern, and more

Great web design starts with the right layout. No matter how striking the visuals, users come for content — and the layout is the vehicle that delivers it clearly, intuitively, and at scale.

Some layout patterns have endured for decades because they align with how people actually read, scan, and interact with screens. In this guide, we break down 12 proven web layout patterns — from cards and grids to F-patterns and asymmetry — with real-world examples, best practices, and tips you can apply today.

Need to move from layout concept to interactive prototype fast? UXPin Forge generates page layouts from text prompts, screenshots, or URLs using real React components — so you can test ideas with users before committing to code. Start a free trial.

Take a look at how to present your web layout in the most powerful format possible.

1. Cards

Facebook

Twitter

Oprah

Problem

Browsing is a large part of site interaction, but displaying the details for each item would clutter the screen.

Solution

Cards allow sites to present a heavy dose of content in a digestible manner. As we explain in our Web Design Book of Trends 2015–2015, cards are popping out everywhere lately, and this pattern’s success is directly related to its usefulness.

Cards act as containers for clickable information: bite-sized previews to help users find the content they want. The style of the cards varies with each site, but most contain an image and description, and sometimes individual functions, such as Facebook’s Like or Twitter’s Retweet.

Moreover, cards work well with responsive design. Since each card is self-sufficient, their placement can be rearranged to fit any screen size.

For sites with a lot of content, cards offer a lot:

Intuitive — don’t require instructions.
Advantageous for responsive design — since each card is self-sufficient, their placement can be rearranged to fit any screen size.
Shareable — easy to share only specific content on social media.
Versatile — can be used with a wide range of site styles

Tips

Make the entire card clickable, not just certain portions. Fitts’s Law, described in Interaction Design Best Practices, states that this makes user interaction more likely.

Focus each card around one central concept, and no more. Otherwise, that defeats the purpose.
Keep smaller screens in mind when selecting images. You may need to crop them differently for different devices.
Don’t get too complex. Cards work best when they’re simple, in what they show and how. Basic typography and minimal description helps browsing.

2. Grids

Problem

Content-heavy sites want to display all primary items with equal hierarchy.

Solution

A grid structure makes browsing easier. Cards are almost always laid out in a grid format, of one kind or another. Grids offer more options for browsing than simple list views, which makes this style space-effective.

Grids can vary in size, spacing, and the number of columns. Sites like Huffington Post stagger their options to avoid that “straight-laced” feel, while YouTube plays up the strict organization, with straight rows and grouped into categories (“Recommended,” specific channels, etc.).

Tips

Pay attention to white space (or lack-there-of, as with Diply) because it influences how users browse. Ample space is slower, but with more attention placed on each item. Minimal space is faster, but risks some content slipping through the cracks.
Consistency is important, especially when designing for different devices. Make sure your layout stays recognizable at different responsive breakpoints.
Get started with a basic 12-column grid with tools like 960js.

3. Magazine-Style Layout

Problem

A site has a lot of regularly-updated content in multiple categories.

Solution

Magazines had this problem long before websites, and the format they evolved remains viable. The alternating sizes of columns, cards, and/or headlines breaks up the monotony of the grid, while still showcasing a variety of content.

The magazine layout changes up how content is displayed. The left side of the screen might be dominated by a grid of cards, while the right side might have a list of text links.

Take BuzzFeed, for example: the first column is featured content, with a detailed description next to the picture. The middle is timely content, with a brief description under the picture; and the last column is what’s trending, numbered pictures with no description. Pay attention to their typography — text colors and sizes vary to show usability and create a visual hierarchy.

Tips

Like print magazines, this format emphasizes images. As with TIME, WebMD, and WIRED, there is usually one dominant feature image on the screen to draw focus before users scan the smaller, secondary images.
One of the characteristics of this style is a vertical menu on either side (or horizontal menu).

4. Container-free Format

AOL

Apple

Public-Library

Cienne NY

Problem

A site wants a minimalist approach when presenting data.

Solution

The container-free format takes minimalism to the next level, stripping away all unnecessary visuals and breaking away from the conventions of other sites. Rather than clear-cut divisions, this pattern format relies on visuals, grouping, and common sense to show relationships.

Historically, web design has relied on linear and highly structured layouts to present information. This works well, but with more options available today, designers can experiment “outside of the box.” This style appeals to agency (Public-Library), portfolio, and fashion sites (Cienne NY), which all value appearing modern and avant-garde.

Designing without containers puts more power back to the content itself. However, extra care must be given to the visual hierarchy. This risky pattern is only as effective as the people designing it.

Often the face of minimalism, Apple disregards containers for its site. Links are all textual (no buttons), and a clever visual design explains which content relates to what.

Tips

Typography is vital to designing without containers. Size, typeface weight, and color all communicate meaning in place of blunt dividers. Apple uses large text for the title, smaller text for the secondary description, and blue text for links out.
To prevent confusion, make most elements clickable. If the user is confused about an element, they will likely click on it first to test interactivity.Content-heavy sites have difficulty with this format, although AOL shows that it’s possible (although not always ideal).

5. Split-Screen

Google Translate

Adidas Football (UK)

Peugeot

62 Models

Lauren Wickware Design

Problem

A site has two main pieces of content that are equally important.

Solution

The split-screen layout is the logical and trendy way to give two contrasting elements equal consideration.

The split-screen is a choice for displaying two central elements simultaneously or — as the Adidas example shows — pit them against each other. This is a good choice whenever you don’t know which of two elements to feature prominently: do both.

Split screens are perfect for when the site offers two drastically different variations, such as the genders in 62 Models. Users make their selection right from the start, so the site doesn’t waste time showing both options needlessly. Split screens also give the opportunity to feature two calls-to-action, as with Peugeot.

The style has since grown to become purely aesthetic. Most common is having text on one half of the page, and a header image filling the other, as with Lauren Wickware Design. Both sides are two aspects of the same concept.

Tips

The split-screen is ideal for contrast. As designer Patrick McNeil suggests, play up the duality with opposing characteristics, such as opposite colors, different text sizes, the nature of the image, etc.

Retain a single, unified navigation menu — ideally at the top, where it’s clear that it applies to both sides.
Split-screen designs do not expand well with as content grows, so do not apply them to content-heavy layouts.

6. Single-page Layouts

Problem

Multi-page navigation system is too convoluted or unnecessary.

Solution

Modern web development has paved the way for single-page sites and web apps. Both technological advancements and the prominence of mobile browsing (in which single-page apps are more useful) gave rise to this pattern, which is restructuring how the web works.

Using AJAX, single-page web apps load asynchronously and are able to combine multiple actions into one page. This pattern is also popular for non-app sites, which section off their home page to serve the needs of individual pages.

Gmail, for example, allows email reading, composing, and chatting on the same page, and even organizes emails into separate categories, which mimics a multi-page site. Spotify, too, multitasks by allowing the user to play music while they browse additional music, uninterrupted by loading pages.

Tips

Generate unique URLs for each viewpoint, like Gmail or Twitter. Because content is loaded dynamically using JavaScript, URLs require special attention. Unique URLs also enable use of the browser’s Back button.

Use sticky navigation to reduce disorientation, even if only a header menu.
Apply the scrolling techniques from Chapter 4 of Web UI Patterns 2016 (Vol.1) to properly deal with scrolling issues.

7. F-Pattern

Yelp

Groupon

The New Yorker

Problem

Users are having difficulty browsing text-heavy sites.

Solution

If there is a lot of content — especially text — users will respond better with the F pattern layout, which mimics the way people scan naturally.

The Nielsen Norman Group explains how eye-tracking studies revealed that users (in left-to-right reading cultures) typically scan heavy blocks of content in a pattern that looks like the letter F or E. Our eyes are trained to start at the top-right corner, scan horizontally, then drop down to the next line and do the same until we find something of interest.

For example, if the user is scanning a blog entry, they will look at the first line of a paragraph for keywords or to gage the meaning, and if it’s not what they want, they’ll drop down to the next paragraph.

When there’s a lot of content, the F pattern organizes it into horizontal rows, one on top of the other. This creates pathways for the users’ eyes to go where they would normally, and gives the designer more control over what gets seen.

Yelp uses perfectly aligned vertical columns to give the users a starting point. When they find an interesting topic (or picture), their eyes scan horizontally for more information. If the item in the vertical column doesn’t interest them, they go down until they find one that does.

Tips

Place the most important content like CTAs at the left and right sides, where the user begins and ends their horizontal search. This momentary pause as they drop down gives them a little extra time to consider.
Start new paragraphs with enticing keywords. Additionally, try highlighting keywords within text, since that’s what users are looking for anyway.
The first two rows are the most important. Users may leave the site if they don’t find what they want there.
Use the right-side column to display relevant, but unrelated content, or as a search tool. This area is seen, but is regarded as outside the scanning process.
Read our Web UI Design for the Human Eye: Content Patterns and Typography for more explanation and best practices.

8. Z-Pattern

TripAdvisor

Kentucky Fried Chicken

Wunderlist

Problem

A site has a specific agenda or call-to-action that users are not interacting with.

Solution

Like the F pattern, the Z pattern layout mimics natural user scanning methods. However the Z pattern is better suited for sites with a singular goal and less content.

The Z pattern is effective at directing user attention to specific points by using well-placed visuals, text, and CTAs. While the F pattern is better for browsing heavy content, the Z pattern guides users through more open pages.

The user (in left-to-right reading cultures) again starts in the top-left corner. Instead of dropping down directly, however, their eyes wander a bit in the middle, then start again at the bottom or near bottom left corner. You can encourage this pattern by placing a telling image in the center (TripAdvisor), or by alternating text and images to create a zigzag.

Tips

Place CTAs on the right side, at the end of the line: user will slightly pause at the end before moving down.
Place your most important CTAs in the upper right corner, since the top line is the most visible.
The Z pattern can be repeated over and over on the same page, so that the user developers a rhythm that keeps them there.

9. Horizontal Symmetry

Starbucks

Budweiser

Problem

A site includes many recurring visual patterns that must be organized clearly.

Solution

A visual phenomenon occurring in nature, symmetry is generally regarded as beautiful and creates a sense of order and structure, even trust.

Because they are visually pleasing, symmetrical images are more likely to create an emotional connection with users, which improves their enjoyment of the site, how they identify the brand, and how well they recognize the site later.

Tips

Balance is not necessarily symmetrical. These are two different, though related, concepts. For more on visual balance, read this Smashing Magazine article.
From its fine arts background, symmetry adds an air of elegance and sophistication to a site’s appearance.

10. Approximate Horizontal Symmetry

eBay

McWhopper

Problem

Horizontal symmetry is too structured for a site.

Solution

Approximate symmetry retains most of the benefits of symmetry, but with a little added vitality. It is created by adding slight asymmetrical aspects to an otherwise symmetrical image. The result is a more stimulating visual, though it loses a small amount of structure.

The slight visual disruption, however, can work to your benefit.

Tips

To grab more attention, place important lines of text, images, or calls to action in areas that break up the symmetry.
A little goes a long way; even altering a symmetrical image slightly produces visual tension. Likewise, you can create asymmetry by just placing a sidebar in an otherwise balanced design. Add your disruptive elements carefully, otherwise you risk complete visual clutter.

11. Radial (Rotational) Symmetry

Wikipedia

Technics

Problem

A site wants to draw attention to a central point and motivate immediate action.

Solution

Radial symmetry creates balance in a circle around a central point. While difficult to apply, when done well this creates a beautiful aesthetic that attracts attention to the center, typically to the company’s name, logo, and surrounding links.

Radial symmetry is also good for showing motion. Circular patterns in general encourage users to continually move their focus around to a natural end.

Tips

Radial symmetry is a good way to stand out while looking good, since it’s not as common as the other types.
Centralize your most important elements, and keep the secondary ones near the edges.
When placing many links around the center of attention, do not complete the loop. For example, notice how Wikipedia leaves the top and bottom of the circle unoccupied. The space creates breathing room for the eye to explore links on both sides.

12. Asymmetry

Beoplay

Problem

Specific feature content must stand out immediately without disrupting visual flow.

Solution

Asymmetry creates tension and dynamism — not practical for every site, but worthwhile if you want a livelier site that clearly shows points of focus.

When used properly, asymmetry can create active space, which means it makes white space more lively. Asymmetrical elements cause the eye to move more rapidly, even across emptiness, which makes the site itself appear more energetic.

However, this style is difficult to apply. Misplaced asymmetry can lead to confusion in the visual hierarchy, or just plain ugliness.

Tips

The use of colors highlights the jarring effects of asymmetry. Both HSBC and Honda use patches of red to push and pull the user’s sight.
To create a slight asymmetric yet organized layout, balance the text on one side with images on the opposing side.
Objects with sharp edges (e.g., a triangle) add more visual weight to an area, which offsets the opposing area. Use these objects carefully since they can quickly unbalance the design.

Modern Layout Considerations

While these 12 patterns remain foundational, modern web design adds new dimensions to consider:

Component-driven layouts — Design systems like MUI, shadcn/ui, and Bootstrap provide pre-built, responsive layout primitives (grids, containers, stacks) that enforce consistency across an entire product.
CSS Grid and Flexbox — Modern CSS has made complex layouts far easier to implement. Many of the patterns above can now be built with a few lines of CSS.
Dark mode and theming — Layouts must work across light and dark themes. Ensure sufficient contrast and spacing in both modes.
AI-assisted layout generation — Tools like UXPin Forge can generate complete page layouts from a text description, a screenshot, or even a URL — then output production-ready JSX built from your actual component library.

Prototype Web Layouts With UXPin

UXPin helps design teams go from layout concept to tested, production-ready prototype:

Forge generates interactive layouts from text prompts, images, or URLs — constrained to your production design system so every component is real and buildable.
Merge brings coded React components into the design canvas. Designers drag and drop the same components engineers ship, eliminating the handoff gap.
Auto Layout makes responsive layouts easy — components reflow automatically across breakpoints.
Production JSX output — Engineers get clean, shippable code instead of static screenshots and redline documents.

Try UXPin for free and bring these layout patterns to life with code-backed components.

Frequently Asked Questions

What are the most common web layout patterns?

The most common web layout patterns include cards, grids, magazine layouts, F-pattern, Z-pattern, split screen, single-page apps, and various symmetry-based designs. Each pattern solves specific content presentation challenges and suits different types of websites.

When should I use the F-pattern layout?

Use the F-pattern for text-heavy pages like blogs, news sites, and search results. Eye-tracking research by the Nielsen Norman Group shows users in left-to-right reading cultures scan content in an F-shape, starting at the top-left and making horizontal sweeps that get shorter as they move down.

What is the difference between the F-pattern and Z-pattern?

The F-pattern works best for content-heavy pages where users scan text in horizontal rows. The Z-pattern suits pages with a singular goal and less content, guiding users diagonally across the page — ideal for landing pages and marketing sites.

How do cards improve web layout design?

Cards break content into self-contained, scannable units that work naturally with responsive design. Each card can be rearranged for different screen sizes without breaking the layout, and they provide intuitive, bite-sized previews that encourage browsing.

What layout pattern is best for responsive design?

Cards and grid layouts are the most naturally responsive patterns because each unit is self-contained and can reflow into different column configurations. Single-page layouts and split-screen designs also adapt well with proper CSS media queries.

How can I prototype web layouts quickly?

Use UXPin to prototype web layouts with production-ready components. UXPin Forge generates layouts from text prompts, image uploads, or URLs using real React components. Designers can then refine with professional tools and hand off clean code to developers.

Web Design Trends 2018: The Complete Guide for Designers

So far, 2018 has been a remarkable year for web design trends. We’re seeing years of design evolution finally come to fruition in trends like Design Systems and Tactile Design, as well as fun and energetic styles like the return of retro. Now more than ever it’s crucial to reflect on what’s happening with web design, and what will continue into the future.

In this article, we discuss the 6 web design trends that are influencing 2018 the most, starting with one that’s shaping up to be a new design necessity.

1. Component-Based Design Systems

If your company hasn’t implemented a design system yet, chances are you will in the next few years. According to the most recent 2017-18 Enterprise UX Industry Report, 67% of those surveyed are now currently building theirs, if they don’t have one already.

There’s a good reason for their success, too. Design systems are the natural progression of style guides and pattern libraries, but with so much more to satisfy the needs of modern companies.

MailChimp, built according to MailChimp Design System.

What is a design system?

A design system includes design standards, documentation, and — one of its central advantages — a UI toolkit with patterns and codes. Design systems aim to ensure consistency across each of an organization’s products, and even within individual products themselves, and to use the optimal design solutions in any given situation.

As Nathan Curtis says, a “design system isn’t a project, it’s a product, serving products”.

Because some of these areas can change, a design system is a “living document,” constantly updating itself whenever new or better solutions reveal themselves.

What does a design do in practical terms? Let’s look at the Polaris Design System, used by Shopify. They break their design system into four areas:

Product principles: Mission statements and approaches to product design, such as putting the merchant first and an emphasis on accessibility.

Written content: A style guide for all written content, including grammar/spelling choices, voice & tone, and general guidelines like target reading levels.

Visual properties: All things visual: color, typography, image guidelines, icons, chart presentation, etc..

Components: The nitty-gritty, covering design patterns, their usage rules, and quick-copy code.

Shopify’s Polaris Design System.

How to Create a Design System

You can create your own design system by following these 7 steps from our free ebook Creating a Design System: The 100-Point Process Checklist.

Create the UI inventory: Go through all your products/websites and list all the design patterns used. Rectify any inconsistencies you come across.
Get support of the organization: Present your findings to get everyone else on board. It helps to estimate the number of design and engineering hours wasted on redundant work, plus mention how more streamlined products can improve NPS scores.
Establish design principles: What are the principles that govern your company? Consolidate answers into a master list.
Build the color palette: Standardize your color palette using precise color codes and agree on a universal naming convention
Build the typographic scale: Fine tune your font sizes, weights, line-height, etc. and establish concrete rules for displaying text.
Implement icons library and other styles: Revisit your initial UI inventory and carry over select icons and design choices.
Start building your first patterns: Audit your pattern library to select the ones that best reflect your company, your products, and your customers.

Keep in mind, a design system is never fully finished. Update periodically and keep an eye out for areas that can be improved.

GE Digital, built according to Predix design system.

2. Polygonal Shapes and Geometric Layers

One of the most distinct web design trends of 2018 focuses on geometric themes, specifically polygons and layered shapes. Chances are you recognize this style when you see it, but to put a precise definition on it, a polygon is any closed-off shape with straight lines, typically 3-5 sides. This trend includes every floating triangle and square you see, but also original shapes that fit the definition.

https://www.anakin.co/

The style essentially centers around geometry, either with shapes (both regular and irregular) or basic geometric patterns (grids, planes). Let’s break down its specific components:

Simple geometry

http://www.espn.com/espn/feature/story/_/id/19742921/espn-body-issue-2017

Rather than filling the entire screen, many companies like ESPN above opt instead for more original, but simple, shapes. This can bring other subtler benefits; for example, ESPN’s slanted shapes above influence the natural visual flow, creating a more dynamic screen overall.

Bold Lines to Grab Attention

http://www.mountaindew.com/nba/

Lines are geometry too, so highlighting them fits this style as well. When used correctly, big, bold lines can visually carry a screen, or draw attention to the complementary image.

When using thick lines, you want to pay attention to both color and intersection points. Color will determine where the user’s attention goes, whether drawing attention to or away from the lines. Intersection points inherently become focal points, so use them to your advantage.

Detailing

https://chop-chop.agency/

If you don’t want to commit to a full geometric aesthetic, you can also use this trend for detailings. Polygons and geometric layers are visually interesting at any size, and so they make great secondary graphics or even button icons.

3. Tactile Design

Tactile Design has an interesting origin: it grew from the principles of Material Design, but at the same time it modernized the old skeuomorphism trends from the early 2010s.

In a nutshell, Tactile Design makes objects appear real in a digital space. In the words of Google’s Material Design guidelines, “the material is grounded in tactile reality, inspired by the study of paper and ink, yet technologically advanced and open to imagination and magic.”

https://www.zennioptical.com/

Tactile design is hard to pin down with words, but like the geometric trends, you know it when you see it. Let’s take a look at its common components:

No Borders

https://www.epicurrence.com/

Like the real world, there are no borders or windows; everything is taken in altogether. Certain elements — particularly text — cross over from one element or screen to the next. For this to work, designers make a good use of space so that users know what they can click on and where it will take them. That’s why you often see ample negative space (white space).

Multilayer Design

https://www.apple.com/ios/ios-11/

Just like Material Design, Tactile Design incorporates multiple layers to create a more realistic look. That means lots of drop shadows to distinguish layers and instill a little more realism.

Purposeful Motion and Animation

https://www.getprepd.com/

Tactile Design prefers meaningful motion over more complicated animations just for fun. Moving elements like hover states and transition animations don’t just improve the visuals, they also serve a purpose and improve usability.

Detailed Photography

https://www.adidas.com/us/ultraboost-all-terrain-shoes/S82036.html

Again because of the importance of realism, Tactile Design uses highly detailed photography, a mixture of HD quality and close-up angles. This is doubly beneficial to ecommerce sites, since detailed photos give shoppers a better understanding of what they’re buying.

4. Complex Desktop/Simple Mobile

The desktop vs. mobile rivalry has been around since the rise of smartphones, but what we’re coming to realize is that they’re not rivals at all. They actually work together. According to a GO-Gulf study, around 90% of users complete the same task on multiple devices, across all age ranges.

Recently, we’re seeing a differentiation between mobile and desktop interfaces of a site. Rather than cramming a complex system into a mobile device or moving a simplistic system as-is to desktop, companies are using no-code platforms and other advanced tools to design more device-specific variations of the same product, site, or app. Adalo, for instance, enables teams to build custom database-driven apps across iOS, Android, and web from a single project without requiring developers.

The trouble is knowing what needs to be changed, and how. Below, we’ve collected some top pointers on how to best use mobile device’s individuality instead of just translating a desktop system:

Mobile Alternatives for Complex Interactions

Replace header videos with stills from the video. If you need to include a video on your mobile site, use a link to YouTube.
Don’t use hover effects. Instead, tappable buttons or gesture controls can hide/show information.
Simplify animated effects. They just don’t work as well on mobile. For example, Coach replaces its desktop slider-animation combination graphic with an animated gif on mobile.
Replace dropdown menus with hamburger menus. Love them or hate them, hamburger menus are an established pattern that everyone already knows how to use.
Implement voice activation when you can. This is becoming increasing popular, and may be the new norm in a couple years.
Reevaluate colors and backgrounds. Mobile devices sometimes require more contrast to maintain readability.

5. Modern Retro Design

Even the New York Times admitted that web design is currently in an age of nostalgia. Today, designs are borrowing more and more from the distinct tastes of the 90s, 80s, and 70s. Let’s look at what each of these eras is bringing to the table:

90s: A time when designers where exploring what digital platforms could do. Lots of animation, colors, and moving parts, or else stripped-down designs of pure information.
80s: The pixelation from the budding video game industry mixes with the bright neon culture from period fashion and early MTV.
70s: Muted colors and bold typography — particularly psychedelic fonts — from when print media was still strong.

Using retro styles in modern times requires picking-and-choosing the best elements to use. After all, certain design styles are best left in the past. Below are our suggestions on what to keep:

Old-School Typography

Old-school typography

http://www.sbs.com.au/imyourman/

We see a resurgence of not just big and bold text, but also the fonts themselves. Fonts with elaborate strokes, thick cursive, and/or rough edges are becoming popular again, as are fonts reminiscent of old movie posters.

The key to using such “loud” fonts effectively is moderation. Big and bold typography is ideal for titles and headlines, but can be distracting for secondary information or body text. It’s best to pair loud fonts with a simpler and subtler font for normal copy.

Extreme Colors

Using fonts in design UXPin

https://caavadesign.com/

Whether using muted colors or bright colors, modern web design pays extra attention to color. Color overlays are common, and so is using matching colors to accent other images and illustrations.

Texture and Gradients

Muted colors with UXPin

http://thislandishovland.com/

Like colors, texture and gradients are commonly seen in extremes. Some organizations put plenty of texture to give their sites a more realistic feel, while others are stripping away such effects for a stark minimalism.

Video-game Style

Minimalism

http://mostdecisivegame.com/

Pixelation, mimicking the original Nintendo console, is a popular style even for non-gaming sites. The juxtaposition of low and high fidelity allows for a interesting aesthetic both older and younger generations love, not to mention how easily it stands out.

6. Simple Homepages

Last, a return back to basics. Homepage trends have come and gone over the years, but now we’re seeing simpler home pages that work more as a gateway than a source of information.

This trend actually emcompasses a variety of other trends. So to get a homepage that looks modern, you can utilize any number of the trends below.

Minimalism

Simple hompeges trend

https://evernote.com/

The go-to style for simple and easy-to-use interfaces. You can identify minimalism by its abundant negative space (white space), big & bold typography, and colorful accents. For homepages, color works best to draw attention to your main call-to-action, as with Evernote above.

Flat Design Family

Flat design family

https://www.mint.com/

Flat, Almost Flat, and Flat 2.0 — similar but with distinct differences — all work well for simplifying homepages. Like minimalism, they reduce distractions and take advantage of color flourishes, but flat design is more forgiving of detailed visuals like an HD hero image.

Subtle Animations

Flat design with UXPin

https://www.roystonlabels.co.uk/

flat design

https://www.ditto.com/

Animations can improve both usability and user enjoyment, but they can also distract from your main elements. Lately homepage animations have become more subdued, limited mostly to:

automated animations that move on a fixed schedule
trigger-based animations that move when the user clicks or scrolls

These more subtle animations retain the benefits of movement, but without losing the simplicity that modern homepages are going for.

Beautiful Photography and Videography

Animations

http://www.casangelina.com/

As long as you leave out other attention-stealing imagery, using a solid hero image or video background still can make a simple homepage. It allows the user to focus solely on the subject of the visual, which can have a powerful effect when done well.

Prioritize Readability

Imagery

https://digiday.com/

Particularly popular with long-form content sites, homepages are seeing a renewed appreciation for readability. If you want to highlight your homepage copy, make it more legible by using:

above-average text size (>16 pt. for body copy).
exaggerated leading or line heights (1.75x text size).
oversized gutters.
text color contrasted with background.
centered images and callouts so line lengths remain equal.

Conclusion

Web design in 2018 is making huge advancements, perhaps more than in any preceding year. That makes this year one of change and transition, where fields like mobile design and component-based systems are coming into their own, while older styles like busy pages are retiring.

Now more than ever it’s time to reevaluate your design strategies and catch up on everything that’s been coming to light over the last few months and years.

For more advice and dozens of examples, download the full 78-page free ebook Web Design Trends 2018.

Create Component-Based Websites with Design Systems

While it’s not necessarily a visual or interactive trend, design systems undoubtedly influence the look and feel of all the properties they govern. They provide the principles, tools, libraries, and code that create the trends we see on the web today.

Design systems are becoming more than a trend—they’re a best practice that will last for a long time because of their usefulness. In the coming years, we can expect improved design consistency across the web.

That doesn’t mean that every website will look the same, but rather that each website will be more consistent with itself and with user expectations of functionality and usability.

Design systems help solve the problems of scale that come with large and remote teams working together. They give everyone standardized principles and components, which leads to benefits including:

Faster time to market: Design systems create a Lego-like process where everything is reusable, minimizing the time spent rebuilding the same components.
Consistent UX across platforms and products: Standardized components create a much more coherent “look and feel.”
Less version control issues: If you update a component in a design system, the changes populate across all instances. The design system is the final record of truth.
Easier collaboration and communication: Design systems create a shared general knowledge base and components for designers, PMs, and engineers.

That’s why 69% of 3157 designers surveyed said they were currently building their own design system, if they didn’t have one already.

While only large companies had the resources to build design systems before, new tools and processes have now made it much more feasible for companies of all sizes. We’ve seen it firsthand as small companies and agencies have utilized UXPin’s design systems platform, and modern no-code app builders like Adalo are democratizing app development by pairing AI-powered generation with visual design tools.

Let’s explore the nuts and bolts of a design system, learn how to build one, and showcase a few examples of websites built using a design system.

What exactly is a design system?

First, let’s get the definitions straight.

Design System: The complete set of design standards, documentation, and principles along with the toolkit (UI patterns and code components) to achieve those standards.
Pattern Library: A subclass in the design system, this is the set of design patterns for use across a company.
Style guide: Another subclass in the design system, this static documentation describes the design system itself: how products should look and feel, use cases for UI patterns, correct typographic scales, etc.

Bottom line: A pattern library (e.g. set of symbols and assets in Sketch) and style guide are only parts of the much more robust design system.

How it all connects

First, keep your focus broad and think about the idea of design systems.

At the broadest level, a design system is a living entity containing the common linguistics, principles, and tools to help teams build products coherently. As Nathan Curtis says, a “design system isn’t a project. It’s a product serving products.”

Shopify’s Polaris Design System is one of the best examples. On the homepage, they’ve already broken down all the core sections:

Product principles: What is the purpose and soul behind all the products?
Written content: How should the product’s interface copy look and feel?
Visual properties: What should the “skin” of the product look and feel like?
Components: What are the UI patterns and code components needed to build products coherently across devices?

Shopify’s Polaris Design System

In this case, Polaris is the complete design system of principles, written content, visual properties, and components. The style guide is simply the static documentation on the Polaris website which describes how to use the design system. The pattern library is part of the components in the Polaris design system.

The differences are subtle but unmistakably important when it comes to improving product development. A style guide on its own becomes quickly updated since documentation requires maintenance. A pattern library lacks the instructions and principles for coherent implementation.

The design system ties everything together.

How to create a design system

Now that you know what these terms mean and how they work together, let’s quickly review how to build a design system. Here is a quick excerpt from our 50-page ebook Creating a Design System: The 100-Point Process Checklist.

Create the UI inventory: First list and describe all of the design patterns currently used in your interface and note the inconsistencies therein.
Get support of the organization: Present your findings and explain the utility of a common design language to everyone. As explained in our Evangelizing Design Systems templates, estimate the number of design and engineering hours wasted on redundant work and how product coherence can improve NPS scores.
Establish design principles: Codify your practices. You’re now starting to work on the style guide for the design system.
Build the color palette: When building the UI inventory, we found 116 different shades of grey that needed consolidation. Create the palette and its naming convention.
Build the typographic scale: You can optimize the scale to serve existing styles, or you might try to build a harmonious scale using the golden ratio or major second. When building the scale, don’t forget that you’re not only setting the size of the font, but also weight, line-height and other properties.
Implement icons library and other styles: Decide which icons from the UI inventory will become part of the design system, then standardize the implementation.
Start building your first patterns: This is the task that will never end. Patterns should always either reflect the truth about the product, or reflect the aspirational state of the product in the near future.

Websites built with a design system

You can find plenty of websites that describe each company’s design system.

But what does a website look and feel like when it’s built with a design system? It is much more logical, consistent, and better-performing thanks to less code bloat.

Here are a few websites that were built with the principles and toolkits of some of the best design systems around.

GE Digital

Built according to Predix design system.

Shopify

Built according to Polaris design system.

Atlassian

Built according to Atlassian Design Guidelines.

MailChimp

Built according to MailChimp Design System.

Github

Built according to Github Design System

This is an excerpt from our full-length ebook, an overview of web design trends. You can read the full ebook for free here. If you’re interested in learning more about design systems, click here to view recordings of UXPin’s Design Systems Virtual Summit. Try UXPin’s design systems capabilities for free here.

UXPin is the design process tool that helps product teams around the world turn ideas into products faster.

With Merge, UXPin’s revolutionary technology, companies like PayPal can easily solve DesignOps challenges. UXPin Merge allows you to design with React components to achieve full consistency with the final product.

Virtual Summit Recap: Atlassian Shares 4 Pointers on Design Systems

Allard van Helbergen, Senior UX Designer at Atlassian, speaks from Sydney about what he and his team learned from 16 years of design system evolution.

Why do you build a design system? The popular answer is to maintain consistency across different products and different teams, but a well-made design system also reduces cognitive load and increases the speed of development overall. There is one reason, though, that stands over the others, the ultimate reason. Design systems help users.

Atlassian has known the value of design systems for quite some time, but it took years of practice before they realized just how powerful design systems are — and how to best utilize them.

Jira UI 2002

Through gradually refining and improving their designs over ten years, Atlassian created its first official design system in 2012. Back then, the goal was primarily to ensure consistency across all of Atlassian’s products, and their first “design system” was actually closer to a traditional style guide.

Jira UI 2017

For the next 5 years, Atlassian developed and fine-tuned their design system, learning some valuable lessons along the way — namely that it could be do more than just maintain consistency. By 2017, their latest version placed more emphasis on reducing friction in product interfaces, and to this end they added the complementary Atlaskit, a move that defined the capabilities of design systems.

The Atlaskit comes equipped with standard UI components that not only help designers maintain consistency by using the similar parts, but also offer the best ready-made UI options for better performance. The kit’s components are built around actual user preferences, so standardizing them saved time for each product.

But, as our speaker explains, “there’s a lot more to it than just delivering UI components.”

Over the years, the process of refining the design system taught Atlassian a lot. Senior UX Designer Allard van Helbergen was kind enough to share some of these Learnings during UXPin’s Design Systems Virtual Summit 2018, which presented case studies from companies like Salesforce, IBM, Airbnb, GE, Linkedin, Fjord, Zendesk, and more.

Focusing on two specific UI components, inline and modal dialog windows, Allard takes us through the four most important pieces of advice for design systems, and how to apply them. Take a look at the recap of his presentation below.

Learning 1: Tension between product and design systems is healthy.

One of the hardest parts to grasp about design systems is that their components never quite fit perfectly out-of-the-box. The design system and the product work together, but do different things. “At some point your product will be leading [the design]. At another point, your design system will be leading.”

Rather than fight this tension, Atlassian learned the smarter solution was to use it to their advantage. There is no “one size fits all” component that would work perfectly with every product, so they needed to add a degree of customization. They found that, by leaving some room for growth in their design system, the components could be slightly modified to suit whatever the product’s needs are.

“What happened was,” Allard explains, “the component that was taken from the design system had a shortcoming and didn’t allow the product to do what they needed to do. So products reached out further and made their own decisions.”

To illustrate his point, Allard shared a real-life example. Compare the design systems entry for inline and modal dialogs…

… to some of the final variations that ended up in the products…

The modifications are minor, not nearly drastic enough to threaten consistency across products. At the same time, the small changes add some new life to the design. Tweaks like color changes, illustrations, or adding a pulsing dot can be just what the product calls for, so it’s crucial to leave that possibility open.

Atlassian gives product design enough freedom to build and change components based on their own individual use cases. This gives designers room to experiment and create variations, which opens up the possibility of improving on the original designs, especially considering individual product needs.

Design systems simply can’t account for every need for every product. You wouldn’t want them to, either; that kind of cross-product uniformity would limit all your products, not to mention appear repetitive for multi-product users. So to get the best of both worlds, Atlassian provided the foundation for UI components in their design system, but gave enough flexibility that individual products could modify them as needed. This philosophy extends to how enterprises organize their data and systems as well—platforms like Adalo embrace similar principles by allowing teams to build custom database-driven apps with flexible components rather than forcing a one-size-fits-all approach.

Learning 2: Look at what’s in product, synthesise, and build forward.

To perfect each component, Atlassian relies on feedback, whether user research, usability testing, or comments straight from the users themselves. Normally, each individual product would iterate the feedback into progressive prototypes and move forward on its own. Atlassian, though, encourages synthesising the feedback from all products first.

For one thing, accounting for feedback from all products adds enough diversity to balance everything out. As Allard explains, “Some products might have made some bad decisions or some products might have taken shortcuts along the way. So this is a moment when you can fill those stop-gaps and help them get that extra kick.”

The other major advantage of synthesising feedback is that the individual components are stress-tested in multiple scenarios, providing a more accurate understanding of how they should be treated. This provides extensive data and opens up improvements that a single product’s feedback wouldn’t reach on its own.

This is the method that helped Atlassian develop two new components, both born from the feedback of previous iterations. The Spotlight is “essentially a type of chaperon that will show you around the interface,” while the User Benefit Modal can “help you kick-start your new experience, telling you some highlights and why this experience is good for you.”

By looking at the entire forest instead of the individual trees, Atlassian was able to identity some UI elements that were missing across the board, and subsequently add them.

Learnings 3 & 4

We don’t want to give too much away in the recap. To learn more about how Atlassian handles design systems — straight from the mouth of a senior designer — watch the video below.

The hour-long video covers all 4 learning points, plus an informative Q&A after the presentation with questions from designers all around the world. You’ll discover a lot of professional insights straight from the mouth of an expert, such as:

How to incorporate user experience into component design.
How to build a cohesive user flow by combining chains of components.
How to synthesise experiences the same way as components, including a case study of Atlassian’s process.
Why you should build your design system as if it were a product
A personal account of how Atlassian evaluated their product line for a “roadmap alignment” to see which design system components to prioritize.
More trade details about how Atlassian devised their “First Impression” framework for onboarding.
Realistic time frames for building and implementing design systems.
The best ways to introduce design systems to other departments internally, and how to get them on board.
Recommendations for follow-up resources on how to start building a design system.

To see Allard’s presentation in its entirety, click the video below now.

Webinar Recap: Scaling UX Teams at Atlassian

Alastair Simpson (Head of Design for Confluence, Stride, and Platform) shared the lessons learned in the past few years as he helped grow the UX organization at Atlassian.

Working for clients in both Australia and East Asia, Alastair first noticed that design teams seemed to be a separated service to product teams, much the same way that consultants were a separated service to the client.

In both scenarios, there was a gap between the two, where one party held more authority over the other. With consulting, this is reasonable; after all, consultation is a paid outside service. But for design to be separate from product management and engineering seemed counter-intuitive.

Wasn’t there a better way?

When Alastair began interviewing with Atlassian, he learned of a “new” model… at least new at the time.

Atlassian’s triad model helps design, product management, and engineering worked together on equal footing. Rather than the product team having authority over design, or design having authority over the product team, the only guiding factor was the user experience. And so, the triad model became the foundation of the “experience-led” process.

This is echoed by a direct quote from Atlassian’s Head of Design Jürgen Spangl, “If the experience is not right, you should stop the release.”

This mentality wasn’t easy to integrate at first. It required evolving the company culture to place more value on design and user experience. This isn’t about giving designers a bigger “seat at the table,” but about spreading the experience-first thinking throughout the entire company, among all employees.

Naturally, changing an entire company culture is not easy. Atlassian accomplished it over the years through trial-and-error, learning lessons the hard way to discover what works and what doesn’t.

Specifically, Alastair lists “5 hard lessons” he and Atlassian learned along the way. He shares these lessons in the video above, so your company can get a knowledgeable head start in building the perfect team dynamics.

Lesson 1

“You can have the best design team in the world, but if your organisation doesn’t truly value design, it doesn’t matter.”

~Alastair Simpson, Atlassian

Atlassian didn’t hire their first designer until 2008, and from 2008 to 2012 the design org grew to only 6 people. This was at a time when the company was booming, with both product development and engineering teams experiencing double-digit growth.

At that time, the industry was more focused on product and engineering, and design answered to these areas. Design’s value was almost negligible and innocently confused with other disciplines.

Enter Jürgen Spangl who joined the company in 2011. Jürgen reorganized the company infrastructure so that design was seen as “more than just pushing pixels around.”

As Alastair explains, one of the first changes Jürgen lead was creating a design system (Atlassian Design Guidelines, known as “ADG”) to improve design cohesion and product development efficiency.

Atlassian Design Guidelines made a lot of sense. From a design perspective it was smoother, from a product perspective it was consistent, from an engineering perspective it was less redundant coding to be done. But most important, it benefitted the customer — familiar and comprehensive interfaces reduced the cognitive load and minimized distractions. It wasn’t so much a design decision as it was an experience decision.

What made this decision so monumental was partially that the customers didn’t request it. No one mentioned standardized drop-down menus or interface visuals in customer feedback. So, going back and changing these elements to be normal was taking engineering resources away from building new features that the customers actually asked for.

As you can imagine, folks were skeptical at first and Jürgen essentially “bet his job on this,” as Alastair puts it. Regardless, the founders trusted him and backed him. The gamble paid off because the customer feedback was overwhelmingly positive to ADG.

The customers weren’t the only ones who benefitted. Product releases were faster and more consistent. Thanks to reusable components, teams could go from whiteboard sketches to working designs more quickly. ADG was tangible proof that experience-led design worked.

So, by contrast to hiring 6 designers between 2008 and 2012, Atlassian hired over 100 new designers between 2012 and 2016.

Design was no longer a service to product and engineering, but an equal partner.

Lesson 2

“Pain is temporary. Suck is forever.”

~Jason Dreamer, Pixar

Making changes is hard. Receiving feedback and criticism is hard. Unearthing and fixing foundational errors is hard. But a bad user experience is worse.

To improve and evolve their design mindset, Atlassian integrated a process they call “design sparring.” As Alastair explains, this isn’t sparring in the sense of a competition, but the proper sense: a learning exercise. Atlassian’s design sparring incorporates peer reviews and honest feedback to help designers learn and thereby improve the final product.

Design sparring at Atlassian promotes 4 key ideals:

Design-led. Designers facilitate their own design sparring sessions.
Structured. Sessions are recorded and documented for quick reference later.
Inclusive. Product managers, engineers, QA reps, and customer advocates all attend to offer their expertise.
Regular. Sessions occur periodically, at least every two weeks.

Echoing the previous lesson, many of the teams outside of design were unclear on the role of design. These inclusive sessions allowed designers to involve the rest of the company in the value of their craft.

Atlassian designers created the above visual to illustrate in no uncertain terms the design process along these 3 core steps. By sharing this visual aid on the internal server, all employees had a comprehensive guide to the design process and where they fit in.

Design is always a collaborative exercise, and there really is no “design only” stage. The better other departments understand design, the better the final product.

Lessons 3-5

In additional to the lessons above, the rest of the webinar covers:

What is “radical candor” and why it holds the key to productive company communication.
How to give constructive criticism in a respectful way.
The Atlassian method of self review and performance review via the Skills Matrix.
The Shuhari framework and how it translates into a 90-day plan for keeping designers on track.
What is “design detention” and how it can solve a lot of common design problems.
The progression of Atlassian’s Design Week tradition over the years.
How to differentiate the separate disciplines that are often incorrectly lumped together as “UX.”
How to break down UX metrics into a structured scorecard to streamline organization.
How accountability works in the triad model, and getting all teams to pull in the same direction.
Q&A session with Alastair answering questions from webinar attendees.

Inside Atlassian’s Design Process: The Power of Autonomous Teams

Designing at scale is one of the greatest challenges faced by product teams today.

What activities are required? How do you govern collaboration and decision making? And what about delivering quality on time?

Atlassian Sydney office.

To find out how a global enterprise tackles the challenge, we spoke with three members of the Atlassian Design team:

Ashleigh Sterzenbach – Senior Product Designer
Erin Howard – Senior User Researcher
Alastair Simpson – Head of Design, Confluence, Hipchat, and Platform

They revealed how the 2,200+ employee company structures its design team and process for collaboration, efficiency, and product quality.

Team Structure

Starting with just 6 designers in 2012, Atlassian’s design team has since grown to almost 200 employees, including designers, writers, and user researchers. The team is lead by Jürgen Spangl, the current Head of Design, who reports directly to the CEO.

The design organization covers five disciplines:

Information experience – Crafting the product content, interface copy, technical documentation
User research – Researching and validating user needs
Product design – Product improvements and new product development
Creative team – Creating interactive marketing projects
Design operations – Putting in place the right tools, processes, and vision to make design teams successful

Within the design operations group, the design systems team consistently pushes the boundaries by working with all product teams to implement the latest design language. Meanwhile, the information experience, user research, and product design teams fully embed into product teams.

To govern product development, Atlassian uses the triad model in which engineering, product management, and design all collaborate in making decisions.

“You need healthy tension in the triad for solving engineering, business, and customer problems,” says Alastair. “If product performance suffers because of technical debt, it doesn’t matter how polished the features might feel. The triad is ultimately responsible for the whole experience.”

Based on the yearly strategy for the company and its product schedule, managers guide their teams in the right direction instead of prescribing every step of the roadmap. Whilst managers influence the overall strategy, the product triads have full autonomy to make decisions – managers don’t need to sign off on everything all the time.

Once a project starts, regular critiques and check-ins let managers ensure the triad’s work matches the high-level strategy.

“Individual contributors are given a lot of flexibility to investigate use cases and problems instead of following a baked-in roadmap that defines everything,” adds Erin. “And that helps us avoid the historical problem in tech of shipping quickly to hit a deadline without checking if the right problem is being solved.”

Atlassian’s Agile Design Process

To balance product quality with speed of implementation, Atlassian practices a design process that’s both structured and highly fluid. Following an Agile methodology where incremental updates are shipped regularly, product teams rely on collaboration rather than a purely linear process.

1. Creating context and alignment

The process always starts with reviewing data and research to identify knowledge gaps.

If they’re working on improving current features, for example, they may start with qualitative and quantitative data around product usage, use cases, and user activity. New product or feature development, however, requires more qualitative insights from generative research.

The team may spend up to a few weeks validating quick prototypes and running user research to make sure they’re honing in on the right problem statement:

Who has the problem, and have we validated the problem exists?
What is the problem? What data or research supports our assumptions?
Why is the problem worth solving? What is the customer and business impact?
Where does this problem occur?

Team members are encouraged to identify areas of risk and even pause the process to investigate further.

“As a user researcher, I’m hardwired to bring skepticism into the process,” says Erin. “For example, we once stopped the momentum of a product update because user comprehension wasn’t where it needed to be. We ended up running some more research studies and were able to solve the issue and deliver the right thing in the end.”

To create a complete picture of the customer journey, the triads will also conduct multiple explorative workshops and activities (described in more detail in Atlassian’s Team Playbook):

Competitor analysis
Writing a press release for the idea (like Amazon’s work-backwards tactic)
User interviews, contextual inquiry, surveys, and other ethnographic research
Baselining experiences
Project canvas
Experience canvas
Job stories
Persona cards and role cards

“You don’t want to jump into solutions too early in the process,” Alastair says. “Shipping doesn’t equal success — moving metrics for customers and your business does.”

2. Collaborating on ideation and creation

To deliver customer value as quickly as possible, product managers will help developers and designers break down large problem statements into smaller chunks of work. Members of the triad will then pair up to tackle each chunk of work.

“Engineers may not push pixels, but they’re absolutely involved in creating ideas,” Ashleigh says. “We pair up designers and developers as part of the process.”

When concepting, it’s quite common for designers like Ashleigh to run in-depth sketching sessions where designers, product managers, and developers all participate. In fact, the team rarely goes 24 hours without gathering feedback – whether it’s for a sketch, a wireframe, or a hi-fidelity prototype.

Product teams alternate between heads-down time and collaborative sessions with a strong regimen of activities:

Standups (daily) – The triad reviews a “highlight reel” of updates, challenges, and to-do items for their projects.
Team sparring (weekly) – A designer will explain the context and reasoning behind the designs, then ask peers in the triad for feedback. Each person marks up feedback individually, then the group debates the feedback. The designer then explains what feedback will be incorporated in the next version, and what won’t.
Design detention (biweekly) – Designers across all product teams gather together (3 hours to the full day) to tackle challenges individually or in pairs, with sparring sessions happening afterwards. Email, chat, and meetings are all put on hold.
Design blitzes (monthly) – Like a compressed design sprint, the triad collaborates across several hours on a complex challenge.

“There’s never just a ‘design-only’ phase,” Alastair says. “Sure, designers might be creating mockups on their own at some point, but everyone is involved in solving customer problems. You don’t build good products in isolation.”

3. Measuring the impact

Throughout the product development process, the triads regularly measure their work against the baseline metrics defined in the beginning.

Using tools like Attrakdiff, Treejack, and UserTesting, Atlassian summarizes the results of its user research and usability testing in a Non-Instrumented UX Scorecard with data like:

“We always baseline and measure against what’s in the product today to ensure the new experiences are heading in a positive direction,” Ashleigh says. “This helps us build confidence in our design decisions as we move through the design process and continue to iterate.”

Atlassian’s UX Scorecard.

4. Shipping carefully and measuring regularly

Atlassian’s policy on shipping is best described as “measure twice, cut once.”

“We don’t work off an agency model,” says Alastair. “Designers are involved all the way through shipping.”

In fact, more technical designers can even participate in code reviews. The cycle of iteration, QA, and measurement allows triads to push both front-end and back-end updates to its cloud products every day.

After a product or feature launches, the triad tracks metrics in a Instrumented UX Scorecard. Now the team can check the real impact of the new experience by measuring the progression of customer behavior metrics.

“Millions of people on teams around the world depend on our tools to get work done,” says Alastair. “We must be purposeful and thoughtful with how we release changes.”

Conclusion

As Atlassian’s process shows, sometimes the key to a scalable process is in executing the fundamentals well.

Give design a seat at the executive table, structure product teams for natural collaboration, then give them room to make decisions every day. Replace bureaucracy with guidance and the self-governance model can actually succeed at scale.

“No team wants to be micromanaged. Every team wants ownership and accountability over what they’re building.” says Alastair. “Managers can’t oversee all the details — you hire smart people, ask the right questions, then get out of the way.”

Interested in being a designer at Atlassian? To see available positions, check out Atlassian Design Careers.

Scaling UX: A 4-Step Framework for Design Leaders

Because it’s part science and part art, UX just doesn’t scale as cleanly as engineering.

All design processes eventually break. The trick to scaling UX is creating a flexible framework that adapts to size and design maturity over time.

Based on research that our friend Jason Culbertson (Design Manager at Airbnb) conducted with product design leaders at Airbnb, Gusto, and other companies, the framework he created explores the following areas of a UX practice:

Tools & Systems – What core criteria should be used by UX leaders and their teams to evaluate tools? How can design eventually become a system rather than individual practice?
Team Structure – How can UX teams evolve their structure over time to support more projects?
Collaboration – What processes and rituals help prevent siloed design?
Culture – How can UX leaders create a design-first culture in the company? How can they create a UX vision that inspires and guides their team in the long term?

In this article, we remove the mystery around scaling design by explaining each of the four steps above.

For more best practices, register for UX at Scale Virtual Summit 2017. Get advice on scaling UX from 15 design leaders at Atlassian, Salesforce, Autodesk, Linkedin, Airbnb, and more.

Tools & Systems

Tools and systems form the base of the pyramid. They enable quality and consistency of the experience across products.

Tools

Cloud-based tools facilitate scaling because they help you preserve a single version of the truth. As design teams grow, so too does the risk of “design fragmentation” with desktop tools. Version control just becomes more difficult.

When evaluating design tools, consider the following criteria:

Collaboration – How does the platform facilitate communication with other teams in different offices and time zones?
Consistency – Can different people update and reuse “approved” design patterns to create a consistent look and feel in all projects?
Control – What interactive and visual fidelity does the platform support? How does it manage versioning and permissions across members of different teams?

The ultimate goal, of course, is a standard toolkit used by product development teams to fulfill:

Project management
Requirements management
Collaboration
Usability testing
Prototyping
Visual Design
Asset Control
Development Handoff

If you use multiple tools, check that they transition well into each other’s workflows. For example, if your team uses a static lo-fi wireframing tool and a separate prototyping tool, they will lose efficiency when rebuilding their designs (assuming the two don’t integrate). Tools like Adalo exemplify the kind of integrated platform that designers increasingly need—where prototyping, design, and deployment capabilities exist within a single environment.

Systems

Once your UX team grows beyond 15 designers and your organization expands beyond 500 employees, you’ll probably need to build a design system.

At scale, product teams require reusable patterns and code components for creation and maintenance. Your design system, then, becomes the final component in your design toolkit.

Here’s some useful examples of sustainable design systems (more here):

One noticeable challenge in using a design system is referencing the right components on an everyday basis. If the design system only exists as a site, developers still need to spend time browsing through documentation to find the code snippet they need for a particular component. One solution, however, is embedding your snippets and other documentation in the design itself so that the metadata follows the elements.

Another challenge of using a design system lies in the long-term maintenance. As Nathan Curtis mentions, prepare to evolve your governance structure over time:

With smaller design teams, an “overlord” structure can suffice. One person publicizes their own personal design system. They also own the responsibility for updating the system.
As the design team grows to dozens of designers, you may move to either a “centralized” or “federated” structure. In the former situation, one person or team updates a democratized design system. In the latter situation, multiple teams contribute towards creating and evolving the design system.
You can also follow a hybrid “cyclical” structure like Salesforce and Airbnb in which individual product design influences the system, and vice versa.

The UXPin product team has seen customers be especially successful with the cyclical system. A design system isn’t one way – you need to evolve it based on new learnings from individual projects. At scale, a dedicated designer (or team of designers) certainly helps to facilitate the two-way balance between consistency and innovation across the organization.

An interactive design system in UXPin imported from Sketch.

Team Structure

With the right tools and systems in place, you’re ready to start growing your team and evolving its structure.

Roles/skills (T-shaped)

As Satyam Kantamneni (former Managing Director of UX at Citrix) suggests in his webinar Building and Sustaining Successful UX Teams, unicorns are simply too rare, unaffordable, and usually suffer from a “diva mentality”.

Instead, design leaders need to be more realistic with hiring needs. Seek out T-shaped designers with deep expertise in one area but enough general competency to fill in other roles as needed. As the team grows over time, you’ll experience less of a knowledge gap thanks to the overlap between all members.

A desired T-shaped skillset for a user researcher.

Ratios

The ratios between designers and developers (and even PMs) will evolve over time.

At any size, however, Jesse James Garrett states that research suggests maintaining a minimum of 1 designer: 12 developers and a best-case scenario of 1 designer: 4 developers. In fact, as John Maeda points out in his 2015 Design in Tech report, the ratio for startups is usually 1 designer: 4-5 developers.

Organization

As Jeff Gothelf suggests, most teams progress from the “internal agency” team model to the scalable “hub and spoke model” as more people join.

For example, Airbnb’s current design organization of 70+ designers reflects a highly specialized “hub and spoke model” of designers embedded in other teams but reporting into one central design organization:

Design Language Team – Innovates and updates the design language affecting all Airbnb products. Responsible for the “future version” of Airbnb.
Outcome Teams – Designers embedded in respective product teams. Jason Culbertson, for instance, is part of the “Business Travel” outcome team responsible for that side of the product.
Production Design Team – Creates tools and iconography for designs. Ensures all designs meet Airbnb standards for quality and consistency.

As Jason Culbertson (Design Manager at Airbnb) mentioned in his webinar Scaling UX in Organizations, here are the most common inflection points you’ll experience as a UX team grows:

1-10 – Small enough to where designers may work on different features of a single product, or multiple products simultaneously. UX manager funnels projects through an “internal agency” model. Roles are more general with UI designers, UX designers, and UX researchers. Responsibilities overlap between designers.
11-25 – Specialization increases among the team as it transitions to a “hub and spoke” model. One or two designers may be responsible (part-time) for building and evolving a design system. Designers embed into specific product teams.
26-50 – The design systems team grows in size from 1-2 part-time to perhaps 3-4 full-time.
51-100 – At this size and scale, separate teams may form to fulfill responsibilities for owning the design system, everyday product design, and overall consistency of assets.

Collaboration

A scalable team structure also needs the right collaborative process to sustain its success. There’s no getting around it – as more designers join your team, you’ll need to formalize the collaborative process sooner or later.

Creating and adapting rituals

While it never hurts to formalize a process from day one, we’ve seen that a standardized process becomes mandatory once you’ve grown beyond 10 designers.

Treat creating a standard UX process as its own design problem:

1. Hold a 30-minute session or conference call with senior members of the team to learn their current processes. Diagram each person’s process, then compare for similarities and differences. Note any gaps or redundancies.

2. Create the new standardized process for an upcoming project as the pilot experiment. Choose a bite-sized project (e.g. a feature update rather than a product redesign).

3. Show the first iteration of your the process back to the people who filled in the spreadsheet and participated in the interviews. Take note of any patterns in feedback for your next iteration.

4. After sharing your finalized version with everyone, review on a weekly basis how the process performs in the pilot experiment. Where do roadblocks still occur? Who’s experiencing issues with collaboration? Continue iterating until the team falls into a natural rhythm and you notice a decrease in questions about the process.

5. As people become comfortable with the process, you’ll want to revisit your tool suite. Create a spreadsheet for everyone on the product team to write down their set of tools. Review the document, then see where you can eliminate redundant tools or add new ones. Now you have an efficient process and the right tools for execution.

For example, Sunita Reddy (VP of Product at UXPin) uses the below process for all her Scrum teams.

You probably won’t follow the process to the letter – and that’s totally fine. The goal is to create a baseline to work with.

Working meetings

To keep iterating your collaborative process, we recommend a few recurring working sessions. During his interviews, Jason Culbertson uncovered a common set of efficient meetings:

Standup (daily) – Review progress, blockers, and tasks. To improve scalability, hold standup with individual Scrum teams instead of the entire design team.
Outcome managers (weekly) – Product manager, engineering lead or manager, and design lead or manager in an outcome team will discuss progress, learnings, and pending tasks.
Outcome design crits (weekly) – Designers in an outcome team will share all their work with engineering and product management.
Demo retro with engineering (weekly) – Designers review the week’s releases with developers to discuss successes and areas for improvement.
Design team share (biweekly) – Designers in an outcome team shows off all their work to each other in a rapid slides format.
1:1s (biweekly) – Design manager in an outcome team reviews career development
Design management (monthly) – All design leads or managers for all outcome teams will discuss progress, learnings, and pending tasks.

Of course, your team may not need all these sessions. Below, you can see how the sessions scale to the different inflection points.

Culture

Aside from tools, teams, and processes, you also need to build a sustainable design culture across the organization and within your team. Otherwise, your processes won’t survive past the initial push for change.

Across the organization

If your current company is not design-focused, you need to earn buy-in through a slow and measured approach. Ambitious UX roadmaps and back-to-back workshops will simply overwhelm the team. Instead, consider a system of “design nudges” along the path of least resistance.

At the executive level – Position yourself as a business leader who specializes in profitable design. Explain that you’d like to try some new processes for a small pilot project (less than 3 months), then outline the KPI goals. Ask for support just for the pilot.
At the project level – In parallel to your executive efforts, seek out pressing problems within different Scrum teams. Explain to the PM or engineering lead that you’d like to try a few problem-solving exercises that require minimal involvement. Conduct informal and brief stakeholder interviews, review all existing data, then propose a new solution rooted in design thinking. As people’s interests pique, only then start explaining the details of design thinking (and offering more in-depth sessions).

As you start getting quick wins, circulate your success with project members and executives. Summarize the processes and metrics achieved, then highlight how non-designers helped contribute. You’ll win more executive buy-in for UX while also making others look good in front of their managers (winning you even more supporters).

Across your own team

First, create a UX vision that should remain relevant in 1-3 years time (or longer).

The vision rallies the team and also communicates its value to external stakeholders.

For example, at UXPin, the vision is “unifying design and development for faster and better products”. A vision describes an ideal future state without prescribing a set solution. While tactics, quarterly strategies, and processes may change as teams grow, the vision usually prevails unless the company undergoes a significant pivot.

It usually helps to create the vision as a quick slide deck so that the team can share with stakeholders:

Explain how your vision adds user value and business value, while including relevant research on market opportunities.
Describe the methods you’ll use and how they help to improve the product experience.
Show where design fits into the organization and who the team will collaborate with on a daily basis (and how).
Outline the KPIs used to measure UX performance (e.g. NPS scores, conversion rates, etc).

Secondly, encourage designers to seek inspiration from products unrelated to your industry. Meet weekly to discuss these different sources of inspiration and how they may apply to different projects.

When you’ve built cross-functional support for UX while also defining your team’s culture, the business value of “good design” becomes far more tangible.

Conclusion

Growing a UX practice is a journey in itself.

The 4-step framework we’ve explored should serve you well as a playbook for scaling UX. Remember that it’s just a framework – tweak and adapt it to fit your needs as they change over time.

To learn more about how to create a design system to scale design, download Creating a Design System: The 100-Point Process Checklist.

Building UX Teams at Scale: Inside Atlassian’s Bespoke Hiring Process

When you hear the word “Atlas,” you might think of the ancient Greek giant holding the world on his shoulders.

The software company Atlassian certainly lives up to its namesake as an enterprise with 12 products, 2,200 employees, and 90,000 customers.

Atlassian San Francisco office.

Creating a design team to support that scale is no easy feat. Add to that the complexities a B2B company faces, and you begin to truly appreciate the full scope of the challenge.

Atlassian, however, is breaking the mold of the engineering-driven B2B company. To explore how they’ve built a thriving design culture and practice, we spoke to three members of their design organization:

Karen Cross, Head of Design – Go-to-Market & Ecosystem
Amanda Sampson, Senior Recruiter, Design
Liam Greig, Design Manager – Confluence

Karen Cross,Amanda Sampson, Liam Greig.

They revealed the secrets of their success in finding, hiring, and nurturing the right designers from all around the world.

The Right Team Size and Structure

Back in 2012, the design practice at Atlassian was just a handful of folks. Design coherence was lacking – for example, there were 48 different kinds of dropdown menus alone. Recognizing the competitive advantage of well-designed business products, Atlassian started building its design practice.

Liam Greig (center) during a design feedback session.

First among those hires was Jürgen Spangl, the current Head of Design. His emphasis on a coherent user experience paid off, and in the years since, their firm grew in both the number of personnel and the maturity of their process. Now, with almost 200 people in the design organization and a powerful design system, Atlassian Design is on track to grow by another 20-30 hires through 2018.

Whiteboarding session in Atlassian Sydney’s design space.

“We’re not just trying to grow a design team arbitrarily,” says Liam. “We’re growing our design team so that it complements product management and engineering.”

The design organization at Atlassian currently spans five disciplines:

Information experience – Crafting the product content, interface copy, technical documentation
User research – Researching and validating user needs
Product design – Product improvements and new product development
Creative team – Creating interactive marketing projects
Design operations – Putting in place the right tools, processes, and vision to make design teams successful

And when it comes to maintaining harmony in the product triad, Atlassian uses this ratio as a guideline:

1 designer : 1 product manager : 10 developers

Of course, the ratio isn’t written in stone – it flexes based on the project and skills of team members.

Generalists vs. Specialists: Enter the Design Skills Matrix

Instead of chasing unicorns, Atlassian hires T-shaped individuals to fulfill their five disciplines. Team members specialize in one area of design (the vertical line of the T), but can still fill in other areas (the horizontal T line).

Hiring T-shaped designers is ideal for balanced design teams with cross-functionality. The structure fits perfectly with the career development process: usually new hires work on one product for at least a year to hone their skills. From there, designers can transfer between different products.

So how do they build the profile for their T-shaped hires? Karen Cross (Head of Design for Go-to-Market and Ecosystem) has created a design skills matrix now used globally across all hiring and career development efforts:

But what about coding? Where does Atlassian weigh in on the debate? Well, it all depends.

“Coding certainly doesn’t hurt, but it’s not a must-have,” says Liam Greig, Design Team Lead on Bitbucket. “Again, back to the T-shaped designer — it depends on what we’re looking for in the T-shape. More importantly, can you understand people who code?”

Amanda Sampson (Sr. Design Recruiter) agrees that different design roles require different levels of technical skill. “If we’re hiring a prototyper or growth designer, then they should be able to code. That way they can quickly design, code, and ship an experience,” says Amanda. “For most designers, we care more about how they work with developers and function within technical constraints.” This principle extends beyond traditional software design—companies building everything from mobile apps with Adalo to backend systems need designers who can collaborate effectively with technical teams and understand implementation realities.

The Carefully Crafted Hiring Process

To find the right T-shaped designers, Atlassian follows a hiring process that’s anything but cookie-cutter. Instead of using the same process as engineering and product teams, the design organization created a tailored four-step process.

1. Initial evaluation

The process starts with reviewing a candidate’s resume and portfolio. According to Amanda — who’s taken classes at General Assembly to immerse herself as a recruiter in the designer mindset — a formal design education isn’t as important as how they think.

She’s particularly interested in how they solve business problems. How do they present their work? How did they understand the problem and the user group? Do they know what worked and what didn’t in their design? These talents can’t always be taught.

2. First phone conversation

Closer to a traditional screening interview, one of Atlassian’s two design recruiters spend about 20-30 minutes with a candidate. The recruiter explains the background of the role, the locations, and the expectations of the role. The candidate will also summarize their experience and expectations.

3. Virtual portfolio and experience review

At this stage, the hiring process starts diving deep.

The hiring manager (someone like Karen or Liam) and candidate speak for about 45 minutes to an hour through a video interview to explore the decisions and process behind a few projects in a candidate’s portfolio.

“Don’t just walk through features,” Liam explains. “Why did you make those decisions? Why is it a carousel? Can you link research insights to a design decision?” It’s not enough to design the right way; candidates have to understand and explain why it’s the right way.

4. Onsite interview

Candidates who pass the virtual portfolio review then get invited for a half day onsite at one of Atlassian’s global offices.

Atlassian’s Sydney office.

After a series of 1:1 conversations with other team members, the interactive design exercise begins. Lasting between 1½ to 2 hours, these fictitious exercises span two sessions that mirror the divergence and convergence of the design process:

First session – 2-3 Atlassian employees role-play with the candidate to gauge collaboration skills (confidence, delegation, leadership style) and idea generation abilities.
Second session – Candidates are given time alone to create a cohesive concept. The final deliverable may range from a wireframe to hi-fi mockup. When ready, the candidate will present their work to the same group from the first session.

Thanks to the alone time in the second session, the process evaluates soft and hard skills without making more introverted candidates uncomfortable. The format reflects Atlassian’s emphasis on balanced designers over unicorns.

“We’ve left the room feeling ho-hum after seeing a candidate not shine in the collaborative session, only to come back and be totally blown away by their work in the solo session” says Liam. “The format really shows all the skills of the designer and prevents us from pigeonholing people”.

Following the interactive exercise, candidates are then invited to a values interview with several employees. The goal is to assess culture fit according to Atlassian’s company values. “Culture fit isn’t about being like the Borg and trying to assimilate everyone into our way of being,” says Liam. “It’s more about sharing the same values and letting culture be fluid as a team grows.”

Questions like “What don’t you like about your current environment?” and its follow-up, “What action have you taken to change that?” shed light into who’s likely to jump ship at the first sign of danger (not team-players), versus those committed to finding solutions first.

“Culture in tech has almost become a buzzword,” says Amanda. “We demystify ‘culture fit ‘by defining our core Atlassian values and interviewing accordingly. We dig into someone’s experience, philosophy, and attitude to see how it resonates with our values.”

The values interview concludes the hiring process, although some additional interviews may be needed to iron out logistics or involve remote team members who couldn’t be onsite.

Designing the Onboarding Experience

The onboarding experience is just as carefully crafted as the hiring process.

Atlassian divides their onboarding into three parts:

Before the first day. A welcome package arrives at their home around the same time they receive an offer. The package includes cultural artifacts like a passport holder to represent the company’s global workforce. Design hires also receive an extra gift: Designing at Atlassian, a physical anthology of the design team’s Medium articles.
First week. Atlassian uses a mentor or “buddy” system to onboard new employees and guide them through onboarding activities. The mentor is usually outside of their core team, again encouraging new hires to broaden their expertise.
Regular check-ins for 90 days. Managers meet regularly with new hires to discuss the company’s mission, products, values, customers, and workflows. Check-ins let managers assess new hire progress, and gives new hires a platform for discussing goals and expectations.

Long-term Career Development: The Dual-Track Model

Over the course of their career, designers can choose from either specializing in design craft or design leadership. By offering equal compensation and stature in the company, the dual-track model allows designers to pursue careers out of genuine interest and skill. Designers are also free to move between the tracks.

Career development paths at Atlassian Design.

To promote a sense of community and improve knowledge sharing, Atlassian also gathers together their design organization every year for Design Week. During the internal conference, teams share best practices from case studies and participate in fun activities together.

Atlassian Design Week 2017

Conclusion

Well-crafted products require good designers. To attract good designers, you need a well-designed hiring process.

Design transformation isn’t as simple as hiring hundreds of designers and calling it a day. Careful processes are required to hire and develop the right design talent without disrupting the balance of other teams.

It’s no different than designing a product: consider the end-user experience, think through the consequences of each decision, and be prepared to evolve and iterate over time.

Interested in being a designer at Atlassian? To see available positions, check out Atlassian Design Careers.

Closing the Gaps Between UX and Agile: Advice from Adrian Howard

Adrian Howard is passionate about creating great teams and great products. With over 15 years of experience working with startups, established businesses, and agencies, Adrian is an active member of the Agile and Lean UX communities. He co-founded his agency Quietstars to specifically help companies integrate business processes with design and Agile methodologies.

We recently spoke with Adrian to explore how to avoid the common pitfalls of integrating UX and Agile. Here’s what he had to say.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.

Have you seen any gaps between Agile processes and user-centered design?

I don’t think Agile and UCD are misaligned in intent. We only create gaps through malpractice and misunderstanding.

People often say Agile is a very developer-focused set of practices. That’s not entirely true.

While Agile definitely originated from the developer world, the focus was very much on, “Let’s stop building crap products. Let’s start making our customer happier. Let’s start listening to our customer. Let’s have much tighter feedback loops. Let’s deliver actual value.” All those principles completely align with UX goals.

You’ll find a lot of stuff out there that’s Agile in name only. It’s the same as passing off rubbish design in Photoshop as UX work. There’s a lot of, “We’re going to jump on the latest buzzword because we hear it’s good.”

But the company does’nt understand the underlying strategy behind Agile. So you get a lot of Cargo Cult Scrum, especially in larger organizations where people run the sausage machine at the development team as fast as possible, pushing functionally sound features out all the time without enough user validation.

As far as I’m concerned, that’s not Agile at all. That’s just a superficial interpretation.

What is one of the top mistakes you’ve seen companies repeat as they practice UX in an Agile environment?

Because a consistent stream of feedback usually pours in during Agile product development, some companies might assume usability testing and user research skills aren’t required. The product team is already pushing incremental features live and hearing from customers quickly, so what more do they need?

The fallacy is that unless your team has at least basic skills in user research or usability testing, you might hear about the problems from users, but you won’t know how to steer the product out of those problems.

So how can Agile teams build up more UX competency to better act on user feedback?

Increase the whole product team’s user exposure hours. Don’t just rely on passive user feedback coming through customer support, or usability reports delivered by a researcher or designer.

In fact, if you look at the origins of Extreme Programming, the creator Kent Beck actually embedded a user into the product development for Chrysler’s Compensation System (the test bed for his XP methdology).

Of course, that kind of Stockholm Syndrome-esque approach does come with potential bias since the customer becomes part of the development team. But still, even at that level, the whole team at least was in regular contact with the end-user.

Usability reports are easily ignored by development teams. However, if a developer attends even just 1 hour of usability testing a week, the feedback hits home immediately. People will instantly believe and understand a designer’s recommendations because they’ve experienced the visceral power of seeing a poor old end-user having a horrible time with the product. You don’t need as much documentation to convey your point.

Try an incremental process of drip-feeding your exposure hours. Every other week spend a few hours with developers interviewing users and moderating usability testing. Incremental research provides more value because people apply insights by the next sprint.

Spreading out your user research is an easier sell to organizations than trying to convince them to spend $60-70,000 on a month’s worth of user interviews all at once. You spend less upfront, show results quicker, which earns more support for thorough research.

You spend much less on user research upfront, and you gain buy-in more quickly since you can show the problems you fixed. Plus, you’re constantly steering the product in the right direction as you uncover new customer needs since the time you started the project.

I have a cliche slogan which is: “Do less more often together to do more”.

Do you think component-based design helps with UX in Agile processes?

It certainly relieves many pain points.

For example, I run this workshop exercise where I show wireframes of popular sites to developers, and designers. I give everyone a few minutes to write down their observations. Developers will say “These are the elements of the application, this is the form X1 for next the page, this is the edge case, etc”. Designers will talk about vertical rhythm, typography, and overall interaction flow.

Everyone sees a different part of the elephant. Component-based design helps you reduce that misinterpretation and resulting approval bottlenecks.

When you have a shared design language that breaks down into universal UI patterns and elements, designers no longer need to create everything for signoff. The whole team now has a toolbox for exploring new ideas or refactoring the existing UI.

As a result, the product team’s conversations are much more strategic.

Instead of developers wading through minutiae when asking a designer to recreate a whole page, everyone knows how the pieces fit together. We know the forms we should use and the interactions we should support. Your sprint release quality improves since developers with little design background can implement mockups and prototypes with less risk of inconsistency.

By democratizing the design implementation, the designers are then freed up to focus on the more difficult business problems. You get to “done” faster and better.

Does the fast pace of Agile UX increase risk of experience debt?

Only if you focus purely on speed of release.

Agile is not just about delivering faster. In fact, the more crap you release, the more crap you need to wade through, and the slower you’ll become anyways.

The issue of UX debt in an Agile process all depends on your organizational values. Does the company care more about keeping the development team at 100% capacity, throwing out tons of features, or about delivering value?

Because if it’s the former, then nobody is really incentivized to dedicate time to “payback sprints” to clean up as they go.

You need to develop against a hypothesis (like Lean UX advocates) and prioritize your work according to the Kano model, otherwise you will inevitably create unmanageable UX debt.

Going back to my earlier point, you need collaborative incremental user research to keep your Agile sprints in check. When the product manager and developer sees five people in a usability testing all fail miserably to register for an account, the designer doesn’t need to fight as hard to justify an iteration sprint versus being forced to dive into the next feature.

When an experimental strategy drives the Agile UX process, you can better remove the danger of people sticking to their plans for fear of losing face.

For more advice and case studies from 10 UX practitioners, download theDefinitive Guide to Integrating UX and Agile.

Solving Agile UX: Advice from Laura Klein

Author of Lean UX for Startups and Build Better Products, Laura Klein is a product management and UX expert with over 20 years experience in tech.

She started her career when the waterfall process dominated product development. In the years since then, she’s practiced multiple forms of Agile.

We sat down with Laura to explore the best practices she’s learned along the way.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.

How do you see Agile and UX working together?

Agile was created for engineers, so it originally didn’t address UX – and honestly, that’s kind of fine. We’ve learned to adapt.

The saying is that “Lean helps you build the right thing. Agile helps you build the thing right.”

Lean Startup is about constantly making sure that you’re working on things that customers will use. Agile is about delivering those things to them quickly and efficiently. They’re both about helping you learn quickly and adapt.

I would argue that any kind of user-centered design contributes to all of that, especially learning. If you use all three of them together it’s easier to build the right thing, and it’s easier to build it the right way, and that is helpful.

But I’m not religious about it, the only thing I don’t love is building things without talking to users.

Could you help walk us through how you’ve seen that Lean/Agile/UCD hybrid process play out successfully in projects?

The Lean Startup process is very much about understanding what you want to build by testing your assumptions with customers. You’ll see that overlaps with UCD methodologies since customer development is a form of user research. We’ve been observing users in the UX community for many years already, so the two work very nicely together.

On the other hand, Agile is a way of organizing your engineering team to release features faster and deliver customer value more quickly.

I’m a big fan, not just of the Lean and Agile philosophy, but also the related discipline of Extreme Programming which includes things like test-driven development, pair programming, and continuous deployment.

Continuous deployment helps deliver the hybrid process – Lean Startup, Agile, and User-Centered Design – because we can be talking to users, observing them, studying their problems, coming up with solutions for them quickly and getting them out in front of users and then measuring the results within a very short period of time

This can be a very Lean Startup, hypothesis-driven process: “If we make this change, we predict it will have this effect. Now let’s test to see if we were right or wrong.” A great advantage, of course, is that we can complete the whole process from hypothesis to validated solution in a matter of hours or days rather than weeks or months.

The key is to always drive your process based on a clear hypothesis. You want to design a small complete thing (not an under-designed thing) as a quick experiment. You can then use Agile processes to break down that complete thing into bite-sized tasks for engineers.

If you involve engineers in the user research, you also gain a greater shared understanding of the problem, which always helps with efficiency. So we come up with our experiment, build it, ship it, measure it, and all of a sudden we’ve gathered meaningful results in a very short period of time. That’s a great cycle to follow, and how I’d combine the different processes.

Now you’ll notice that I didn’t say things like, “Well you always need two-week sprints, and you need a planning meeting, etc”. Daily standups and Scrum are not the point. Those are tactics. They’re not bad! In many cases, they’re incredibly helpful tactics. But they don’t define the process.

The strategy behind Agile is being able to focus on small chunks of work that you can quickly get in front of people to learn if you need to change direction. Continuous integration and continuous deployment help you figure out very quickly if things are broken. You don’t find out 6 months later and then cycle back into the process again.

Agile is not specific tactics. Just like Lean Startup isn’t only A/B testing or customer development and user-centered design isn’t just writing things on post-it notes or making wireframes. Those are just tools. Occasionally using a hammer doesn’t make you a carpenter.

Know the strategies behind your process and adapt the tactics and tools to your team.

How do you fit user research into an Agile process?

Companies newest to Agile struggle most with fitting user research into the process.

They worry about design teams working ahead of engineering, which is really tough at the very beginning of the Agile transition because it means that engineers are sitting around waiting for people to finish designing the stuff that they’re supposed to start building. So, people try to dramatically shorten the design process.

You end up with a collection of tiny waterfalls.

Of course, you can’t avoid that altogether. I don’t believe teams need to do everything together. Not everyone needs to do user research together or sit around and create wireframes together. Designers will need to do some work ahead of engineering so that engineers have something to work on. But they don’t need to design everything ahead of time.

Also, don’t think of user research as something that only happens at the beginning of a project. Certain types of user research do tend to happen early – the generative stuff where you’re learning a lot about your prospective customers and their needs often gets frontloaded – but we need to stay in constant contact with users throughout the project and involve everybody on the team in some of the regular research activities.

In your almost 20+ years in tech as a designer and developer, what are some of the most dangerous UX mistakes you see Agile companies make?

Setting the designer up as the user champion. We should all be user champions.

The other problem I see is creating this series of mini-waterfalls where engineers are just handed very specific things to build with no input into the design or research process, so they don’t have the context to make good decisions.

We need to work together on many product decisions. You can’t just say “I did all the work upfront, now it’s your turn”.

The situation is even worse honestly when you’re dealing with a design agency where the conversation is very much “Here are some comps, implement this,” and then all of a sudden the engineers are left with so many questions that they just answer in the simplest way possible.

It also absolutely drives me nuts when it’s set up as designers versus engineers, and every decision is, “Oh, is this going to be good for the user or good for the engineering team?” We should have a process that’s good for everybody, and that comes from collaborative teams where everybody has an understanding of the user and the ability to contribute to important decisions.

How do you run retros so that people actually “fail better”? instead of just “fail faster”?

In terms of time length, the retros usually run 15-30 minutes. Any longer and it costs a lot – not just in terms of salaries, but also morale. Designers and developers hate disrupting their flow with meetings.

To focus the discussion, I start every retro with the “Start-Stop-Keep” format. Based on our progress in the past sprint:

What should we start doing that we haven’t already?
What did we try that we should stop doing?
What worked so well that we should keep doing it?

We also review metrics of any recent features that shipped. One thing I don’t like about Agile is the misleading feeling of “Done”.

We even have a column on the Kanban board that’s called ‘Done’, right? So, “Oh, I moved it to Done, that task is done.”

That task is not done. It’s just in users’ hands. It’s not done until it’s changed the user behavior in a way that meets the business goal we set. Until then, all you’ve created is output without an outcome.

You might ask some other variations of the questions in your retro, but you must change the conversation from “What did we accomplish in terms of getting working features out the door?” to “What did we accomplish in terms of impacting the business and changing user behavior?”

In an Agile UX process, what else can we do to redefine the meaning of “Done”?

Understand that the job of anyone on a product team is not to ship a feature. Your job is not to write code, your job is to increase a business metric. We need to show that number on a big information dashboard so that everyone can see it.

If we’re telling engineers, “Hey, your job is to knock off 6 tasks a day and hit this particular velocity and close this many issues,” that’s all you will get.

We need to tell the whole team “Hey, your job is to increase this number. Nothing is done until that number’s where it needs to be (and these other numbers haven’t suffered).”

For example, “Increase user activation from 15% to 20% without decreasing retention”. Tools like Baremetrics can help product teams track and visualize these kinds of business metrics, making it easier to monitor whether you’re actually moving the needle on what matters.

When you focus on a common goal like that, it also creates a stronger sense of “the product team” versus “the development team” and “the UX team”. Companies need to reward their teams fairly based on those business goals, which is admittedly really hard to do.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile.

Agile UX for the Enterprise: Advice from a Sumo Logic Design Director

Based in the Bay Area with 250+ employees and $161 million in venture capital funding, Sumo Logic serves some of the top enterprises in the world.

The company’s analytics platform visualizes more than 100 petabytes of data per day, helping businesses harness the power of machine data to streamline operations.

In 2015, Sumo Logic hired their first UX team comprised of design leaders, interaction designers, visual designers, and UX architects. One of those designers was Daniel Castro – a 20-year design and engineering veteran in the enterprise space.

Now a Design Director, Daniel spoke with us about the tactics and processes required for Agile UX to succeed in the enterprise.

Sumo Logic’s UX readiness model.

What common mistakes have you seen companies make as they fit the user-centered design into Agile?

The first time I heard of Agile was when I was designing at Verizon. One of the Agile evangelizers who developed the manifesto presented a really detailed deck to the company.

I remember the response from the whole design team was “This whole process is never going to work.” At that time, the concept of a UX “Sprint 0” just didn’t exist. We were just expected to start designing and developing immediately.

So, as with a lot of processes, you need to pick out what applies and what doesn’t. Since the early 2000s, we’ve seen so many different flavors of Agile that sometimes it almost feels like we’ve just created micro-waterfall.

In fact, a developer here at Sumo Logic actually has a sign in his cube that said “Drink coffee, do stupid things faster and with more energy!”. Agile is the coffee for your design process – it is a fantastic tool for efficiency, but it doesn’t deter you from doing dumb things.

The biggest mistake is thinking that Agile will help you move in the right direction. You need to build in a series of checks and balances to ensure you’re building the right thing.

How do you strike that balance between user-centered design and Agile processes?

You take advantage of Agile’s collaborative nature to expose everyone to the value of user-centered design.

User-centered design is naturally iterative, but in reality you only have a few shots at revisions before you frustrate engineers. They’ll get cranky because the requirements keep changing.

To make the most of the iteration sprints you can realistically run, one of our most successful tactics is ensuring everyone understands that each design change is supported by usability research and testing.

In our design process, the first step is to validate whatever problem a product manager presents with customer interviews. Once we’ve spent time digesting the feedback in the form of customer journey maps, our design team clears out their calendar for ~2 days. We email the whole company and advise certain stakeholders to be on-call for feedback.

For those two days, we’ll hold a highly focused “Swarm” session in which we dive deep into the divergent and convergent design around the problem. The Swarm also helps us align with the product vision for the ensuing sprints and the business goals. We might also create additional generative research questions with developers and PMs, which then breaks down to a series of tasks you test with users with alternating sprints of testing and design.

That list of tasks is the contract binding developers and designers together for each sprint. You reach a solid middle ground where developers aren’t pushing back on every change, and designers aren’t lost in blue-sky thinking.

You get more buy-in for unexpected iterations because the context changes completely. Designers aren’t forcing the developer’s hand – the customer is guiding everybody along.

Sumo Logic’s Agile UX process.

How do you approach documentation in the Agile UX process?

You can’t completely throw out your documentation just because you’re Agile. You need to create smarter documentation.

Documentation doesn’t need to live in a document. You can be nimbler, like Slacking your team a screenshot of your whiteboard session. Don’t obsess over the form or format – the singular goal of documentation is to ensure that everyone agrees to the success criteria.

For example, if I need to convey more detail after a whiteboard sketching session, I’ll create a quick UXPin prototype and share with the team instead of marking up a huge product specs document.

Sumo Logic prototype created during a discovery phase for their Unified Logs Metrics product.

In the platform, I can literally just drag and drop objects from the dozens of libraries to convey the concept that our team discussed. Add some notes to the prototype and share with the team, and now everyone has naturally created documentation together that actually helps us make better decisions down the line.

Understand the collaborative spirit of documentation, not the tactics.

Does this natural form of documentation help you mold your product strategy?

Absolutely.

For Sumo Logic, the UXPin platform really shines at helping us create collaborative visualizations to help PMs and developers better understand both the horizontal requirements (overall feature set) and vertical requirements (depth of each feature).

Even if the PMs and developers aren’t physically present, we can send them a project link for their comments. They suddenly have clear visibility into how the scenarios play out for each persona, and how it all comes together to form the overall customer experience.

Collaborative prototyping helps the team understand the end-to-end solution and how it breaks down into chunks of work for sprint planning. Very early on, the team can start to understand what Release 1, 2, and 3 looks like and how they all map back to the core vision. Everyone gets a better sense of what they should and shouldn’t build.

The prototype naturally joins the product strategy and design tactics together. Even though your final product might not look anything like the prototype, you’ve created a living representation of the core success criteria. You can’t really see that with paper documentation.

How has prototyping helped you define success criteria in Agile UX?

So, after we’ve held the “Swarm” sessions and conducted user research, we’ll sketch through all the feedback. Once the sketches start to convey flow, we’ll dive into a lo-fi prototype.

The prototype flows are the heart of the design. They inform all the tasks, which of course define success for the product.

With a prototype, you can tell confidently tell a developer “Hey, we tested this design and it’s ready for you”. After the first formal build, you can compare the coded design back to the prototype and list of usability tasks.

Design swarm at Sumo Logic.

For each sprint, how do you build the components without losing sight of the overall strategy?

You need to set success criteria in each sprint on two levels.

Let’s return to the bicycle analogy.

First, you need the horizontal success criteria: the person needs to sit down, hold down the handlebars, pedal, and move from A to B.

Secondly, you need vertical success criteria: the frame design will be aluminum, the pedals are a certain size, etc.

Not only does the team need to understand both levels of success criteria, but you also need to ensure you’re testing at both levels.

You can’t test features in isolation. You need to test the entire end-to-end solution as early as possible. Otherwise, you get lost in vertical paths. You build the most amazing tires but Billy can’t ride the bike because the tires don’t fit on the frame.

Of course, prototyping helps us get that perspective at each step in the process. It’s a living contract for both sets of features. Anyone can have high-level conversations about strategy, or dive deep into individual components.

What Agile principles have you found useful to user-centered design?

Agile gives you a concrete structure for planning ahead. It brings designers back to earth and prevents them from wanting to design forever.

Agile has also democratized the design process so that even sales and customer success can contribute to the product.

We’re able to break up work, encourage open contribution, and move away from the “lone designer” mentality.

On the other side of the spectrum, how do you prevent too much design collaboration (e.g. design by committee)?

That’s always a tough issue.

It starts with the designer’s attitude towards collaboration.

First, they need to see themselves as a facilitator for gathering, shaping, and testing input.

Secondly, consider holding 1:1 sessions with vocal stakeholders. During design reviews, let them air their thoughts, but if they dive too deep into prescriptive advice, tell them you care so much about their ideas that you want to dedicate focused time to discuss.

Sometimes, you’ll find that stakeholders might even reconsider since they realize they need to separate personal opinions from facts. It seems like a paradox, but sometimes being overly open actually helps people better accept dissenting opinions.

For example, we were working with a product manager who wasn’t exposed much to the design team. We had trouble communicating our approach, and he was adamant about a certain feature. We simply responded with “We don’t think it will work, but let’s test it and see”.

Coming out of that usability test, the original idea was invalidated, but we found pieces of it that could work in a different context. So even if the testing validates the designer’s idea, you can’t tell others “I told you so”. You need to convey a spirit of “We’re willing to work with you”.

Finally, designers can try reframing the conversation by saying “Look, we’re trying to make you look amazing. We want to release a product that will make people want to write about your features.” versus “Look, my idea is right because…”

All of a sudden, something clicks and the other stakeholder realizes that the designers are on their side – and sometimes that means saving them from themselves.

Do you follow a component-based design system (e.g. Lego-block approach to design)?

We’re currently in the middle of a reboot project that will help us work even closer along those lines.

Luckily, we’ve been blessed with UI developers who sit inside the UX team. As such, designers and developers can define the major components of a pattern library together.

Once you have that common design language that breaks down to patterns and elements, everyone does less redundant work. Designers can focus on solving large business problems, and developers feel empowered to use vetted components instead of asking designers to verify everything.

We aren’t 100% there yet. But after this reboot project, we’ll be much closer. You can imagine how exciting it will be to just go into a shared environment and grab the exact component to match your context of use.

How would you improve the Agile UX process?

I’m all about expectations, whether they’re big or small.

The best process starts with collaboratively defining the requirements for success. From there, you can chunk out all the pieces into your sprints.

Within each sprint, you also set expectations for each chunk of work. What are the goals? What are the discovery questions? What are the tasks? How will we know customers love this?

You repeat the process, ensuring that everyone on the product team always knows the answers to the four questions above.

Download the 99-page Definitive Guide to Integrating UX and Agile.

12 Common Web Design Patterns

1. Cards

2. Grids

3. Magazine-Style Layout

4. Container-free Format

5. Split-Screen

6. Single-page Layouts

7. F-Pattern

8. Z-Pattern

9. Horizontal Symmetry

10. Approximate Horizontal Symmetry

11. Radial (Rotational) Symmetry

12. Asymmetry

Modern Layout Considerations

Prototype Web Layouts With UXPin

Frequently Asked Questions

What are the most common web layout patterns?

When should I use the F-pattern layout?

What is the difference between the F-pattern and Z-pattern?

How do cards improve web layout design?

What layout pattern is best for responsive design?

How can I prototype web layouts quickly?

1. Component-Based Design Systems

What is a design system?

How to Create a Design System

2. Polygonal Shapes and Geometric Layers

Simple geometry

Bold Lines to Grab Attention

Detailing

3. Tactile Design

No Borders

Multilayer Design

Purposeful Motion and Animation

Detailed Photography

Grab design ebooks created by best designers

Do you want to know more about UI Design?

4. Complex Desktop/Simple Mobile

Mobile Alternatives for Complex Interactions

5. Modern Retro Design

Old-School Typography

Extreme Colors

Texture and Gradients

Video-game Style

6. Simple Homepages

Minimalism

Flat Design Family

Subtle Animations

Beautiful Photography and Videography

Prioritize Readability

Conclusion

What exactly is a design system?

How it all connects

How to create a design system

Websites built with a design system

Learning 1: Tension between product and design systems is healthy.

Learning 2: Look at what’s in product, synthesise, and build forward.

Learnings 3 & 4

Drawing on a real-life case study, this e-book goes through the step-by-step process of transforming an enterprise through design.

Lesson 1

Lesson 2

Lessons 3-5

Team Structure

Atlassian’s Agile Design Process

1. Creating context and alignment

2. Collaborating on ideation and creation

3. Measuring the impact

4. Shipping carefully and measuring regularly

Conclusion

How it works

Tools & Systems

Tools

Systems

Team Structure

Roles/skills (T-shaped)

Ratios

Organization

Collaboration

Creating and adapting rituals

Working meetings

Culture