Ben Gremillion, Author at Studio by UXPin

Design Systems Are What’s Next. Is Your Team On Board?

You’ve read the reasons. You’ve dabbled in the concept. Now you’re ready to introduce design systems to your team. The trouble is getting everyone ready to evolve.

Convincing your team to upgrade their thinking harkens back to the early days of responsive web design. When Photoshop comps were the order of the day, going responsive disrupted established workflows. Change is rarely easy, especially in production environments. But gradually, as mobile users became more prevalent, design teams saw the need to think about different viewports and browsing experiences.

Adopting a design-system mindset is no different. It takes effort and causes friction. But the benefits outweigh the initial pain with smarter workflows that benefit everyone, including the end users. Teams that evolve faster will reap the benefits sooner.

Starting the conversation

Where do you even start? Try the opening line, “How would you like to save time and money?” This simple question distills design systems to their essence: solutions to the dual problems of deadlines and budgets. Which they are. It just takes a shift in one’s mindset to see why.

For one thing, design systems are more than pattern libraries. They’re visions. More than just useful assets and code snippets, systems are also the reasons why their designs work — the spirit and the language that harmonizes a team’s (or teams’) efforts. They’re frameworks of thinking that let you create patterns as needs arise.

They’re also living, adaptable products. If you learn that something isn’t working, then user test the heck out of possible solutions, and replace the errant pattern with something better. Once deployed, the whole team benefits from that single set of user tests.

Vision: goals you want to accomplish
Assets: downloadable files ready to tailor for contextual needs
Code: text ready to copy into development environments
Documentation: best/intended use, parameters, case studies or examples, version or date

But philosophy will only get you so far. Often it’s real-world talk that wins the day.

Make a practical case for design systems

Thinking in systems means looking beyond the immediate project. That’s because design systems are long-term investments that will expedite future design decisions with reusable assets. That’s a fancy way to say “they’re pretty dang useful.” And there are other ways to say it.

Design systems are value-adds. Both on and offline, they prevent confusion among users or customers about what the brand stands for — and even prevents the question, “is the organization changing on me?”

Design systems are memories. If you’ve ever revisited a project after six months or more and wondered, “what was I thinking?” then a design system is your friend. When documented, it will explain the ideas behind the design and code, not just reference their veneer.

Design systems put users first. By designing around content — you know, the stuff that people visit a site or use an app for — teams all but guarantees that users return for more.

Design systems are safety nets. Once developed and vetted, design systems give teams proven UI, UX, and code patterns that work across all relevant browsers and accessibility needs.

Design systems are detail checks. A well-structured system gives designers an overview of the whole project, sans-context, to help them make sure everything speaks the same language. Comparing details at a glance will reveal inconsistencies. For example, do buttons of various colors fit the forms in which they’re placed? Does the typography use a pleasing scale? Heck, are round corners used consistently?

And there are other, more surprising benefits.

Design systems are “instant-expert” guides. Their documentation helps bring new teammates up to speed quickly without having to dig through an entire project, one screen at a time.

Design systems start the right conversations. Working with stakeholders on design systems moves meetings towards visuals that lead people to the project’s goals. That’s because designing individual components helps designers get faster feedback than asking people to review entire pages. Smaller chunks are easier for stakeholders to digest, analyze, and comment on.

Speak in the right language

So how do we communicate all that to a team? We don’t. Instead we talk in ways that people in different roles will understand.

Hey designers: A well-structured system is an asset library.

Hey developers: Design systems are “object-oriented”-like approach. They’re more logical and easier to manage than “procedural” pages and views.

Hey creative directors: Want to keep everyone on-brand throughout the entire project lifecycle, even after launch? Design systems are the definitive brand and style guidebook for your team, including future members, to follow.

Hey C-level execs: Design systems invest resources into long-term returns by providing accurate, proven assets to the designers and developers when they need them most — for example, when striving to hit those milestones.

The tangible side of a design system

At heart, most designers and developers are makers. Tinkers. People who get their hands into anti-aliasing and if/else statements. So when persuading people to adopt design systems, actually getting started is a great way to … get started. Get the team together with pens and paper, and start hashing out the means and visuals of this partial inventory:

Building blocks

Typographic scales
Color schemes
Grid column widths, gutters, margins (including responsive web design)
Icons
Image assets

UI patterns

Templates
Modules
Components
Elements

That’s great for a style guide. Systems go further.

Vision

Design principles
Implementation guidelines
Do’s and Don’ts
Editorial guidelines

Management

Ownership & responsibilities
Version control
Permissions

Going forward

Design systems are not side projects. They are the products on which other products are built. They are active products that need curation, budget, and deadlines. Design systems have versions and a product roadmap. So pitching them as a project unto themselves is critical to helping design teams understand their value.

Adopting a design-system mentality takes effort and causes friction. But the benefits outweigh the initial pain with smarter workflows that benefit everyone, including the end users. Teams that evolve faster will reap the benefits sooner.

Naturally, everyone has their own design style. And that’s fine. But when everyone draws from the same source of truth, individual styles from becoming muddled user experiences.

Deal With It: Break Established Design System Rules and Integrate the Results

Some rules exist to support the rule-breakers.

Design systems are products that enforce consistency while expediting development. They manage all that with proven design patterns and tested code snippets. But the default parameters don’t always cover every case. When the built-ins fail, it’s time to step out — intelligently.

When elements get lost, design comes to the rescue

Websites that are designed to convert casual browsers into paying customers face the challenge of telling people how to do so. The more a page needs to sell its product or service, the more information it requires. This can bury the call to action, no matter how much it shouts.

This leads to problems like, “Our user testing revealed that people want this signup form, but don’t know where to look. We think it’s obvious, but apparently not.”

Natural variations are part of the design system

Design systems are places to start, but variations naturally arise as you apply them to real-world projects. Buttons become “submit” or “search” or “cancel.” Icons change color based on context. Each level-1 heading contains its own text. Almost every time designers apply a pattern, they’re applying a starting point. Patterns are templates upon which designers create their products, not the final results.

