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 designing more device-specific variations of the same product, site, or app.

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 even utilized UXPin’s design systems platform.

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.

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.

Design Systems Virtual Summit 2018

Design systems are the hottest topic in UX today.

Everyone seems to either be creating one, or planning to create one. The benefits are undeniable: better design consistency and more efficient product development.

So what better way to usher in the golden age of design systems than with a worldwide online event full of experienced speakers and compelling case studies?

That’s how Design Systems Virtual Summit 2018 came to be. And thanks to sponsorship from Atlassian and Salesforce, it’s free for the world. Design Systems Virtual Summit 2018 features 13 webinars across Feb 13–16, 2018.

Featuring 13 free webinars from today’s top practitioners.

Speakers include folks like Dan Mall, Bethany Sonefeld, and Ken Skistimas. They come from places like Salesforce, Atlassian, Airbnb, Linkedin, Fjord, IBM, GE Digital, Fjord, Athena Health, ForumOne, and Zendesk.

You’ll learn:

How to assemble a design systems team and technology stack.
How to identify and resolve design inconsistencies.
Where design systems should be consistent or flexible and how to adapt tools and technology to balance both.
How to avoid vague design principles.
How to sustain consistency across products and interface targets (Android, iOS, VR, or even Natural Language interfaces).
How to build a design systems backlog, governance model, and ROI tracking.
How to unify design with code.
How to close knowledge gaps between designers and developers.
How to sell a design system to designers, engineers, and stakeholders.

Free e-Book: Scaling Design Thinking in the Enterprise

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

Design thinking has a proven record for improving performance, customer satisfaction, and sales… so why is it so hard to implement in enterprises?

If you want what’s best for your company but don’t know how to get your colleagues on board, this free ebook lays out everything you need to do in just 56 pages.

Rather than explaining the theory, author Julie Baher recounts her own real-life experience implementing design thinking at the million-dollar software company Citrix. Baher, currently the Senior Director of UX at Illumina, shares her 5-year journey as Group Director of CX at Citrix to show — in practical terms — how she won over an entire company to a new way of discovering and solving business problems.

In this free e-book, you’ll learn:

The 3 main steps of converting your enterprise to design thinking from the ground up
The core tenets of design thinking: what it really is, beyond all the buzzwords
How to speak to company leaders about design thinking so that they’ll actually listen
Which company activities, formal and informal, can speed up the adoption process
How to train coworkers in design thinking, and how to train other trainers
Which tactics from the Lean Startup methodology can help you
Which tools and software are invaluable during the process
The true case study of how Baher succeeded in convincing Citrix to convert

Download this free e-book 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.

UXPin + JIRA: One continuous workflow for designers and developers

Designers and developers might think and work differently, but that doesn’t mean we can’t connect their processes together

That’s why our major updates in the past few months have all focused on unifying design and development:

Spec Mode (Oct. 2016): Auto-generate specs, CSS, and style guides for any design in Sketch or UXPin. Eliminates manual redlining for handing designs off to developers.
Freeflow Documentation (Jan. 2017): Pin documentation to elements in your design so team members can see the rationale behind product decisions. No more shuffling between design and 100-page requirements documents.
Design Systems (June 2017): Create consistency in design and documentation everywhere. Design systems libraries give everyone a single language and toolkit for design patterns and code snippets. Updates to design system documentation syncs to all projects.

Now with JIRA integration, you can visually illustrate requirements and keep the team updated on your design work right in JIRA.

Thanks to our collaboration with Atlassian you can preview your prototypes in the JIRA issue and access the design documentation and specifications.

How it works

The process is pretty simple for bringing UXPin prototypes into JIRA:

1. Install the free UXPIN for JIRA app to your team’s account, or request your JIRA account owner to install it.

2. After installation, copy and paste your UXPin preview link into your JIRA issue. The UXPin prototype will appear as a thumbnail.

3. Now you can preview the prototype in the JIRA issue, and access the documentation and specifications by clicking the tabs.

