The shorter version of these slides was presented at Amuse UX 2015 Special Meetup (Budapest, Hungary) — http://www.meetup.com/UXbudapest/events/225944151/.
DOCUMENT-DRIVEN DESIGN
Many designers still focus on deliverables – work products of
their creative process. They do research on a market and users,
define scenarios and IA, explore solutions through sketching and
prototyping, create mockups and guidelines, then give all of their
deliverables to the developers.
R.I.P. THIS
As a result, designers spend their time polishing supplementary
documentation instead of focusing on the product itself. The
purpose of most deliverables is simply to transfer knowledge
about the product design to other team members, and they
quickly become obsolete. This approach leads to high
transactional costs. It’s definitely not an optimal approach!
THE AGE OF SHREDDER
A new approach requires that designers no longer consider their
work narrowly, focusing on projects whose goal is to launch a new
product or feature. Instead, they focus on bringing a holistic
product platform to market, then evolving it. A product or
product line then grows systematically, and a company’s UX
strategy works on all 3 levels: operational, tactical, and strategic.
3 LEVELS OF UX MATURITY
CHAOS
OPERATIONAL
TACTICAL
STRATEGIC
3 LEVELS OF UX MATURITY
Operational. The designer is just an implementer, working on
individual design tasks and creating design deliverables.
Tactical. An integral part of a product team and deeply
integrates design into other product development processes.
Strategic. The designer is a visionary or product owner who
influences strategic decisions on how to evolve a product.
GUIDELINES RULE?
Classic solutions for systematic product design are guidelines and
pattern libraries.
However, they create a
“guidelines → design → front-end code → implementation”
workflow, where a lot of design and product details get lost.
1.
NOBODY READS DOCUMENTATION
Designers often complain that developers don’t read the
documentation. But, to be fair, designers themselves seldom refer
to it when interacting with several people.
They’re always too busy!
2.
A GUIDELINE FOR A PRODUCT LINE?
HUH!
Specifications often require updates, new patterns emerge, and
designers discover better solutions for old designs. As a result,
design implementation and the creation of guidelines move on
parallel tracks.
So where’s the reference design – in the documentation or the
implementation?
3.
DESIGN QUALITY CONTROL
IS TIRESOME AND EXPENSIVE
Designers should control every screen of every product, manually.
This approach requires massive effort, and keeping the design
quality high takes a lot of time – thus, it’s expensive.
4.
PROBLEMS MULTIPLY
WITH DESIGN UPDATES
You should start again from the very beginning, then ensure the
full realization of the new design in every product.
THE LIST OF PROBLEMS
IS EVEN BIGGER
Plus, when doing responsive Web design, you can multiply these
issues by the number of breakpoints you’re supporting. Many
companies just hire more designers in this case.
BLAZES!
WE CAN’T DO IT
WITHOUT TECHNOLOGY
Systems thinkers are looking at the intersection of design and
technology. Only by moving the reference design from static docs
to the implementation can you shorten the production cycle to
“guidelines = design = front-end code → implementation".
Many troubles with design implementation, enhancement, and
support then go away.
TO MARRY
DESIGN + TECHNOLOGY
Many big companies are moving in this
direction because it allows them to create and
implement good designs faster and cheaper.
WE DID IT TWICE
We used this ideology to launch two product lines – mobile web
and media products. In this presentation I’ll uncover the details of
building such a platform.
12 MOBILE WEBSITES (2013)
We designed the first batch in 3 months – a new record for us.
A component-based design system was born.
10 NEWS WEBSITES (2014)
Time to market dropped from 1-1,5 years to 6 months.
Not to mention decreased support costs and better quality.
http://health. http://weather http://lady.mai http://auto.ma http://kino.mail.ru/
A UNIVERSAL DESIGN SYSTEM
Now we’re building a more universal platform for different
product lines. We have a lot of work to do.
40PRODUCTS
Add to this mobile and tablet sites and apps, promo pages… It's
about two hundred projects if you sum it up. A lot of them are
leaders in their market niches.
My team works on a half of them.
*
*
150MLN USERS (MONTHLY)
Total audience of Mail.Ru Group products. We should be careful
with redesigns – it’s easy to insult them and lose market share.
INTUIT HARMONY
There are some fantastic case studies demonstrating it,
including Intuit’s Harmony ecosystem.
LOTS OF COMPANIES ARE HERE
In 2012-2013, many companies pursued this approach
simultaneously. We started here too.
There are five levels of maturity for this approach:
1. Design principles have been defined, then implemented in
CSS.
2. All products use common UI components.
3. Living guidelines exist that describe design principles and
common components. Example components and pages are
implemented in code, not shown in screenshots.
4. Prototyping is possible using common components of code
from the living guidelines.
5. Design experiments employ common components, making it
possible to compare different approaches.
1. A UNIFIED
VISUAL STYLE,
INTERACTION PRINCIPLES,
INFORMATION ARCHITECTURE
It benefit users by ensuring that an organization’s products are
visually familiar and work in the same way.
This is also great for the brand because it results in a holistic
design for an entire product line.
{
2.
100% 90% GUARANTEE
This development process guarantees consistency of a product’s
UI because all ready-made code blocks and elements come from
the common code base.
The other 10% is up to designers, who should choose design
patterns with care when creating screens. You can build a monster
even with a perfect toolkit.
3.
EASIER TO DO REDESIGNS
AND NEW LAUNCHES
The framework provides all necessary user-interface controls,
patterns, and components. It also helps you to build new designs
really quickly.
4.
EASIER TO MANAGE
A PRODUCT PORTFOLIO
It’s when all products are being built in the same way. Instead of
closely monitoring many separate projects, designers can just
manage a few core guidelines.
5.
LESS ROUTINE WORK
Designers produce less mockups and other unnecessary artifacts.
You can create a page out of ready-made components, bypassing
Photoshop altogether in the future.
6.
SCALING BEST PRACTICES
Successful product decisions have a cumulative effect. For
example, if your new design increases pageview metrics on your
Sports Web site, you can quickly apply those enhancements to all
of your other services.
7.
ALWAYS UP-TO-DATE
You can move from doing large redesigns every couple of years
to constantly updating designs.
Large redesigns take a lot of time and effort, and a thousand little
enhancements that you’ve made to a design throughout its
lifetime typically get lost in the process.
MANAGING TRENDS
Using common components would make it easy to capitalize on
whatever the next design trend after flat design might be.
Of course, running after trends is not a viable design strategy.
However, there are sometimes radical transformations that
seemingly happen overnight – as with iOS 7. Companies need a
way to react to such changes quickly.
UX STRATEGY’S CRITICAL PART
We had tried to unify design and implementation several times
through specifications, UI Kits, and pattern libraries. But these
were never viable solutions.
Developers rarely requested these deliverables, which were
internal to the design team.
Once and for all!
When you create, then reuse
an accurate design implementation,
you can be much more confident
in the quality of the products you launch.
The best way to succeed
in a product design-unification effort
is to move design artifacts
to the implementation level.
BILL SCOTT
At PayPal, it took 6 weeks to change a block of text
on the home page because of tech constraints. This
slowed down the evolution of designs and made
experiments impossible. At Netflix, he had made
dev-process simplification one of his team’s
primary goals with a flexible HTML5 framework.
USE DESIGNER’S HEAD,
NOT JUST THEIR HANDS
Reducing the amount of routine, operational work that designers
must do lets them move their focus to strategic tasks such as
product definition and solving business problems.
THE COMPANY BENEFITS TOO
Successful product decisions have a cumulative effect.
Faster time to market and revenues for new products and
features.
Guaranteed design unity.
Reduced costs and efficiency improvements.
Minus costs of creating a platform.
*
*
STOP THINKING ABOUT SCREENS!
Instead, view product design and development as platform
development.
For example, look at what Google, Apple, and Microsoft have
done. They’ve made terrific progress by building platforms and
ecosystems. Even if your company is smaller and has less
ambitious goals, you can still learn from these giants.
If you deconstruct these platforms’ key elements:
general principles of visual and interaction design,
a portfolio of products that includes their own apps,
as well as a vast array of third-party apps (like made by
partners and contractors),
these have much in common with what any product company
creates.
WHERE DO I BEGIN?
TWO WAYS, AGAIN
You can first create guidelines, then build products based on
them.
Or you can launch a successful product, then build guidelines
based on it.
Both of which have pros and cons.
WE CHOSE THE SECOND APPROACH
We scaled the already tried-and-tested design that we’d
optimized after doing user research and gathering analytics.
Nearing product launch, then right after release, we conducted
many experiments and tests that led to many design tweaks.
This approach is rocky and requires some refactoring.
*
*
PARALLEL TRACKS ARE HARD
While designing guidelines and products simultaneously may
seem ideal, doing so would take an enormous amount of time
because there would be seemingly endless iterations: “A new
pattern is proposed → it’s applied to several products →
inconsistencies are found → the whole team discusses and fixes
the problems → the revised pattern is applied to products”.
On a real project, the product would never get released.
*
*
MATT MCMANUS
Tells about “continuous design approach”. It’s
necessary to abandon the long-held concept of
“final designs”. Designers must be involved
throughout the entire product development
process, not just at the beginning.
1.
DESIGN MANIFEST OF PRINCIPLES
A set of about a dozen principles that help us to integrate brand
image with specific product-design decisions.
They work as a high-level checklist that we use to validate our
design patterns.
MICROSOFT
They advise focusing on content rather than chrome for Metro design,
and the role of animation is also foundational. Setting such principles
leads to a consistent experience across all products and devices.
MY.COM
One principle for our international brand is to combine a minimalistic
white surface for all user-interface blocks with bold red accents.
However, other brand qualities include personality and emotion. To support
these without breaking the first rule, we use colorful backgrounds wherever
the main working surface lies on top of a semi-transparent white container.
A LANGUAGE FOR EVERYBODY
You should tie design principles to a company’s business strategy.
For design principles, we do this primarily through branding,
ensuring strong impact and value for managers and other team
members.
The purpose of brand design principles is to help you make
design decisions.
DESIGN PRINCIPLES FTW
Principles should not overlap, and there should be a reasonably small
number of them to ensure that they’re memorable. You can find
inspiration in this great collection.
2.
INFORMATION ARCHITECTURE
Considering the specific target audience for a product,
information architecture principles should guide the distribution
of features and scenarios across pages or screens, so you can
build a suitable hierarchy and navigation system.
Within a product line, the information architectures for different
products can vary significantly, so may require different
approaches:
one-pager;
hierarchy;
linear;
network;
hub and spoke;
or a combination of these.
You should define what each of these constructs is good for and
how to map product features and scenarios to them.
You can also cover labeling, metadata, and organizational
schemes – such as alphabetical, geographical, temporal, topical,
task based, audience based, or popularity based.
Navigation bars in the header or footer;
Drop-down menus;
Contextual menus, which appear when a user right-clicks or
presses;
Search bars;
Breadcrumbs;
Drop-down list controls for sorting, filtering, or grouping;
Contextual links;
Notification systems and alerts.
Illustrate these patterns, showing how they should appear on
typical screens and annotate the illustrations with usage
recommendations that are tied to business goals – for example,
contextual links help improve pageview metrics.
Tie all interaction design patterns to device types – that is,
patterns for Web applications on the desktop, tablets, and mobile
devices, as well as patterns for operating systems that run on
tablets, mobile devices, and wearable devices.
Every device type has its own specific input methods such as
mouse, touch, and voice; shortcuts, including keyboard shortcuts
and gestures; and accessibility features.
4.
VISUAL LANGUAGE
These are specific principles that define visual presentation.
While the manifest of principles speaks on the level of values,
visual language is about specific decisions. We should strive to
keep a high abstraction level in all definitions.
1UI GRID
Superpixels! The increments (or modules) of a grid allow you
to align and measure the sizes and margins of all UI elements.
Many products now use an 8-pixel grid, including Android and
Google products. Windows 8 and Windows Phone use a 5-pixel
grid, while iOS uses an 11-pixel grid.
The 8-pixel increment is great because you can always divide it by
2 – for example, to create 2-pixel rounded rectangles. At Mail.Ru,
our UI grid limits sizes and margins to 4, 8, 16, 24, 32, 48, 96, or
128 pixels.
This approach became an unexpected boon for us, greatly
reducing the number of disputes and errors relating to every tiny
screen detail.
It’s better to measure a grid in density-independent pixels (dp)
rather than in pixels.
Designers calculate by a rule, not with a gut
It significantly decreases the number of
unnecessary disputes and small mistakes,
hugely improving the quality of design.
A 12-pixel grid is most prevalent now because the most popular
frameworks use it.
However, we chose to implement a rhythmic grid – a series of 40-
pixel columns with 20-pixel gutters. This results in 16 columns for
1024-pixel viewports, 20 for 1280-pixel viewports, 24 for 1440-
pixel viewports, and 26 for 1600-pixel viewports. This approach
allowed us to unify different generations of our designs.
The structural grid defines how responsiveness works for layouts
on screens of various resolutions.
3LAYOUTS
Now, getting to the level of specific design solutions, what UI work
areas are necessary, and how are they distributed on the structural
grid?
A page layout may consist of a single column, as is popular on
landing pages.
But most follow a classic two-column approach.
However, specialized and professional layouts often have three
columns.
Alternatively, a layout may comprise an infinite flow of cards
or tiles, as popularized by Pinterest.
A layout may also define a vertical ratio, but that’s rare.
4CONTAINERS
Every column in a layout holds containers that stack one after
another. Containers have a common visual style and logic.
You place content and controls within containers, which are useful
in defining visual presentation – for example, using borders,
backgrounds, shadows, and headers – and define interaction logic
for the container itself.
Containers make platform development easier and simplify
adding new patterns or tweaking current patterns. If there are
more elements than a container can display on a screen, overflow
logic becomes necessary – for example, a Show More link that
expands a list, page navigation, or infinite scrolling – whether
vertical or horizontal. If you choose horizontal scrolling and want
to change the style and position of arrows or add a swipe gesture
for touch devices, you can do it at the container level instead of
changing every instance.
You can be also define overlays and tutorials here.
*
*
5TYPOGRAPHIC GRID
Line height and type sizes should be based on the UI grid.
Use the idea of base-text scaling to build this grid.
For example, in our case, font parameters should be multiplied by
four. This is easy to do for headings, but problems often arise with
the body text:
web-font rendering is unpredictable in Windows and often
requires many hacks and tweaks;
16 pixels for the base text may be too large for a specific user
interface.
Nevertheless, if the line height fits into your UI grid well, it’s
already good enough. Display and text fonts won’t break the grid.
UI colors, including black and white and several shades of
gray for base surfaces, borders, and supplementary text;
colors for errors and other system messages – typically, red,
green, and yellow; and colors for links.
Accent colors – for example, for content categories. These
could use some variance algorithm – for example, to display
states, they could be tinted or shaded.
All of these additional colors should be harmonious with the
primary brand colors.
7UI KIT
Once you’ve created UI and typographic grids and paired them
with a color palette, you can create basic building blocks.
Buttons (primary and secondary action buttons, option
buttons, text and/or icon buttons for toolbars);
Links;
Generic and specific input boxes;
Drop-down lists such as combo boxes, date pickers, and
country selectors for telephone codes;
Selectors such as check boxes, radio buttons, and switches;
UGC (User-Generated Content) loaders for photos, videos, and
files.
Each of these requires states such as focused, active, hover, and
unavailable.
8DESIGN MATH
o Add the text “Save” in the base text size.
+ Add standard padding around the text.
+ Fill the space around the text with the standard background
color for controls.
+ Draw a border using a standard color, stroke width, and corner
radius.
+ Add a standard box shadow beneath the button.
A common language
As long as your design standards exist, they
will lead all designers and developers to
consistently make the same design decisions,
no matter where they are.
FORM LAYOUTS
Form elements should have field sets defined. Consider the
placement of field labels, tip or descriptive text, validation rules,
and error text.
GRAPHICS AND ILLUSTRATIONS
You should define standards for photos, other content images,
and user avatars, including their proportions, typical sizes, and
alternate sizes for various screen resolutions. Try to fit them into
the column grid.
UI ICONS
These should follow brand guidelines, so you can build a
universal icon set for all products.
Define their general style, stroke width, color palette, volume-
representation principles, and their placement in user interfaces
or promotional materials. Lay out small or mid-sized icons in a
standardized grid.
Define the general style of illustrations. Consider creating a mood
board when making decisions about style.
You can base large illustrative icons on the metaphors you’ve
used in small UI icons, adding detail.
INFOGRAPHICS
AND DATA VISUALIZATIONS
One more design asset to unify.
You’d need all of these only for highly specialized products, but
some of these are in wide use.
Tables;
Common types of diagrams such a histograms, pie charts,
and bar, line, and area graphs;
Specialty diagrams such as bubble, ring, radar, and span
charts, Venn and Sankey diagrams, maps and cartograms,
heatmaps, tag clouds, trees and tree maps, mindmaps, block
charts, flow diagrams, timelines, and arc diagrams.
ANIMATION MODEL
In a perfect product, all transitions between states and screens
should be based on a well-defined model. Animation should be
consistent, making users more comfortable.
For example, an overlay could slide down from the top of the
screen, then slide back up when it’s closing. For a multi-step
wizard, the next step could slide in from the right; the previous
step, from the left.
The best source of inspiration for animations are the three major
mobile operating systems:
Android (orchestration);
iOS (before and after iOS7);
Windows Phone (which introduced the modern approach to
UI animation).
ADS
First, define an advertisement grid – within the limitations of the
design grid – which typically determines the visual appearance of
ads.
To determine design-friendly ad formats, it’s critical that you
communicate with sales as much as with developers.
Set standards for your ad inventory. Define types and sizes of
display and contextual ads, branding principles for pages and
patterns, and limitations for full-screen banners and other
aggressive advertising approaches.
Set requirements for internal promotions as well.
Second, define an advertising-layout grid, which determines
where ads are placed in a layout.
5.
DESIGN PRINCIPLES IN CODE
Once you’ve defined basic design principles, you can bake them
into your CSS – thus, completing the first platform-maturity level.
Plus, icon fonts and SVG sprites simplify your usage of graphics.
Designers should understand code, so they can build a truly
future-proof platform.
Design is defined on every project phase
Systems thinking and the continuous
improvement of a design implementation
throughout the product development cycle are
key to delivering high-quality products.
GLOBAL VARIABLES
Modern CSS preprocessors like SASS and Less let you define
variables, which is a great way of implementing design principles
in code.
Once you’ve defined standards in code, you can easily update
them globally, magically changing the design of your whole
product line.
TOKENS TO UNIFY WEB AND NATIVE
These are “super variables” stored outside of a specific platform
like web, iOS, Android, etc. Then this specific platform imports
tokens and stores variables in CSS, XML, or other format required
by its technology.
It allows you to keep visual language consistent across web and
native development environment.
The idea was proposed by Salesforce
*
*
TYPICAL PAGE LAYOUTS
Also, code examples of typical page layouts, including a header,
footer, content area, and columns will make your guidelines easier
to use and understand.
UI COMPONENTS
Since your goal is to simplify your production cycle to
“guidelines = design = front-end code → implementation”,
a component is ready-made code that defines a UI element
and applies visual appearance and user-interaction logic to it.
Components should be independent of their context, so you can
put them anywhere, on any page, and they won’t break.
PATTERNS 2.0
A component is a classic design pattern. The difference is that you’re
no longer using deliverables to define them, control their
implementation quality, or support them.
COMPANY-WIDE UPDATES
Furthermore, if you want to update a pattern, you just have to
change the code in the unified code base to update the
component in all of the products based on your framework.
Here are some examples of components:
navigation – tabs, alphabetical navigation, calendar navigation,
search, filters, sorting controls, and a browsing history;
lists – drop-down lists, matrices, horizontal sliders, and
asynchronous tile grids;
media – videos, infographics, a photo gallery, and social-media
embeds;
informers – gadgets that display information about the weather,
stocks and commodities, sport statistics, schedules, horoscopes, or
world clocks;
social interactions – comments, surveys, ratings, feedback, and
social sharing.
TYPICAL PAGES
In addition to defining specific components, you should define
typical page types based on them. Create newsletter templates as
well.
It’s best to standardize anything that you use more than once.
News listing;
Article;
Search results;
Settings;
User profile;
Sign in and sign up;
Blank pages
Server errors.
SEMANTIC CODE IN COMPONENTS
One basic principle is that the names for patterns should have
semantic meaning and refer to types of elements rather than their
style – for example, second-level heading or surface for cards
rather than 24pt font or surface color #F0F0F0 – or refer to their
target usage – for example, main content, more information on a
topic, or supplementary links.
As long as you do this, the goal of making updates across your entire
product line easy will work as intended.
*
*
UNIFICATION OR BORINGFICATION?
Having several products or services based on the same
components might lead to boring user interfaces.
Your platform should let you stylize certain properties of
components for specific products, without altering the main
component’s essential design.
STYLIZATION EXAMPLES
Our team decided to use different accent colors for specific products. Each
product has its own accent color to differentiate it from other products. You
can also use different fonts, decorative elements, illustrations, and icons.
100% ACCURATE
It shows a real implementation, not just screenshots.
This radically simplifies quality control for a product line.
Its first sections should describe general principles, which you’ve
extracted from your actual CSS.
Then include ready-made components that you’ve used in real
products. You should describe each of these components,
including where and why it should be used.
Even if you’ve built a simplified system that is similar to Bootstrap,
it will help you greatly in systematizing design.
I LOVE THIS RESOURCE!
I refer to styleguides.io again –
it’s a huge directory of tools to create living guidelines.
AUTO-HEALING SYSTEM
A spider script occasionally goes through all products, comparing
their CSS to reference values.
Then, if there are inconsistencies, designers should get a list of
the problems discovered.
LESS INSERTIONS
Once all key parts of a platform are up and running, you can
simplify your production cycle even further and leave behind
tools for deliverables creation entirely.
When living guidelines show a component’s HTML code, it
becomes easy to create a real page in an HTML editor using
layout templates.
PHOTOSHOP SUCKS LESS OFTEN
Many designers are no longer afraid to code. Coding in HTML
and CSS are simple enough, and there are many simple tutorials
and ready-made examples of code on the Web.
Photoshop or Sketch are great for design exploration. But,
especially for RWD, it’s getting harder to work productively
without moving at least part of your process into a browser.
AXURE IN A BROWSER
If your company has the resources and your platform is mature
enough, you could go further and build an online tool for visual
prototyping.
Designers could drag ready-made components onto a page to
create an interactive prototype.
PROJECT POLYMER CONSTRUCTOR
Google has a web tool,
which lets you to create Material Design in a browser.
https://polymer-designer.appspot.com/
REAL DATA
While good designers don’t use “Lorem ipsum”, it takes a bit of
effort to create mock data.
Showing different states of pages and patterns takes even more
time, so making data easy to import into a prototype would help
us to do this faster.
COMMUNICATE EASIER
In addition to a functional prototype’s being cheap to create, it
works much better as a communication tool. You can link pages
and use all of the logic and scripts from the production version.
Plus, pages are all properly responsive, so you don’t have to
address same problems again and again.
A/B TESTING OUT OF THE BOX
Design patterns don’t solve problems once and for all. You should
always strive to find better solutions. You should experiment as
much as possible and compare alternative approaches.
A great platform should afford the ability to do this systematically
and inexpensively, making it simpler to do usability testing and
run A/B tests.
KNOWLEDGE BASE
You can save historical versions of patterns, including the details
about and results of experiments.
This helps you to learn why they worked or how they failed, so
you can gain insights that you can apply when creating future
enhancements.
A CUMULATIVE EFFECT
The main benefit of a platform is that every project uses an actual
version of a component from the unified code base.
So you can quickly distribute an optimized variant across the
whole product line, and the company benefits from cumulative
advances.
DESIGN ALGORITHMS, NOT SCREENS
On algorithmic platforms, designers and developers define logic
that considers content, context, and user data, then the platform
compiles a design based on principles and patterns.
SUPER-DUPER-FINE-TUNING
In this way, it is possible to fine-tune the tiniest details of a user
interface for specific usage scenarios, without your having to
draw and code dozens of screen states.
AUTOMATED MAGAZINE LAYOUTS
The existing content had poor semantic structure, and it was too
expensive to update by hand. A special script parsed an article
and, depending on its content – for example, the number of
paragraphs and words in each article, photos and their formats –
the script chose the most suitable pattern in which to present
parts of the article.
ARE WE THERE YET?
Algorithmic design is far from being an established approach –
it’s rarely even discussed today.
But, in the future, it could definitely help designers to achieve
truly groundbreaking designs, even on more mature platforms. It
will automate the routine, freeing us for new thinking.
OUR STORY
Mail.Ru Group is taking this platform approach.
To get there, we’ve committed to the whole
process of framework creation and
implementation.
1.
CREATE THE REFERENCE DESIGN
AND THE PLATFORM
We defined a suitable and scalable information architecture,
interaction-design principles, visual styles, and a technical
solution for implementing the framework.
2.
MOVE ALL PRODUCTS
TO THE PLATFORM
We’ve expanded our unified code base with new patterns and
made the back-end for every product conform to framework
requirements.
We use two strategies: either redesign a product from scratch or
update it gradually component by component, page by page.
3.
REFACTOR THE DESIGN PROCESS
We’ve created design solutions for core product tasks and are
fine-tuning the technical solution now, so we’ll be able to
dispense with most design artifacts soon and create new screens
out of ready-made blocks of code from our unified code base.
4.
REFACTOR THE DESIGN
We’ve released a dozen products and discovered a lot of
problems after their launch, so refactoring their designs is taking
a significant amount of time. Plus, design trends are changing,
requiring further refactoring.
It takes some time to setup the product update process – you
need component versioning and management approval workflow.
WE’RE ON THIS WAY
We are now on the third and fourth steps of our framework-
implementation process. We’ve seen benefits from working with
the platform from the very beginning, the evolution of our
designs is becoming easy, and we’ve reduced unnecessary
design-documentation work significantly.
We’re currently updating the visual design across our platform, so
we’ll find out whether this is as easy as we intended. When rolling
out a set of living guidelines, implementation takes a couple of
years, so there is always the risk that new design trends may
emerge.
Even so, you should strictly follow your own standards. Sure,
during the framework rollout, some of your products won’t have
up-to-date visual designs. But once you’ve launched your
platform, you’ll have the luxury of updating the designs for a
dozen products at one time, in a matter of just a few weeks.
WHAT ABOUT APPS?
The component-based model that I’ve described is for the Web.
However, we’ve thought about applying this idea to mobile apps,
using bundles instead of components. These are shared
libraries to which we’ve applied a unified design. But for now,
we’re focused on our Web platform.
WE HAD OUR SHARE OF PROBLEMS
Nevertheless, looking back, I believe that we could have made the
implementation process faster and shorter. I’ve told you about
both our mistakes and our good decisions, so your job will be
easier if you decide to follow our path. We have had our share of
problems to be sure, but the overall result of this effort has been
amazing for our products, our users, and our product teams.
BEING TOUGH
When you’re implementing guidelines, they must be
authoritative. To achieve systematic design, always use existing
patterns and components whenever possible.
However, if there’s a need to introduce something new, you
should determine whether you’ll use it again in the future. If so,
create a new pattern or component.
This is the only way to keep your design framework up to date
and your product portfolio consistent. It also ensures that your
framework will be easy to support, enable you to create
comfortable user interfaces, and be a positive for your brand.
A.
BOOTSTRAP-LIKE SYSTEMS
Pro: Faster and cheaper. You can quickly profit from inexpensive
design experiments, fast prototyping, and simplified development
support.
Con: Design updates are still painful.
SMALL COMPANIES CAN DO IT TOO
Bootstrap and Foundation already solve a lot the problems by
implementing design principles in code, providing living
guidelines, and supporting prototyping.
BUILD YOUR OWN BOOTSTRAP
Lots of visionary publications by Anna Debenham, Brad Frost,
Mark Otto, and Dave Rupert were released around this time.
B.
COMPONENT-BASED SYSTEM
Pro: It guarantees the quality of the design implementation and
offers the benefits of easy product updates.
Con: It requires much more effort.
REACT VS BEM
Famous frameworks for true component-based design systems.
We use BEM ideology and some pieces of its technology.
THAT’S OUR CHOICE
We chose this approach at Mail.Ru Group. It started in the middle
of 2012 from a simple idea and an experiment.
NATHAN CURTIS
Nathan Curtis writes in-depth articles about
key parts of design systems and processes.
He published a book “Modular Web Design”
back in 2009.
ANNA DEBENHAM
She was one of the pioneers in creating living
style guides. She collects examples of such
systems, articles, presentations, and tools. This
is a marvelous resource, and I strongly
recommend that you check it out.
BRAD FROST
Brad Frost is the author of Atomic Design
ideology. He is currently writing a book on this
subject and has already published some
chapters from it on his Web site.
FROM COVER TO COVER!
A link heaven on living guidelines and component systems.
It’s better than any book!
I’m confident:
Any modern UX strategy
should employ platform principles
to ensure a good outcome for your products.
Wanna build a solid, sustainable foundation
for a product or an entire product line?
Forget about creating static guidelines and
pattern libraries and instead take a platform
approach. Interim design artifacts add
unnecessary costs to design projects.
It becomes faster and cheaper to get new products and features
to market.
It guarantees that you’ll achieve a unified design and sustain it in
the future.
It lets you run more design experiments to find the best solutions.
It benefits your whole product line by scaling the enhancements
you’ve made to individual products.
Designers work more with their heads, not just their hands.
LEAVING
HEROIC REDESIGNS BEHIND
Instead, you’ll be able to constantly update your designs.
The platform approach lets you spend more time thinking about
product design rather than design documentation and
maintenance.
P.S.Just don’t go extreme! Any new approach is an augmentation and
evolvement of existing ones, but not an abolishment.
It’s stupid to scream that modern designers only work in a
browser and everyone who still uses Photoshop/Sketch is ancient.
But you’ll ruin your career if you’re still bounded by classic tools.
I hope it’s not about you :)
*
*
CREDITS: DESIGN
EUGENE BELYAEV
EUGENE DOLGOV
MARIA BOBROVA
EUGENE FERULEV
ARTEM GLADKOV
ALEXEY KANDAUROV
DMITRY OSADCHUK
GEVORG GLECHYAN
ALEXANDER KIROV
ALEXEY SERGEEV
PAVEL SKRIPKIN SVETLANA SOLOVIEVA
ANDREW SUNDIEV YURY VETROV
KONSTANTIN ZUBANOV
CREDITS: DEVELOPMENT
ALEXANDER BEKBULATOV
ANTON EPREV
DMITRY BELYAEV
EUGENE IVANOV
ANDREW KUSIMOV
SERGEY NOZHKIN
BORIS REBROV
STANISLAV MIKHALSKY
ANTON POLESHUK
PAVEL RYBIN
PAVEL SCHERBININ
MAXIM TRUSOV
ARSTAN TOREGOZHIN
VITALY VASIN
PAVEL VDOVTSEV KONSTANTIN VOROZHEIKIN