So patterns should be flexible enough to allow for changes while including parameters about their max/min size and how much “stuff” they can hold. They also need to describe other changes that are allowed — and under what circumstances. In the signup form example, the design system allows for a larger-than-normal header. It’s a variation on the “Input Form” pattern that requires more attention than average.

So a designer breaks from convention to make the form stand out, right? Wrong. They should change the pattern to allow for an eye-grabbing variation, and apply that to their project.

It’s a truism that design elements are rarely used once. Being able to reference a pattern — including its exceptions — saves effort next time someone on the design team needs to make a form stand out. Design systems exist to keep a visual language understandable. The goal is to invent a pattern that breaks certain rules while adhering to the spirit of the system.

What might change?

Down to brass tacks. Or steel ones, or blue ones, or red ones — what variations should a pattern allow? The answer varies (ahem), but a few rules of thumb will help you make more robust design patterns.

Contrast: Higher contrast implies importance, while lower contrast demands less attention. Like <H#> elements in HTML, a few levels of priority will help most visuals find their place in a page or view’s hierarchy.

Dimensions: Small, medium, and large versions of a pattern provide the flexibility to work in a variety of layout configurations. If a given page or view doesn’t have room for the “default” size, then the try the pre-built smaller version.

Text weight: Like contrast, thicker letterforms imply dominance. But should a pattern allow different weights like bold or light when it also allows for higher contrast via color? Consider how many options are too many for the same job.

Single vs. multiple colors: Several colors in the same element can add a “wow” factor that one color can’t do alone. In gradients or in flats, use multiple hues (or values of the same hue) to make an element seem more sophisticated than its monotone brethren.

Layout grid: A standard horizontal grid, like those found in Bootstrap and Foundation, forces elements to match each other’s widths. In doing so, they create natural consistency of which you can take advantage. For example, leave the outermost columns empty until you need a break-out element. You can also twist an element to jump outside its gutters, defying the rigid layout rules.

How stand-outs fit a design system

Let’s say our hypothetical Call to Action pattern gives designers a choice between two widths. The design system also has several types of buttons. All of them obey the harmonious color scheme. That’s the problem.

To fix it, first we experiment with colors not in the scheme. Which ones complement the existing hues and values well?

Next we run it past our team members. If you’re lucky enough to have someone responsible for the design system, submitting your new button color for review is straightforward. If not, seek input from your peers both to borrow from their tastes — and to build a sense of ownership. Collaboration is important for a design system to succeed.

If the button color wins approval, then make it an official part of the design system. Then don’t forget to note the reason it exists — to grab attention when you need users to act on a busy page — and the date or version so you can test its value later.

If you can, A/B test the form to discover whether or not the color helps. You may need to adjust the hue or value for greater impact, in which case your design system should change as well. Throw out the old color, or mark the new one as a new version.

No matter how you slice it, this process keeps a new variation of an existing pattern in the system without stepping too far out of bounds. In fact, it changes the bounds to accommodate for better design based on proven needs: “our form is not converting.”

How stand-outs stand out

Common sense says that the less something seems to fit, the more attention it gets. But there’s another key factor: the more consistent the rest of your DS is, the more blatant attention-grabbers will be, even if they don’t use tricks like eye-bleeding colors or annoying animations.

The example site used mostly warm colors, so making the call-to-action form’s button helps it to stand apart.

But look at the big picture. From top to bottom, the page bathes its veneer in Earth tones. The more it does so, as opposed to a medley of hues, the more that bold green will stand out.

Write rules to break, then integrate

Consistency is great, in part because people don’t have to re-learn what things mean in a digital product. But sometimes you have to stand out. That means either breaking a pattern or, better yet, having a pattern that stands out for the purpose of grabbing attention.

How to Use Minimal Design to Create Practical Design Systems

Design systems can help teams start great products. But designers sometimes forget that the system itself is a product worthy of attention. Like any project that involves UX, design systems must solve people’s pain points, like being able to find the right pattern under deadline pressure.

Design systems are the building blocks of digital products’ interfaces and behaviors. Making a system usable will encourage people to use it often — and help them design in appropriate ways.

Know your audience, know your goals

As with any design project, knowing your audience and how they use the design system — actually use it, not how you’d like them to use it — is critical to success. Yes, design systems benefit from user testing too. We’d hope that users would use a web app or site the way we plan, but that’s not always the case. User testing reveals how people defy our unconscious assumptions. Likewise, design systems need to bear in mind how people will use it.

Two things to consider:

What do people need when they’re stressed? Designers working under deadline pressure or debugging a live project need to get a component or pattern in a hurry. The best design systems give harried people what they need, and nothing else. If you design for people on rush jobs, then people under less stress will benefit all the more.
Are they new to the project — or even the company? While new team members don’t need hand-holding, exactly, they do benefit from copy that spells out a pattern’s purpose in a sentence or two. Three, tops.

Organized into four broad topics, everything about LinkedIn’s publicly-available brand guidelines helps newcomers understand their do’s and don’ts. Members of the press, for example, need more than the downloadable assets. They need instructions about the assets’ use.

Making a design system well-designed

From typography to layout to color, DS designs follow the same rules as any product design. And because many design systems for digital products live online, we can narrow it down to the rules of website design.

Uncluttered: Visual design systems work best without added decoration that detracts from the components they present.
Consistent: Don’t make people guess what various icons mean in different contexts.
Accessible: Good design systems work well across a variety of browsers, screen sizes, and interfaces.

Design systems also have their own unique traits.

Hassle-free to edit: The right people shouldn’t have a hard time making appropriate updates as needs arise.
Versioned: Is this component off-brand, or out-of-date? Dating or numbering patterns will help you keep things current.
Available: Your stakeholders, if not the general public, need an easy way to reference the design system online or in print.

The general idea is to let a design system’s examples speak for themselves against a blank or single-color background. You’re designing the content, not the chrome, of a living document. While Asana is well-known for its colorful look, its style guide fills space with usable information organized with whitespace and minimal typography.

What information should go into a design system’s design?

Live, visual examples are musts in design systems, especially if they’re online. Bonus points if interactions really interact with user input instead of plain screenshots, although those are valid as well.

For example, PatternLab’s demo includes a feature that lets design teams test components’ responsiveness against various screen sizes with discrete buttons at the top of the screen.

