Advertisement
Advertisement

More Related Content

Similar to Amuse UX 2015: Y.Vetrov — Platform Thinking(20)

Advertisement

More from Yury Vetrov(20)

Advertisement

Amuse UX 2015: Y.Vetrov — Platform Thinking

  1. PLATFORM THINKING APPLIED UX STRATEGY YURY VETROV MAIL.RU GROUP
  2. PRODUCT DESIGNER UX STRATEGY FRAMEWORK PLATFORM THINKING UX STRATEGY IMPLEMENTATION OUTCOME-DRIVEN DESIGN FROM DESIGN TEAM TO DESIGN CULTURE
  3. 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.
  4. 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!
  5. 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.
  6. 3 LEVELS OF UX MATURITY CHAOS OPERATIONAL TACTICAL STRATEGIC
  7. 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.
  8. BUILDING A DESIGN SYSTEM
  9. 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.
  10. 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!
  11. 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?
  12. 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.
  13. 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.
  14. 5. DESIGN EXPERIMENTS ARE EXPENSIVE They require yet another stack of deliverables and increase entropy.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 12 MOBILE WEBSITES (2013) We designed the first batch in 3 months – a new record for us. A component-based design system was born.
  20. 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/
  21. A UNIVERSAL DESIGN SYSTEM Now we’re building a more universal platform for different product lines. We have a lot of work to do.
  22. 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. * *
  23. 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.
  24. INTUIT HARMONY There are some fantastic case studies demonstrating it, including Intuit’s Harmony ecosystem.
  25. LONELY PLANET It’s based on their own Rizzo framework.
  26. POLYMER PROJECT A platform from Google based on material design.
  27. YANDEX.LEGO A constructor based on BEM (block-element-modifier) ideology and technology.
  28. LOTS OF COMPANIES ARE HERE In 2012-2013, many companies pursued this approach simultaneously. We started here too.
  29. 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.
  30. 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. {
  31. 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.
  32. 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.
  33. 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.
  34. 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.
  35. 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.
  36. 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.
  37. 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.
  38. 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.
  39. 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.
  40. The best way to succeed in a product design-unification effort is to move design artifacts to the implementation level.
  41. 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.
  42. 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.
  43. 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. * *
  44. HOW TO BUILD YOUR PLATFORM
  45. 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.
  46. 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.
  47. 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.
  48. 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. * *
  49. 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. * *
  50. 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.
  51. DESIGN LANGUAGE A foundation of the design & the platform.
  52. 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.
  53. MAILCHIMP The company puts a lot of effort into voice and tone.
  54. 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.
  55. MY.COM One principle for our international brand is to combine a minimalistic white surface for all user-interface blocks with bold red accents.
  56. 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.
  57. 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.
  58. 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.
  59. 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.
  60. 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.
  61. 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.
  62. 3. INTERACTION DESIGN Specific navigation patterns correspond to information architecture principles.
  63.  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.
  64. 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.
  65. 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.
  66. 1UI GRID Superpixels! The increments (or modules) of a grid allow you to align and measure the sizes and margins of all UI elements.
  67. 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.
  68. 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.
  69. 2STRUCTURAL GRID The number and size of the columns and gutters that define a UI layout.
  70. 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.
  71. 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?
  72.  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.
  73. 4CONTAINERS Every column in a layout holds containers that stack one after another. Containers have a common visual style and logic.
  74. 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. * *
  75. 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.
  76. 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.
  77. GRIDLOVER An online grid generator that brings most of scaling approaches together.
  78. 6COLOR PALETTE Add complementary values for your primary brand colors. Define formulas for borders, box shadows, overlays, etc.
  79.  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.
  80. 7UI KIT Once you’ve created UI and typographic grids and paired them with a color palette, you can create basic building blocks.
  81.  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.
  82. 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.
  83. 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.
  84. FORM LAYOUTS Form elements should have field sets defined. Consider the placement of field labels, tip or descriptive text, validation rules, and error text.
  85. 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.
  86. 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.
  87. 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.
  88. 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.
  89.  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.
  90. 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.
  91. 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).
  92. 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.
  93. 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.
  94. 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.
  95. 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.
  96. 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.
  97. 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 * *
  98. 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.
  99. PATTERN LIBRARY Create common user-interface components and re-build products on them.
  100. 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.
  101. 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.
  102. 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.
  103. 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.
  104. 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.
  105.  News listing;  Article;  Search results;  Settings;  User profile;  Sign in and sign up;  Blank pages  Server errors.
  106. 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. * *
  107. 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.
  108. 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.
  109. LIVING GUIDELINES One more project based on common components.
  110. 100% ACCURATE It shows a real implementation, not just screenshots. This radically simplifies quality control for a product line.
  111. 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.
  112. I LOVE THIS RESOURCE! I refer to styleguides.io again – it’s a huge directory of tools to create living guidelines.
  113. 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.
  114. PROTOTYPING Re-factor the design process.
  115. 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.
  116. 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.
  117. 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.
  118. PROJECT POLYMER CONSTRUCTOR Google has a web tool, which lets you to create Material Design in a browser. https://polymer-designer.appspot.com/
  119. BOOTSTRAP-BASED Similar visual constructors exist for Bootstrap – for example, Jetstrap.
  120. 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.
  121. 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.
  122. DESIGN EXPERIMENTS Looking for the best patterns across alternative solutions.
  123. 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.
  124. 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.
  125. 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.
  126. ALGORITHM-DRIVEN DESIGN? Or meta-design.
  127. 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.
  128. 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.
  129. 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.
  130. DUPLO Flipboard launched a similar model last year.
  131. THE GRID CMS It chooses templates and retouches and crops photos all by itself. It runs A/B tests to choose the most suitable patterns.
  132. RENE An experimental tool for generative design by Jon Gold. It creates design variations from user defined variables.
  133. PARAMETRIC TYPOGRAPHY Tools like Robofont and Adobe Faces, which give designers flexibility and present new options.
  134. 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.
  135. 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.
  136. 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.
  137. 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.
  138. 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.
  139. 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.
  140. 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.
  141. 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.
  142. 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.
  143. 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.
  144. BEING TOUGH When you’re implementing guidelines, they must be authoritative. To achieve systematic design, always use existing patterns and components whenever possible.
  145. 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.
  146. REAL-WORLD EXAMPLES
  147. 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.
  148. 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.
  149. BUILD YOUR OWN BOOTSTRAP Lots of visionary publications by Anna Debenham, Brad Frost, Mark Otto, and Dave Rupert were released around this time.
  150. REALLY? Although these frameworks lack the benefits of a component- based system – they can’t simplify updates of a whole product line.
  151. 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.
  152. REACT VS BEM Famous frameworks for true component-based design systems. We use BEM ideology and some pieces of its technology.
  153. 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.
  154. 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.
  155. 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.
  156. 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.
  157. FROM COVER TO COVER! A link heaven on living guidelines and component systems. It’s better than any book!
  158. CLARITY CONFERENCE First conference on design systems launched in 2016.
  159. CONCLUSION
  160. I’m confident: Any modern UX strategy should employ platform principles to ensure a good outcome for your products.
  161. 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.
  162. 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.
  163. 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.
  164. 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 :) * *
  165. 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
  166. 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
  167. THANK YOU! YURY VETROV www.jvetrau.com twitter.com/jvetrau
Advertisement