UXPin prototypes you see in JIRA (and the documentation and spec links) are always updated to the latest version. It’s just another way we’re bringing designers and developers closer together.

You can download the app in the Atlassian Marketplace.

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).

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.”

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.

Smashing Conference Barcelona 2017

As guest authors for Smashing Magazine, we’re pretty excited to share some cool news about their upcoming conference in Barcelona.

Smashing Conference is an in-person extension of the practical content we read on their site. Based on their speaker lineup and topics, the multidisciplinary conference explores UX and front-end development case studies:

Design and development collaboration
Best practices for front-end development
Mobile design and development
Evangelizing UX design

An image from SmashingConf in Barcelona 2016. Image Credit: Alessio Carone

What is it about?

A big proponent of collaboration and networking, Smashing Conference aims for an intimate and comfortable experience. No fancy suits, impersonal halls, just useful content with like-minded designers and developers.

Smashing Conference 2016

They’re bringing together experienced folks to share front-end and UX techniques and the pitfalls they ran into, lessons learned, and efficient workflows.

This year’s topics in Barcelona include:

How to improve the perceived performance
Where and how to use SVGs
Accessibility For Everyone
Responsive Design
Emoji integration
Design systems

When is it?

October 17-18, 2017.

Who’s speaking?

This year’s 15 speakers include:

Brad Frost – Author of the book Atomic Design, co-host of the Style Guides Podcast, he has also helped create several tools and resources for web designers, including Pattern Lab, Styleguides.io, Style Guide Guide, and WTF Mobile Web.
Stephanie Walter – A Web Designer, Pixel & CSS lover, she focuses on designing for user experience on mobile and web applications and Responsive Webdesign. She also teaches courses on Mobile design and optimization and HTML & CSS for beginners at the University of Strasbourg.
Sarah Drasner – A web developer and designer, with a history in as a Scientific Illustrator and an Undergraduate Professor. She’s an award-winning Manager of UX Design & Engineering at Trulia and staff writer at CSS-Tricks.
Monica Dincluescu – An emojineer at Google, she works on Chrome, web components, and Polymer.
Anton and Irene – Creators of interactive experiences for many large scale clients and projects, under which the redesign of USAToday.com, Metmuseum.org, Zumtobel.us, Balenciaga.com, Wacom.com, and SportsIllustrated.com. They’re also the creators smaller projects, apps and experiments for clients like Shantell Martin, Karim Rashid, Google, Nickelodeon, Porsche and Red Bull.
Marcy Sutton – A Web Platform Award winner for her work in accessibility, she works on web accessibility tools at Deque Systems, a company focused on digital equality.
Paul Boag – User experience strategist who helps companies make use of digital to better serve connected consumers. He hosts the award-winning user experience podcast at boagworld.com and is the author of four books including Digital Adaptation and User Experience Revolution.

Where is it?

In Barcelona at the Palau de la Música Catalana, one of Barcelona’s most magnificent buildings, built from 1905 to 1908.

Palau de la Música Catalana

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”.

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.

Integrating UX and Agile: Advice from Jeff Veen

With a career spanning 25+ years, Jeff Veen’s experience has spanned design, business, and venture capital.

He’s lead design teams at WIRED, Lycos, Google, and Adobe. He’s co-founded three successful companies: Measure Map (acquired by Google), Typekit (acquired by Adobe), and Adaptive Path (acquired by Capital One). Now, he’s advising startups (like us) on design and product strategy as a Design Partner at True Ventures.

We figured he knows a thing or two (or many, many more) about how to practice design successfully in an Agile process. So we sat down with him for an hour to learn from his experience.

From hybrid processes to conducting user research and running retros at scale, here’s his most useful advice.

Want more practical advice on Agile UX? Download the new Definitive Guide to Integrating UX and Agile.

You founded Typekit, lead teams at Google and Adobe, and now work in venture capital. How do you balance UX with Agile?

I’ve seen a lot of different methodologies come and go, or come and merge.