Another requirement is the code behind each component. Whenever possible, include HTML, CSS, JS, Swift, C++, Java, or whatever code is appropriate. The ability to copy/paste a component’s code into a project makes it handy; the ability to copy code with push-button simplicity saves time and helps ensure accuracy. Our own Spec Mode feature lets design teams copy relevant snippets by selecting the element they want, then clicking a handy “copy” button adjacent to its code.

Use cases are less obvious but surprisingly, well, useful. A good use case — “best used under these circumstances …” — not only describes the component’s intent, but also under what circumstances the code, if any, was written to work.

Salesforce’s Lightning design system does all of this — plus a little extra, by color-coding its code snippets, describing accessibility features, and warning people about compatibility issues.

How many notes are too many? As you might expect, the answer depends on the complexity of what’s getting described. In general, more sophisticated components require more notes about their use cases and caveats. A typical Lightning component like the “menus” section includes how its code functions, including a table about variations in the HTML, their purpose, and what to expect.

Organizing a design system

Like any reference, a well-designed design system is only as useful as its structure. In general, a system should be browsable, searchable, scannable, and sensible.

What makes a design system “sensible?” Ideas about common sense vary, but most systems we’ve seen organize their content into topics like “forms” and “headers.” Once again, user testing comes to the rescue: watching people strive (or struggle) to find what they need will inform how you should organize a design system.

ZURB’s PatternTap accomplishes this with a taxonomy of tags that cover everything from type to mood to size to color. And since it’s not specific to any project, PatternTap’s comprehensive search feature reaches into related “library” items as well.

Going forward

Remember that design systems are living products that need as much design polish as the projects they support. Their UX is just as important as the projects they support, especially when the team using it is under pressure to get the job done. Making a system usable will encourage people to use it often — and keep using it appropriately.

Tweak Your Buttons for a Design System With Some Leeway

Not every button has to look the same, especially in hi-fi prototypes where the nuance between “save” and “submit” is fuzzy at best. That’s when you should customize buttons to fit your meaning.

Buttons’ styles also need to reflect their surroundings to stay on-brand. If your user interface has a slight gloss or texture, then your buttons should too. How they’re allowed to change is part of a design system.

Try UXPin for free

Designing a system

The trick is to figure out what should remain the same, and what’s allowed to change. Text is obvious — the same style button can say either “submit” and “create.” But what about color? If one button is green and another red, what makes still them feel like part of the same design?

Only you can decide how the design system should work. But you might consider using some of these to establish a general button-y look.

Border radius: Make buttons look like more than content boxes with a slight curve — or a major curve that turns them into round-edged pills.
Colors & gradients: Boxy or not, you can make buttons stand out from other elements by giving them a contrasting hue and value.
Shadows: “Make it pop” might make designers cringe, but having an element seem to rise off the screen isn’t a bad idea when you want it to get attention.
Text size: Boost buttons’ characters to make them more prominent than their surroundings.

Check out the live demo to see examples.

If some of the above make buttons look like buttons, then what’s left to design?

Color: Once you’ve established a default button color in your design system, also decide what other hues and values buttons can assume based on context or function.
Size: Big buttons mean business. Small buttons, not so much. Allow yourself some variation in buttons’ maximum and minimum dimensions to make some look more important than others.
Font weight: An often-overlooked button attribute is how thick its characters are. Like size, you can use bold or light typefaces to indicate importance or get more attention.

If you’re making buttons in UXPin, you’ll find all of these properties in the right-hand panel of the UXPin editor. But UXPin or not, establishing conventions of “should” and “shouldn’t” will help buttons in your design systems look like siblings — or at least close cousins. Guidelines were made to be flexed.

Simulating Data-sorting in Prototypes Adds Interaction Where It’s Needed

Many design systems include simulations of their interactive widgets, although they stop short of providing real content. That’s not their job. Their job is to play what-if.

For example, while many prototyping tools won’t sort data on your behalf, you can create a “sortable” table, if you don’t mind rearranging a few elements.

Sortable tables rearrange content when people click on their headings. They’re not impossible to simulate — far from it. Here are five steps to building sortable tables.

1. Create random content in rows and columns

In a prototyping or design app, make each table column its own text element. Although in some cases you’ll need a ton of content, for brevity here we’ll only create six rows with three columns. Give them sensible names like “ID”, “name”, and “status”.

2. Make column headings

Give each column a title, analogous to a <th> element in HTML. As before, make each heading its own text element. Adding a dividing rule line is optional — use your best visual judgement as defined by your design system’s typography guidelines.

The more specific your design system is, the more specifically you can name the columns. For example, if a system spells out how special components should behave, like lists of users or a category management system, then your system should include those headings. However, if “sortable table” could apply to anything, then generic headings are best. Don’t forget to spell out what’s allowed in the component’s notes.

3. Give the element states per column

Select all of the table data, and make a multistate element. Create one state per column, named to reflect their heading. In this case:

“Sort by ID”
“Sort by name”
“Sort by status”

I also recommend you name the multistate element something like “sortable table” so you can easily find it when assigning interactions in step five.

4. Rearrange the content per state

Alphabetize or sort by number the content in each state, according to its column.

5. Make the headings clickable

Use interactions: “set state” to each state to which the column heading refers. (You did name the states in step three, didn’t you?)

Designing data

More than mere visuals style guides, good design systems include simulations of their interactive widgets to play what-if: what if someone clicks this? How should the system react? The simulated solution that suggests answers is just a few states away.

Demo

Check out this live sample to see it in action, then grab a free trial to try it yourself.

How to Write Killer Copy That Improves Your Design Systems

Documentation. Most people see it as a chore, like cleaning out email spam: an unnecessary irritation that detracts from “real” work. But writing notes in design systems is as important as the visuals themselves. And it’s not hard.

Think of documentation as writing commit notes in git. You know it’s important, but you can read the code to see what’s changed, right? That’s not always the case — and neither is glancing at visual patterns in a design system to tell what’s what. In this article we’ll cover ways to turn mundane documentation into useful notes that help your design systems in the long run.

The “so what?” factor

Redundant or similar patterns lead to inconsistencies and confusion, resulting in a slightly sloppy end product. If you’re concerned with pixel-perfect or responsive web designs, then you need more than precise Photoshop or Sketch files. You need to understand each pattern’s intention, its reason to exist. Every pattern in a design system should have a unique role.

Documentation reflects this. If you can’t write down why a pattern is in your design system, then do you need it at all? One way to find out is to list instances where your team has used it. A zebra-striped table, for example, might appear several times in a web app. Could another pattern have replaced it? Probably not since only tables display tabular data. Therefore the purpose of a table pattern’s alternate striping is to help people discern rows (or columns) at a glance.

Notice that “a table supports tabular data” isn’t a good purpose. That function is obvious. The table’s design solves a readability problem, as documenting its unique look explains.

What to write

Writing notes is more than jotting a pattern’s name and visual description. Three bits of information will make documentation as useful as the pattern itself.

What makes the thing you’re documenting unique? Each pattern needs its own purpose. For example, “Use this button to more attention than ‘cancel’” or “Use this panel when you need to make something look draggable.”

What are its parameters? How much content — text, images, media dimensions, etc — will help others decide if this pattern is right for them. Describe the most and least material it can contain, and how far it’s designed to stretch. If a calendar widget can only stretch across three columns before looking silly, for example, then you need to write that in its docs.

When was it made? Dating or versioning your patterns will help your team (and your future self) decide if the pattern is due for an upgrade, and which was built solidly enough to stand the test of time.

A documentation template

Still stuck for what to write? Try filling in these blanks: “I designed the (name) pattern to (goal). Use this pattern when (purpose). Intended parameters: (specs).” Some examples:

“I designed the Primary Button pattern to make calls to action stand out from other buttons. Use this pattern when you want to encourage reluctant people to click. Intended parameters: One column wide, 30–40px tall.”
“I designed the Intro Paragraph pattern to show readers where to start reading. Use this pattern when the top of your blog design looks cluttered. Intended parameters: three to five columns wide, 40–60 words long.”
“I designed the Feedback Notice pattern to tell users the results of their actions. Use this pattern when you need to inform them that hitting ‘save’ worked, or when an error occurred. Intended parameters: 10–12 columns wide, 60px tall. Use brand ‘blood orange’ for warnings, brand ‘forest green’ for success.”
“I defined the ‘Forest Green’ color as a way to stand apart from brand ‘sky blue’ for people with vision problems. Use this pattern when you need a cool color that contrasts well with the background. Intended parameters: #33691E.”

Tips

Write well. Compose two to three complete sentences per item, tops. Words are useless without context, so don’t settle for vague phrases. Thorough design doesn’t stop at the pixels. Content counts.

Consider SEO. The easier finding patterns is, the more likely people are to stick with a design system. To that end, remember that search engine optimization isn’t just for Google. It’s for any search tool — including the one in your design system, if it has one. And if it doesn’t, SEO means how well headings are to manually scan. Keywords are the key.

Review with teammates. Ask someone else’s opinion: does this make sense? What is it lacking? Like any user testing, getting an outside opinion will reveal dangerous assumptions in your thinking.

Stick to the topic. You don’t have to write a pattern’s life story to give people the gist. Most people referring to a design system just need one thing, and they may be in a hurry. Don’t wander onto tangents. Most kittens are fuzzy.

Building a stronger design system

Documentation may sound like a chore, but it’s a vital part of creating a design system. Spelling out each pattern’s purpose and best-use case will help your whole team understand not only the value of that pattern, but the value of your design system overall. Refer to these notes as you write yours.

Don’t Settle for Default Radio Buttons — Make ’em Your Own

Not all assets are created equally.

Every design system has its own style, whether it’s based on an existing framework or completely home-brewed. For example, some systems for websites and apps rely on plain HTML elements and let the browser display whatever they’re programmed to display. But they don’t have to.

Take radio buttons. Radio buttons let people select one option from a series. They’re long-standing HTML elements that every major browser renders with ease. But certain looks, like Google Material Design Lite, don’t follow browsers’ built-in radio button styles.

If you want to stylize your forms, here’s how to make your own radio buttons.

1. Find radio elements

Aside from the traditional ones, many graphic radio buttons exist. Look no further than Google’s own set — of which you can find as simulated, colorable vectors in UXPin. Create one in your tool of choice and copy it for each option you want to give users.

Color them to suit your needs (although for demo purposes we’ll stick with black). Then repeat the process with three “on” buttons, placing them on top of the “off” buttons.

2. Create states

Each radio button has two settings: on and off.

In UXPin, select all pairs of radio buttons and give them two more states, turning them into a multistate element (MSE).

This turns the six radio buttons into one “element” with three views, one for each active button. But you need to edit each state to reflect that. To do so, go through each state and hide the appropriate radio buttons using the left-land layers menu.

3. Add interactive hotspots

Hotspots are invisible layers that act as triggers for interactions. Since the entire set of radio buttons is effectively one design “element,” put a hotspot over each radio button and its label. Then add an interaction to each: on click, set state of “Multistate 1” to state 1, 2, or 3, depending on to which hotspot you’re adding the interaction.

The result: a set of radio buttons that fit into your customized design system better than plain ol’ HTML-based elements.

Every design system has its own style, whether it’s based on an existing framework or your own design. Some systems for websites and apps rely on plain HTML elements and let the browser display whatever they’re programmed to display. Others, like the custom set you’ve seen here, enhance your design system with its own aesthetic.

Beware Sloppy Shortcuts — Use Design Systems to Keep Code on Track

People like shortcuts. It’s not that they’re lazy; developers and designers alike like to save time, and who can blame them? Beating deadline is an important part of design as a business. But shortcuts carry risk.

Here’s one problem: copying code snippets is easy. Copying the right snippets takes precious time. And even if a design team’s internal slang helps them remember what things are — billboards, carousels, and rafters, for example — there’s no definitive code behind them. So the thought process wanders: “What was that thing called again? Never mind, I’ll just copy from the web page.”

Don’t do it!

Would designers revamp graphics from JPGs or PSDs? Would front-end designers edit CSS generated from Sass? Of course not. They’d go to the source. So why copy/paste code from old web pages into new ones? That approach is fraught with peril.