We adapted practices from Extreme Programming, Agile, and Lean Startup (which I think is an evolution of both of those ideas). We didn’t follow “agile with a capital A”, but just treated it as another inspiration for our hybrid process.

The most steadfast “rule” was that every single person on the team is doing UX, whether they’re a back-end developer, front-end developer, or designer. A Database Engineer is just as important to delivering the end-user experience as a Visual Designer.

To make that hybrid process work, we found it helpful to merge the UX and development team. I just made one team and said, “You all have different roles towards making the best possible product, now let’s follow a design process that works for all of us.”

For example, our daily standups weren’t by the book at all. If you read the books about Agile, you’ll find lots of discussion about tacking index cards up on the wall and moving things around. I don’t really do a lot of stuff, but I love the spirit behind checking in every morning to gauge progress and morale.

Once our teams grew, we scaled the format to accommodate size (sometimes 40+ people). You don’t have to ask every single person, “What did you get done yesterday, what do you want to do today, and what’s blocking you?” Instead, you can appoint key people who have emerged as leaders in the organization to report out on these answers so the format is more “Here’s what’s happening in our company and team”.

Then, as a leader, you’re better able to see if there’s energy here or if you need to dig deeper into problems.

Was it hard getting buy-in for that more hybrid design process?

It was definitely more challenging for companies that were still following a waterfall process.

For example, you go to a place like Adobe, which is really entrenched in an org chart with separate disciplines and everybody is centralized around their discipline, and engineers with years of experience will say, “Would you just please give me a mockup, so I can go build it?”

That can be really challenging. To get buy-in for a more hybrid process, I would always try to show progress by tackling smaller projects for quick wins. That way, others could immediately experience the improved process versus what happens when a design team is battling priorities from a department that has nothing to do with the current product.

What do you like most about those different methodologies that inspired your design process?

Shifting the thinking so that every technical project must be rooted in an identifiable user needs.

The other part I liked is that Lean, Agile, and Extreme Programming are all structured around momentum. And that means going fast, doing small amounts of work, and launching as quickly as possible so you learn from the real world.

That turns a design process into a much tighter prioritized set of goals. Instead of designing a complete architecture and launching all 150 features at once after 6 months, we launch two things next week and learn how to immediately improve.

Once you’ve shifted that mindset, it’s so much easier to follow a flexible process based on the project needs. Everyone ends up feeling good about their work, they’re getting constant feedback, and they’re shipping quickly as opposed to these death marches towards giant releases.

What pain points did you face in your hybrid design process?

Flexible methodologies are always difficult to introduce to talented people who are already well established in their careers.
When I describe this hybrid collaborative process, a lot of people can believe that it sounds like a waste of time and we should spend that time coding. You need to build trust in the team to say, “Look, we’re not typing at our computers for the next week, we’re doing work that helps us understand the problems we need to solve”.

On the other side of the coin, going fast all the time with sprints can be frankly exhausting. It’s like you’re sprinting through a marathon. Leadership needs to regularly gauge the overall sense of fatigue in a team.

Sometimes we needed to go a little slower and we planned a few sprints to pay back the technical debt we accumulated from moving so fast. You need those “payback” sprints because you want the team to feel satisfied with work that reflects their reputation.

For this hybrid design process you tried at Typekit and Adobe, how did you decide who was the product owner?

We always designated one person as the product owner, but that person wasn’t a pure product manager.

I tend to look for product management skills in developers and designers or even user researchers. For the product management and product owner role, I find people are more successful if they first have a strong background in a design or technical role and they’re shifting to this role for more influence over the product.

At Adobe, a lot of product management were MBA types. It’s not a bad thing at all, but their method of working was around developing models, spreadsheets, and Powerpoint decks. Very little user research involved. They would examine problems like “What’s the total addressable market, and how do we achieve that?” Those questions are totally important, but your method of achievement must be based on user-centered design.

Therefore, in order to capture that market share, you need clearly designated product managers and product owners with a solid grasp of UX.

Jeff Veen at Adobe in 2013.

How can enterprise designers better sell the value of user research in an Agile process?