You might copy to much or too little code.
Or get unrealistic expectations of what content goes into it.
To avoid the above, you need to spend precious time analyzing source code to find the correct bits.
It’s impossible to say how an instance of code has changed. Copying from an instance might get someone else’s hack.
Depending on a team’s code standards, someone has likely vetted a design system’s code against major browsers.

A systematic approach

Imagine making a list of components in a project. From sidebars to buttons to scrollers to list items, there’s no shortage of things to inventory. Picture this list as a sketch of each component. Then imagine giving each one a button that copies its code to your clipboard.

Click. Copy. Paste. Move on.

Such a solution is part of a coded design system. It’s about getting code from the source. A visual source that’s easy to browse.

Ideally developers could look up a component, module, or other widget by its look as well as its name. Upon selecting that element, they’d see its code which they could copy/paste into their favorite code editor.

The advantages are huge:

Working from the same codebase, everyone on a team can work with everyone else’s code.
There’s no need to reinvent and test blocks of code, saving time in development and maintenance.
Front-end developers can test code snippets beforehand, ensuring that it will work with their target browsers.
There’s a smaller chance for typos.

What are the downsides? As the saying goes, old habits die hard. Some people have trouble remembering to use the design system’s code snippets, or figure eh, I’ll just cheat a little. After all, it’s just one button.

One button with a potential bug. One button that doesn’t fit the spec. One button that, when it needs editing, someone must take time to figure out. These little problems add up.

Bringing the team onboard

How do you fight old habits? With new ones.

A habit is what we tend to do without conscious thought. And they’re usually small: checking email over morning coffee; paying rent on the first of the month; muscle memory for your favorite keyboard shortcuts. To change a team’s habits, you must make changes one step at a time. Specifically, adding new habits to replace old ones rather than trying to “break” them.

In the case of visual code libraries, changing the copy/paste habit begins with a few simple steps.

Include everyone in developing the pattern library and its code.
Start today. Don’t put off changing your or your team’s current habits or else they’ll continue to dominate your workflow.
Practice building web pages or app views with the design system’s pattern library.
Enjoy the “work” so your mind accepts change more readily.

What’s in a snippet?

You may chose to document more than a visual reference and the code itself. Five bits of metadata you might include with your code snippets are:

A sensible name. “Top widget” could refer to anything. “Navigation bar” is more descriptive.
Version number or date. When was it last updated? Is there a newer edition that your team should use, even though older versions are still in use?
Min/max. How much content can it handle? What are its widest, narrowest, shortest, and longest dimensions?
Safe browser versions. Since web browsers change frequently, knowing which snippet works in what circumstances is critical as users’ capabilities evolve.

While these metadata are optional, you may find them handy for long-term success.

Going forward

It’s not that shortcuts are a problem. Far from it. Recognizing a technique vs. a cheat, however, is the key to getting consistent, accurate code for your digital projects.

Hide the Right Functions With Custom Drop-down Lists

Let’s face it: users don’t need every function in your app at all times. Hiding the right tools at the right time keeps visual distractions at a minimum, helping users focus on the task at hand.

A good design system not only includes reusable widgets, but instructions on their use cases. For example, a system may present a drop-down list’s appearance, and even offer an example of its interactions. But which items should get tucked out of view? When designing a component — especially interactive ones — best practice is to, well, describe best practice.

Build your own drop-down list

Here’s a handy trick to building custom drop-down lists: group ’em twice.

Most apps treat each element as its own layer — including groups — which you can show or hide in the left-hand layers menu.

Typically we make the “trigger” element — an icon or bit of text that people see first — show the menu on hover. Multistate elements are a great example of this. But the drop-down menu may disappear as soon as the user’s mouse leaves the trigger icon, making the menu impossible to use.

Instead, group the drop-down menu — and then group that within another group along with the trigger element (in this case a green, pill-shaped button).

Next, make the outer group hoverable. Then hide the inner group. The outer group will expand as the menu appears, making it reachable as your mouse covers its options — and it’ll disappear as soon as your mouse leaves.

Once you’ve got it built, add the component to your custom library to share with your team as part of a design system.

How it works

“Hoverable” means that as the mouse enters the trigger element, an effect will take place. When it leaves the trigger element, then the element reverts to its default state. For example, a button may darken on mouse in, then return to its original light color when the mouse exits it.

Here, the outer group is hoverable. It expands as the drop-down menu appears, also expanding the entire mouse-out-able area. And as you might expect, any links within the drop-down menu (the inner group) remain clickable.

How to Find Your Team’s Design Assets in a Hurry (Hint: it’s More Than a Name Game)

Everyone has their own design and development style. One person’s .class-name is another person’s .className in CSS, not to mention HTML formatting and how people organize their Photoshop layers — if at all.

Teamwork hinges on people’s ability to get along, yet disparate file-organizing and naming strategies can make things hard to deal with. If Bob goes on vacation, how is Alice supposed to carry on his prototype work on the important $50k Big Ranch website redesign?

That’s where design systems come in. Design systems do more than provide visual and interactive style guides to which teams should adhere. They also make their contents easy to find. After all, UX doesn’t just apply to non-designers.

Organizing a design system’s pattern library

Pattern libraries contain templates upon which to build instances of design. For example, a list of the ranch’s amenities is a list plus real content. The list itself — its bullet point style, its line-height, its maximum, and minimum widths — are parameters upon which one-off lists are made. Does the client need a list of their ranch houses for rent? It’s the list template to the rescue.

The trick to pattern libraries is — well, it’s not a trick. It’s common sense with a dab of discipline. No matter what you put into a pattern library, each component, widget, and element will need a few common bits of information that makes it easy to locate in a hurry.

Element overview

Name things how they’re used. Avoid specific names that describe context like “horse signup template”. That describes what it contained when it was built — and obviously, it’s a template. Instead, think about how it should get used, now and in the future: “signup form” or even “basic form” are more useful and more applicable to future needs.

Write a (brief) description and use case. Consider the following:

“This form has a photo, three to five radio buttons, an email field, and a submit button.”

Anyone could tell that by looking at the form. Try instead:

“Use this form when asking users for personal information and you want to reassure them that they’re not going to get spammed.”

Include a version number or date. Patterns change. Most digital assets do. That’s why versioning — anything from 1.x to 2017-01-01 — will help you weed out old patterns and track your library’s evolution. Bonus points if you use a versioning system like Git to track “what if?” experiments in branches and copies.

Pattern use cases

Cite live examples. Whenever possible, reference examples of how the pattern’s used in the wild, rather than with generic placeholder content.

“Best used for ….” What is a pattern good for? Answering this is tricky because, at least the first time, patterns are often created to answer one-off needs. The best bet is to try different contexts. For example, on how many different pages could a specific header get reused? What would have to change to make it work? Think generic. “Best used for third-level inside pages” is more useful than “best used for pages that feature barbed wire.”

Include sample variations. Plain-box templates are useful for low-level views of a template or element. But seeing it in action — several times — will help your team understand its versatility (or lack thereof).

Taxonomy

Categories: Organizing your assets into groups is an obvious approach to organizing at all. But what should the groups be? Some suggestions for categorization:

Based on psychology, like those found at UI Patterns.
Based on prominence, or how important a pattern is to the project.
Based on type, as in “teasers,” “primary content,” “lists,” or “panels.”
Based on application, like “layout,” “navigation,” or “social.”
Based on frequency of use: “major,” “minor,” or “supplemental.”

Tags: In general, categories divide different types of information, while tags create cross-references among them.

Primary color, if a pattern requires a certain hue or value.
Version number — there’s that concept again.
Style, such as “bright,” “textured,” “elegant,” “illustrated,” or “flexible layout.”
Resources: don’t think of patterns as strictly visual. Remember inclusive tags like “has HTML,” “has CSS,” “has PSD,” and “has content.”

Meta data: Information about the pattern is just as important as the pattern itself.

Informal title: How do you refer to the pattern?
SEO title: If we’re talking about an entire page layout, what guidelines do we follow to make it search-engine friendly?
Last modified date: When was the last time someone tweaked the pattern?
Next check date: When is the next time the pattern is up for review?
Author: Who is responsible for the pattern’s upkeep?
Medium: Is it a layout component? A video template? A single graphic?
Size: How wide and tall is it? Does it adhere to a particular layout grid? If it’s video or audio, how long does it last?

Notice that the tags listed above are adjectives, while categories lean towards nouns. Metadata, meanwhile, answers questions. Use these as cues to forming your own taxonomy.

Pattern libraries work with a team’s workflows

Whether Bob’s file is called brown-cow-teaser-5.psd or Photo-2017-01-01.psd, a curated design system helps Alice find it by type, description, use case, or maybe even dimensions. The goal is find-ability, not just search-ability. Your team should be able to round up assets its pattern library by browsing as searching.

Do Your Future Self a Favor: Don’t Bust the Grid

Layout grids help designers define and structure elements in a composition. Sticking to them is critical to success in any design system because elements and blocks should stay modular. You never know in what context the future “you” will want to use something.

Context is key. Should a hero element go on the left or on the right? Should it fill four width-units or six? Knowing its size determines how you can arrange everything, LEGO-like, in a composition — and more importantly, what can go adjancent to what.

Prototyping a design system grid

From prototyping apps to CSS frameworks, some design tools let you establish a standard grid to keep your components’ dimensions interchangeable. For example, UXPin has a customizable horizontal layout grid that’s analogous to those found in Bootstrap and Foundation. Here’s how it works.

Editing the grid

With no elements selected, UXPin gives you canvas options on the right side of the Editor. Click “Edit Grid” to do what it sounds like. Options include:

Number of columns
Gutter width
Side margins’ widths

You can also type option-G (Mac) or alt-G (Windows) to toggle the horizontal grid on and off. When the grid is on, elements will snap to the visible columns. Turning the grid off disables this snapping feature — although elements will still align to the canvas and each other.

What about the canvas?

A design system’s canvas is just as important as its layout grid. To change the canvas’s width and height in UXPin, look for “Size” above the grid button. You can choose from a preset size or enter your own pixel dimensions.

Using grids in your work

Grids are a fundamental part of your style guide or design system. They inform components’ dimensions (or, if the grid is flexible, their limits) which makes them modular. That is, you grid-based elements ensure you can easily rearrange them in a page or view.

When thinking in terms of flexible building blocks rather than static templates, your designs can adapt to circumstances beyond their original context — I’m looking at you, as-yet-undreamed-of-next-version.

Grab a free UXPin trial to build prototypes that snap to a sensible grid.

Take Advantage of Complex, Pre-built Elements in Design Systems

What resources do designers and developers need to keep a project on track, consistent, and easy to edit?

The answer lies in their team’s design system, which often includes practical, relevant examples of items used in design. They go under many names: components, widgets, elements, molecules …. Regardless of their names, the items that go into a design system solve several problems.

Easy to reference: Design systems make items easy to find in a hurry, whether by search or category or other criteria. To do so, the items’ names and metadata must be accurate and up-to-date.

Easy to apply: Ideally, items in design systems would contain the files, like PSDs, that designers can copy and repurpose for their immediate needs.

How complete should design system elements be?

From lo- to hi-fi, items in design systems should reflect the team’s workflow. If they need boilerplate information, then blank templates comprised of grey boxes should do the trick. If the team needs more pracitcal examples to answer, “how did we use this six months ago?” then high-fidelity items with real (or realistic) content is more appropriate.

For example, UXPin has basic shapes like boxes, arrows, and circles — standard design stuff. But it also has some built-out sets you can use as starting points for your work.

Design system components should be fully editable, right down to the text and colors. And some are more customizable than others. They should also be easily findable. For example, searching UXPin for certain keywords will produce many results:

app
store
list
music
phone
social
set

Individual component keywords include:

pagination
breadcrumbs
navigation
bar
form
tab
slider
body
head
foot
activity
icon

Build a design system in UXPin

Once you’ve customized the pre-built components — or created your own — you can save them as templates with our custom library feature. Dragging a saved component out of your custom library will create a copy that you can edit to suit your current design’s needs. This helps keep your interactive visuals in the same general family without having to reinvent them every time.