You can use some sleight of hand at the beginning of a project, and say “We need to work on all these big things. We need to develop some kind of overall architecture. We need to choose a technology platform. Oh, and we need to do a bunch of customer research to make sure none of that goes sideways.” You place user research in the same category of upfront work as technical scoping.

You also frame the research in a way that generates revenue.

When working at Google on their analytics and Adwords platform, I said: “Look, we have to talk to people paying for AdWords and find out their reporting needs so that we can help them spend more money.”

As a result, we spent our first few sprints (a couple of months) diving deep into understanding ad spending, online marketing, and publishing the efficacy of customers.

We met with hundreds of potential customers in the agency world and in-house teams at large companies. When you listen to even 20 people with the same job talk about their role, and you visit their office and you see the sticky notes on their monitor and all the other workarounds, you see a ton of trends emerge. You analyze the transcripts of all of these interviews and say, “This is a task, and this is a task they do, and this is a task.” Group the tasks together and you’ve built a solid mental model and product architecture.

All without coding anything or designing any screens.

On the other end of that spectrum, how did you fit user research into the process you practiced at Typekit?

Same approach. We did two large research sprints upfront to learn about web designers and people who design and sell type for a living, then continued to follow up throughout the process.

In the beginning, my cofounders and I would spend 30 minutes at a time interviewing a total of 40 users (Skype, coffee, etc.).

From those interviews, we learned about critical issues and had plenty of source material to adapt to the rest of our design sprints.
At Google and Typekit, I didn’t write up a research brief with a protocol and a structured plan. I just told everyone “No, I should go talk to as many people as I can to figure out if I’m going crazy or not.”

In this hybrid process, did you run post-mortems and retros on a regular basis? If so, what format did you find successful?

We ran post mortems and retros all the time.

That’s incredibly important for freeing everyone up to be creative. You don’t look for blame or credit, but simply “What did we learn from what we just did”.

For each post mortem or retro, someone on the team was tasked with investigating the situation and returning with insights. They’d share them with the rest of the team for alignment, and then we’d dive right in after the morning standup.

The “investigator” would share the vetted results with the team, then we’d start an open discussion based on the 5 Why’s of Lean Startup to dive into issues discussed. We kept the post mortems and retros short and focused to prevent them from becoming a complaint session.

And of course, during post mortems for projects that failed, leadership needs to identify the circumstances, not the attributes, of the people involved.

What would your ideal design process look like?

I’m not quite sure I have a perfect process because there’s no perfect team.

The most important thing to remember is that a team is just a collection of humans. Humans have some combination of rational thoughts and emotional responses to everything. And every process must account for that particular blend of rationality and emotions.

Here are the three key elements crucial to any design process:

A deep understanding of the people on your team.
From that comes culture, a clear mechanism for communication that everybody buys into.
That culture encourages a sense of momentum in which everybody feels like progress is happening and they’re thrilled every day to see the product get better and better.

The best process is a flexible process. Steal the best techniques from multiple methods, then adapt them to the context of your product and team.

That approach always scales over time.

What collaborative tools do you think help facilitate Agile UX?

I’m a huge proponent of any tool that facilitates collaboration and communication across teams. I’ve seen the power of this when working in highly productive teams who embrace tools like Slack or Trello or Asana.

But what I’ve been most interested in lately are processes and tools that encourage collaboration around design artifacts – the files that designers use to communicate their interface solutions or interaction flows.

As an investor, that’s where I think Definitive Guide to Integrating UX and Agile.

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

Across the organization

Across your own team

Conclusion

The Right Team Size and Structure

Generalists vs. Specialists: Enter the Design Skills Matrix

The Carefully Crafted Hiring Process

1. Initial evaluation

2. First phone conversation

3. Virtual portfolio and experience review

4. Onsite interview

Designing the Onboarding Experience

Long-term Career Development: The Dual-Track Model

Conclusion

What is it about?

When is it?

Who’s speaking?

Where is it?

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

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

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

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

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