This is critical when thinking in terms of components: design system parts that snap together, rather than building single-use templates that don’t adapt to projects’ future needs. (Let’s face it: when was the last time an active digital project didn’t evolve over time?)

Design a System of Icons With These Techniques

Little icons have a big job. With limited real estate, they must convey meaning to people who expect to be informed about function or status. Maybe that’s why thousands of icons sets exist, many for free. But there’s nothing quite like making your own.

Project-specific icons help the project to stand apart and convey meaning unique to its functions. For example, most apps or dashboards let you create new records. But fewer systems will let you assign one record to another. That may require a creative symbol that people will come to recognize as they learn your product.

Their role in design systems leaves little room for ambiguity: meaning must remain clear in a variety of surrounding contexts, while fitting into the system’s overall aesthetic.

How does it work? Here are some tips to create your own winning icon sets.

Create a visual language

Iconography is more than tiny pictures. Together they form an entire family, not unlike a set of typefaces, that reinforce a brand.

They also prevent extra work. When you need an icon, just grab one from the project’s style library, or use the library as inspiration. To that end writing (and drawing) guidelines for new icons is important.

Make guidelines. Part of your design system should include parameters on what your team can and can’t do with icons.
Practice style. One of the best ways to develop a visual language is to apply it to new ideas. As you invent icons, make sure they fit the same look — but don’t be afraid to modify that look early in your work.
Test each iteration. Do your icons make sense? Can people figure out what they mean? Getting stylish while retaining clear meaning requires showing your work to users.

Getting ideas

Where do icons come from? Your imagination is just the beginning. Seeking inspiration from outside sources can be critical to success.

Look up synonyms for the word or concept you want to represent.
Look for styles beyond the obvious. What inspiration might you find from, say, Polynesian symbols or Mandarin letterforms?
Doodle shapes at random, avoiding backgrounds like circles or squares.
Use the brand. Does your project’s logo have an eye-catching characteristic you can use? How about the project’s typography?
Create negative space. How can the interactions of three or four regular geometric shapes overlap to create new and interesting forms?

Base complex forms on the same shapes

Recognizability is the most important aspect of an icon. If people don’t know it at a glance, they may waste precious time deciphering it — or look elsewhere for a shape they associate with the function at hand.

With that in mind we start by defining icons’ silhouettes. But don’t just start drawing lines.

Use the same geometry. Here we make shapes based entirely on small circles and rectangles. When you base icons on the same general elements, they look like they belong to the same family
Use the same angles, e.g. 90°, 45°, 30°. Doing so will make them more legible and more consistent.
Same line weight throughout. Here, basing glyphs on the same few shapes will help keep your icons looking similar without looking derivative.
Stick to symmetry — or the same asymmetry. Tilting your icons is a great way to make them stand out from other sets. But if you do so, tilt them all at the same angle to reinforce that they’re part of the same family. Otherwise stick to good ol’ right angles.

This example may stick to its base shapes a little too closely for practical design work, but demonstrates how simple geometry can create complex forms that look like they belong together.

Make a consistent color palette

Like using geometry to make icons look like a set, if you plan to use color, then you should use the same color palette. But which colors?

Seek inspiration from your photos. If you have final art for your project, make the icons look harmonious by sampling colors from that art.
Borrow from Google’s MDL palette. They’ve done a great job of selecting bright colors that stand out against a variety of backgrounds, yet rarely clash among themselves.
Make sure the colors work well together. Speaking of clashes, test every combination of your preferred colors to keep them from looking awkward when adjacent to each other.
Use one color per icon. The contemporary “flat” look works best without shading, shadows, gradients, or other details that detract from their silhouettes.
Use values. If you must use multiple colors, try to use different shades of the same hues.
Consider meaning. Should colors imply function? It’s up to you, but remember that many people associate color with actions, like red for “delete,” green for “create,” and faded (usually less opaque) for “disabled.”

How much color is too much? How much is too little? Determine your color palette based on one factor: attention. If your icons need to grab people’s eyes, then make ’em bright. Otherwise aim for consistency.

Remember that symbols have preconceived meanings

People often associate certain “universal” icons with certain functions. The trash can, for example, means “delete.” Hamburger icons, though, aren’t universally understood … yet.

Using microcopy with icons is a good idea. Rely on shapes for quick identification, and text for folks who don’t get it.

Designing a system

Icons must do a lot with a little. In spite of running small, people expect to “get it” at first glance. That’s why silhouettes, consistency, color, and meaning all work together for a great, on-brand icon set.

Tips on Asking for Feedback

UXPin’s preview mode is great for soliciting feedback. But leaving stakeholders to their own devices can give too many random opinions, and not enough constructive criticism. In short, “what do you think?” often results in bland, unhelpful, off-topic comments.

Here are some tips to get great feedback:

State your goals. Telling stakeholders “I’m going for X” or “I want to achieve Y” helps them to frame responses in ways that keep the conversation on the topic. Learn more about goal-setting at SurveyMonkey.

Assign comments to someone. UXPin lets you indicate who should address certain points of feedback. Learn more about assigning comments in the UXPin User Guide.

Set a deadline. I’ve found it helpful to ask for feedback by a certain date, both to encourage timely replies and to keep a project moving forward. Think of it as agile sprints for opinions. Learn more about working under tight deadlines at UXPin.

Figure time vs. benefit. Make a graph with time to implement on one axis and benefit to users or the business on the other. Then jot keywords or phrases that summarize each bit of feedback on the graph. Prioritize items that are easiest to implement and most beneficial first. Learn more about data visualization tools at Creative Bloq.

Ask the right people. Chances are, not everyone in your organization needs to weigh in on a design in progress. Ask as few people as possible, like one of your peers, your creative director, or select beta testers to keep from getting overwhelmed. Learn more about getting feedback at ZURB.

Take feedback seriously, but lightly. Feedback is loaded with personal views. People’s comments are suggestions that you can weigh against your own judgement. For example, just because someone likes blue doesn’t mean you have to change to fit their preferences. Learn more about judging feedback at Inc.com.

“Perfect is the enemy of done.” Sometimes meeting deadlines is more important than getting everything perfect… whatever “perfect” even means. If you iterate on feedback more than three times, maybe it’s time to move on. Learn more about being good and doing great at Six Revisions.

Solicit great feedback from your team with a free trial of UXPin.

How to Prepare for the Freelance Design Life

Going freelance is a risky business. Designers who want to switch from full-time to independent work face many hurdles, some of which begin long before the designers are prepared.

According to the US Small Business Association, about 50% of new businesses fail within five years. That number will likely increase for designers who set out before they’re ready, or who underestimate the amount and type of work involved.

But designers who wish to freelance can take steps that mitigate the chances of failure by following simple advice.

Don’t neglect the business side of freelancing

Designers should go into full-time freelancing with their eyes open. For example, knowing that the business itself occupies more time than most expect can help them find their daily, weekly, or monthly rhythm.

Ilise Benun (@ilisebenun ), Author, Speaker and Founder of Marketing-Mentor.com, knows this well. “Business tasks could take 30–40% of a designer’s time, including email, marketing, project management — all the things you don’t get paid for,” she said in a phone interview. “Some people say, ‘Well, I’m getting paid so that’s the priority.’ But marketing is an investment. I advise my clients to spend the equivalent of one day per week marketing themselves.” Many of her clients do just that, dedicating a single day per week to self-promotion and bookkeeping rather than breaking their flow for a few hours per day.

No matter the when it occurs, knowing how much time each project is taking is critical to success because bookkeeping can warn designers when a given project is running over budget. But when it comes to taxes, Ilise said there’s only one solution.

“Do your own bookkeeping if you can. If not, you need a separate person. But definitely find an accountant,” she said. “Don’t do your own taxes.”

Earning clients at pace

A sudden switch to freelancing is less likely to succeed than a gradual move. Ilise recommended doing side jobs before taking the plunge. And should you make the leap, you can’t expect it to happen automatically. Building a network and reputation is vital before starting a business because getting clients isn’t easy.

“People don’t realize how much time and effort it takes to get clients you want,” Ilise said. “I have a pet peeve. When people ask how to get work, word of mouth isn’t actually a marketing tool. You can ask for referrals and will probably get them from people you know, but when you do, the person referred may not have a need for you.”

At the same time, such leads aren’t without value — if a freelancer is willing to keep the relationship going. Just because someone isn’t interested in a freelance designer’s services at the time doesn’t mean their needs won’t change in the future.

“I think (freelancers) misunderstand silence or a ‘no.’ They assume the referral is not interested. Stay in touch with them — it might turn into something later,” Ilise said. “Money in the bank is helpful, but it’s better to have that network.”

Working on the side requires dedication

Employers may not take kindly knowing that one of their designers is looking to freelance. But a new trend is emerging. Designers are switching between freelance and full-time work more frequently than in past years, Ilise said. Making the switch repeatedly is a good way to keep one’s network going, although it reinforces a common notion about freelancers and their work ethic.

“Freelancers have a bad rap,” Ilise said. “People assume they’re unreliable or flaky. They have to overcome that preconceived notion by over communicating and over reliability.”

So it’s no surprise that extra work is involved, keeping designers active in the community and nimble in their self-promotion, even during full-time jobs — not to mention possibly working on the side without creating conflicts of interest.

“The way that works is if you keep freelance business going. That way you don’t have to start from scratch,” Ilise said. “Keep cultivating your network and keep your portfolio up to date.”

So what’s a freelancer’s time worth?

Money is a sensitive topic, especially for many new freelancers. Setting expectations too high is one concern. Having to pay rent is another.

“I’m a proponent that your hourly rate is not your price (per project). You can use it to determine your price, but it’s about negotiating with each client,” Ilise said.

Freelancers know what they need. Clients know what they’re willing to pay. Finding middle ground that satisfies both parties isn’t easy for new freelancers, who often price themselves under what they’re worth. Ilise has a solution.

“Here’s the trick for that: you ask the client for their budget. They’ll stop if they don’t have numbers. So ask if they have $500, $5,000, or $50,000. That restarts the conversation,” she said.

Gauging estimates by orders of magnitude may seem extreme, but Ilise said having a ballpark figure will give everyone a sense of the project’s scope that will lead to a fair price.

Taking the plunge

While no advice can substitute for practice and experience, new freelancers can prepare for success by deciding what it looks like. The old adage, “begin with the end in mind” rings true for people whose career no longer depends on meeting quotas or filling out time reports.

Almost by definition, freelancers risk a lot in starting their own business. Those who wish to try can take gradual steps to improve their odds of success.

Starting the conversation

Make a practical case for design systems

Speak in the right language

The tangible side of a design system

Going forward

Join the world's best designers who use UXPin.

When elements get lost, design comes to the rescue

Natural variations are part of the design system

What might change?

How stand-outs fit a design system

How stand-outs stand out

Write rules to break, then integrate

Join the world's best designers who use UXPin.

Know your audience, know your goals

Making a design system well-designed

What information should go into a design system’s design?

Organizing a design system

Going forward

Designing a system

1. Create random content in rows and columns

2. Make column headings

3. Give the element states per column

4. Rearrange the content per state

5. Make the headings clickable

Designing data

Demo

Join the world's best designers who use UXPin.

The “so what?” factor

What to write

A documentation template

Tips

Building a stronger design system

Join the world's best designers who use UXPin.

1. Find radio elements

2. Create states

3. Add interactive hotspots

Join the world's best designers who use UXPin.

A systematic approach

Bringing the team onboard

What’s in a snippet?

Going forward

Build your own drop-down list

How it works

Join the world's best designers who use UXPin.

Organizing a design system’s pattern library

Element overview

Pattern use cases

Taxonomy

Pattern libraries work with a team’s workflows

Prototyping a design system grid

Editing the grid

What about the canvas?

Using grids in your work

Join the world's best designers who use UXPin.

How complete should design system elements be?

Build a design system in UXPin

Join the world's best designers who use UXPin.

Create a visual language

Getting ideas

Base complex forms on the same shapes

Make a consistent color palette

Remember that symbols have preconceived meanings

Designing a system

Join the world's best designers who use UXPin.

Don’t neglect the business side of freelancing

Earning clients at pace

Working on the side requires dedication

So what’s a freelancer’s time worth?

Taking the plunge