Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Design Systems - Siili collective
Ähnlich wie Design Systems - Siili collective (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Design Systems - Siili collective
- 1. Design Systems 20.4.2018 Tomi Sjöblom & Esko Pyyluoma Collective 20.4.2018
- 2. Agenda 1. What on earth is a Design System? 2. History of Design Systems 3. Where are we now? 4. Parts of the System 5. System of communication 6. What’s in for us? 7. Future of Design Systems 2018-04-23 D E S I G N S Y S T E M S
- 3. What on earth is a Design System?
- 4. Preface W H A T O N E A R T H I S A D E S I G N S Y S T E M ? 4
- 6. 6
- 7. 7
- 8. 8
- 9. 9
- 11. The process of making a button TYPE x HIERARCHY x STATE x IMPLEMENTATION + QA RESPONSIVE? ACCESSIBLE? THEMEABLE? BROWSERS/DEVICES? 2018-04-23 W H A T O N E A R T H I S A D E S I G N S Y S T E M ? 11
- 12. The cost of making a button TYPE x HIERARCHY x STATE x IMPLEMENTATION x QA RESPONSIVE? ACCESSIBLE? THEMEABLE? BROWSERS/DEVICES? 2018-04-23 W H A T O N E A R T H I S A D E S I G N S Y S T E M ? 12 200 h x 90€ / h = 😰 x 5 teams = 😱
- 13. Scaling design is hard Designers have to face questions like: Developers have to face questions like: • What is the the Hex value of our blue? • Do you know how the CSS box model and inline alignment work? • Can you send me a comp of the page? • Is this already done somewhere? • Should it say ‘No’ or ‘Cancel’? • How hard can it be to make a button? • Why are we already behind schedule? • Can you redesign it, we can’t do it like this? • What’s the RGB value of our blue? • How many pixels of padding is ‘giving it room’? • What happens after you click that? • Is this already done somewhere? • Should it say ‘No’ or ‘Cancel’? • How hard can it be to make a button? • Why are we already behind schedule? • Can you do it again, it doesn’t look right? 2018-04-23 W H A T O N E A R T H I S A D E S I G N S Y S T E M ? 13
- 15. ”Software is often built by incredibly large teams of people. The challenge to create coherent experiences multiplies exponentially as more people are added to the mix. Over time, no matter how consistent or small a team is, different people will contribute new solutions and styles, causing experiences to diverge.” Karri Saarinen - AirBnb
- 16. History of design systems
- 18. Brand Guidelines 😊 Visual guidelines 😊 Voice & tone 😊 Brand attributes 😞 Focused on marketing collaterals 😞 Lack user interaction guidelines 😞 Hard to implement 2018-04-23 H I S T O R Y O F D E S I G N S Y S T E M S 18
- 20. Style Guides 😊 Written in code 😊 Usage guidelines 😊 Interactive components 😞 Hard to maintain and adapt 😞 Disconnected from the design process 😞 By-product of a project 2018-04-23 H I S T O R Y O F D E S I G N S Y S T E M S 20
- 22. Pattern Libraries 😊 Always up to date 😊 Usable components 😊 Product of it’s own 😞 Lacking the big picture 😞 Disconnected from the design process 😞 Technology & product specific 2018-04-23 H I S T O R Y O F D E S I G N S Y S T E M S 22
- 23. Where are we now?
- 24. Different takes to same issues 2018-04-23 W H E R E A R E W E N O W ? 24 BRAND GUIDELINE STYLE GUIDE PATTERN LIBRARY DESIGN SYSTEM PEOPLE Design-driven Development- driven Development- driven Holistic SCOPE L S/M S XL FOCUS S L XL L
- 28. Parts of the System
- 29. Design system is a kit of reusable, interconnected parts and practices, used by a community of collaborative, interconnected people to build a set of cohesive, interconnected products
- 31. Our design system offers ___________________________________________________ released as ___________________________________________________ and documented at ___________________________________________________ produced by ___________________________________________________ in order to serve ___________________________________________________ products and experiences.
- 32. Our design system offers visual style, UI components, and accessibility procedures released as React component library and Sketch assets and documented at designsystems.companyname.com produced by a systems team of 1 systems lead, 1 product manager, 1 designer, and 2 front- end developers partnering with a React-based engineering team in order to serve ~10 web-based and 2 native app products and experiences.
- 33. A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive. https://medium.com/eightshapes-llc/defining-design-systems-6dd4b03e0ff6
- 35. System of Systems Everyone already has a Design System. It’s probably not a good one, though. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 35
- 36. How good is your Design System? 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 36 -2 -1 0 1 2 3 ❓ Pixel designs with guidelines ❓ Lego approach ❓ Design handovers ❓ Project specific code ❌ Pixel designs ❌ Page approach ❌ Design through PDFs ❌ Page specific code ☑️ Responsive design ☑️ Component approach ☑️ Design-dev collaboration ☑️ Project style guide ✅ Component based design ✅ Small-to-big approach ✅ Design version control ✅ Cross- project reusable code Level 2 and… 🔥 Separate design system as a service 🔥 Products as customers 🔥 Design System specific roadmap Level 1 and… 💪 Modular design (atomic or similar) 💪 Content / Tone-of-voice guidelines 💪 System as dependency
- 37. Customers of the System Design system caters multiple products. If you can’t sell it to the product teams, there’s no use for Design System. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 37
- 38. How do we interact? • Team A is building a company website, with confident tone of voice and clean visuals. • Team B is building an internal tool, with official tone of voice and functional visuals. • Team C is building campaign sites, with enthusiastic tone of voice and bright visuals. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 38 Find the common ground.
- 39. There is always a system of system. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 39
- 40. Technical differences • Team A is creating company website as React powered Single-page app. • Team B is running intranet on Drupal platform, with minimal Javascript. • Team C is making static sites with some Vue.js for interaction. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 40 Find the common ground.
- 41. How much should you support? 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 41
- 42. Team motivations • Team A wants to have a consistent company brand to be reflected throughout the site. • Team B wants to be able to customize ready-made components with as little effort as possible. • Team C wants to go wild with the visuals, and seldomly returns to old projects. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 42 Find the common ground.
- 43. The system will be incomplete for a long time. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 43
- 44. Minimum Viable Benefit For all these teams to use the System, there must be value for them. 2018-04-23 S Y S T E M O F C O M M U N I C A T I O N 44
- 45. 2018-04-23 45 put brand colors to design system put brand color variables to design system create a brand color system in design system make creating forms easy with design system
- 46. What’s in for us?
- 47. Consultancy company + Design System? If consultants built a Design System… • Who would the internal customers be? • What products would it cater? • Which aspects should be included in the system? • Why should we keep that system up and running? 2018-04-23 W H A T ’ S I N F O R U S ? 47 🤔
- 48. Design System System? If consultants built a System for building Design Systems… • Who should we propose the approach? • How customizable should the system be? • What would be the business model? • Which ways can we ensure the system of systems is up to various challenges? 2018-04-23 W H A T ’ S I N F O R U S ? 48 🤔🤔🤔
- 49. Consultants as Design System specialists? If consultants helped clients to build Design Systems… • What would we require from the client? • How could we share the methodologies across projects? • Who would be the coordinating the efforts? 2018-04-23 W H A T ’ S I N F O R U S ? 49 💡
- 50. Scaling the design The biggest companies are the biggest drivers of Design Systems, as they have the biggest need for Design Systems. 2018-04-23 W H A T ’ S I N F O R U S ? 50
- 51. Where the Finns at? There’s proven Design System work happening in Finnish industry as well… 2018-04-23 W H A T ’ S I N F O R U S ? 51
- 52. Where do we want to be? Do we want to be the users or the creators? 2018-04-23 W H A T ’ S I N F O R U S 52
- 53. Future of Design Systems
- 54. Rise of DesignOps 2018-04-23 F U T U R E O F D E S I G N S Y S T E M S 54 • Design Systems need constant, just-in-time work • Design as a Service • In-and-out to design system consumer teams
- 55. Data in Design System 2018-04-23 F U T U R E O F D E S I G N S Y S T E M S 55 • When we get unified design, we can analyze it better. • Adoption data, A/B testing, real-time analytics? • How to connect the client analytics to system analytics?
- 56. AI in design • Breeding grounds for AI-assisted design decisions • Personalized experiences in new ways • Computational design boundaries • Machine learning utilized with Design Systems 2018-04-23 F U T U R E O F D E S I G N S Y S T E M S 56
- 57. 2018-04-23 F U T U R E O F D E S I G N S Y S T E M S 57
Hinweis der Redaktion
- Something we were asking during the conference. No one seemed to want to answer. I’m not going to give an answer either, but I’ll talk more about what it isn’t, could be and should be, which are far more interesting questions.
- First, a story of a button, and how to create one. It’s a simple component, we do them in pretty much every project. But what does it actually take to make a button?
- Buttons define and use most of the visual elements of an application or a brand. How is it spaced? What kind of typography? How is it laid out next to other elements? What style elements does it have, rounded borders? Shadows? Here are some of the things a developer has to figure out.
- It also defines and uses a lot of the verbal tone, as it’s one of the primary points of interaction. What terms should be used? How should it address users?
- The context of buttons is important. Can it be used over images? Or color background? Do these need guidance or alternative versions of the button?
- There should be some kind of visual and content hierarchy, different sizes and priorities of buttons are needed.
- How does the button react to user interaction or different states? It needs active indicator especially if accessibility is a concern.
- How is it implented in different parts of the application?
- All of these add up and require input from multiple team members with different expertises. When you add in QA you have to make further decisions. Is it Responsive? Does it need to be accessible and how? Does it need to have a different appearance in another application, or next year? What browsers and devices have to be supported and tested?
- It can take input from development team in excess of several hundred man hours to fully implement the simplest of components. That costs a lot. If you have 5 teams all building their own buttons, it costs a lot more.
- This is because both developers and designers have to spend time thinking about things which don’t relate to the work they’re expected to do, which takes away time from doing that work and creates frustration, inconsistant and poor experience for the user and slows down velocity We speak different languages. Components mean different things to a designer, and design patterns mean something else to a developer. There are assumptions of meanings, but they aren’t shared The technologies we use aren’t compatible which leads to knowledge gaps The tools we use don’t do a good job of explaining intent, which leads to a need of documentation We don’t have a systematic way of organizing the parts of our applications No one has answers to questions that are outside of our expertise It’s hard to communicate and estimate the work requirements Which leads to frustration and blockers And in the end to repetative and wasted work
- In the end you usually end up with something like this.
- Karri Saarinen was one of the keynote speakers at the conference, and he has a good quote that describes the problems. No matter how small or consistant the team, eventually different people who don’t have a shared understanding of what they’re doing and how, will create diverging experiences, which will amplify the problem and create a downward spiral of qualit and consistency.
- These are not new problems, but the growing complexity of projects and teams have amplified them and made people seek solutions to them. Design Systems are the lateste greatest thing, but they haven’t come from vacuum, but they draw from existing concepts that have been used for years.
- Usually when someone starts to develop an application or a site for a company and asks how it should look or function, someone hands them a brand manual. Usually prepared by brand teams or agencies, they have sometimes very detailed guidelines on how the brand should appear in different guidelines.
- These were a good startig point, they gave the basic principles needed to start designing, colors, type, images and so on. They usually also contain some voice and tone guidelines, to help in content editorial work. They usually define the attributes, or the personal characteristics of the brand, which can be used to help decide how the applications should feel. But they’re usually focused on print materials, and they while they go to great detail when it comes to them, in the context of UI and application design they aren’t very opinionated. They also don’t offer guidince on how Uis should be implemented, and the guidlines might not meet the requirements of Uis, like accessibility contrast ratios.
- Development teams started to address some of these shortcomings and started building style guides that are based on and extend the brand identity guidelines
- Style guides are writtin in code, so they are easy to understand and implement. They have guidelines on how and when to use the components, and as the components are written in functional code, their interaction is modelled. But they are hard to maintain, every change in both design and code has to be replicated in the style guide. the style guide is not the source of truth for either the development or design, and it’s especially disconnected from the design tools and processes. It’s not a project of itself, it doesn’t usually have a dedicated project team or resources, but it is by it’s nature an artifact that’s produced as a by-product
- Some years ago people started talking about pattern libraries. These usually differ from style guides, in that the components aren’t just representations in code, but the actual components that are used to build the applications. They discouple the development of the applications from the components, and the source of truth for the components lives in the pattern library.
- It is a product of it’s own right, with dedicated teams. it is always up to date, with no code specific maintenance requirements. The components are directly usable in the applications, unlike usually the case in style guides, which are more documentary. But they lack the big picture, being more focused on the code and it’s implementation. It’s still disconnected from the design process, just as styleguides, and it’s tightly coupled to the technology stack and product, making it hard to adapt to multiple products.
- So after this there is this new paradigm of design systems and everything is great? Not really
- All of these methods, including design systems are different takes on the same issues. Design systems usually include parts from all of these other methods, but they differ mostly in scope, scale and focus people: design systems are holistic in approach, they include not only devs and designers but the whole organization in it. requirements, resources and team members are sourced from all areas of organization, to avoid the problems of disconnection scope: scale means how much of the different aspects of building products the systems try to include. brand guidelines encompass the whole identity of the company, where as style guides focus on a narrower, digital aspect of it, and pattern libraries include usually only the components needed to build the products. design systems try to include all of these aspects, to ensure consisntancy across the whole experience focus: brand guidelines don’t go into too much detail about how the products should be build, where as style guides and pattern libraries are deeply focused in enabling their implementation. desing systems include similar level of focus and detail across it’s scope.
- One of the inspirations of these holistic, wide spanning design systems are brand manuals of organisations like nasas, ny transit authority, american airlines done in the 60’s. they produced huge manuals, that not only dictated how the brand should look, but how people interact with it across all of its’ touchpoints. Milan metro is one example, it’s identity and wayfinding system were designed by designer bob noorda and architect franco albini. they took this project together as a cross-functional team, and included people ranging from train drivers to upper management in the process
- They produced the usualy design items, like typefaces, visual styles, logos and such. but they also mapped the entire journey that people took in the metro stations. the picture left shows the different paths people take walking, which led to decisions on things like handrails, and non-slip floor materials in places. the picture on the right shows where a metro car will stop, and what are the sightlines of people inside it, which directed the placement of the information signage. This kind of focus on the detail while taking on the entire experience of using a subway is not possible by having multiple teams working on multiple projects, but requires a cross-functional team that involves the entire organization and that is ran systematically.
- This kind of approach is very interesting especially to large, digital companies, and the holistic way of design system thinking has started to gain traction and popularity through them. companies like google, vmware, salesforce, ibm have all invested in projects like these, because they see the value and understand the complexities of creating consistent, effective user experiences across their entire digital presence.
- So what makes a design system? What is important to these big corporations might not be so important to others, so it’s understandable that what is included in a design system varies a lot.
- In it’s core, design systems could be summed up like this. - parts are the guidelines & deliverables of the projects - practices are the shared languages and conventions of using and implementing those parts - this is done by people who are interconnected and collaborative - and they use all of thse to build cohesive products
- Design systems usually contain a founding level of agreed principles. these are used to build the visual appearance, the pattern library and sometimes the editorial style of the system. The output of the system is usable tools in the form of code, design files and a system for maintaining and documenting these.
- We did an interesting exercise in the workshop about defining what design system should be for your organization. in order to do so, you have to start from the bottom up. - first you must define what is the goal of the system, what products and experiences does it serve. - what kind of a team does it require and you can dedicate - how and where is it documented? These will dictate what the actual deliverables are and what must be offered to enable them.
- Here is an example filled out.
- The thing in implementing a new design system, and why new design systems usually fail, is that it requires people to adapt a new way of working. Taking the good ol’ practices people have been used to, giving the new tool to replace those. There is a lot that can, will and has went wrong with this step.
- A quick guide for figuring out where your design is at the moment. Doing systematic design doesn’t always require design system, but on scale that’s the direction we would be navigating towards.
- The thing in implementing a new design system, and why new design systems usually fail, is that it requires people to adapt a new way of working. Taking the good ol’ practices people have been used to, giving the new tool to replace those. There is a lot that can, will and has went wrong with this step.
- It might be that we have a set of internal tools that are dependant on design system through a platform. This is a graph from Nathan Curtis, founder of Eightshapes, design system consultancy company in United States. He talked a lot about system of systems, so whenever there is a design system in place, there will be different ways of using that. Let’s assume our system has HTML elements and CSS styles distributed to products. But our internal tools are dependent on a Drupal platform, so we can’t push the NPM package directly to the projects – the upgrade has to be done in centralized manner from our Drupal system admins for it to be reflected through to all Drupal products. On the other hand, our lighter Javascript based internet sites are happily consuming the system directly, getting the freshest updates every time the deployment is being made (assuming there’s no breaking changes in the design system). We find ourself in situation where we have two versions of the design system live. Source: https://medium.com/eightshapes-llc/design-systems-intermediaries-955ef18c9409
- It might be that our HTML/CSS design system is not enough for the teams going wild, so they start translating the design system to their respective technology stacks. A set of React components are being formed on top of the design system. And another set of Vue components. They are formed by enthusiastic team member on a product team, not in the design systems team. They now depend on a certain version, there’s no update cycle, and it’s out of the design system team’s reach. What should we do? Invite the enthusiastic team members to the team? Take React and Vue as our official Design System languages? Keep going like this as it’s a struggle to even keep the HTML version up to date? There are no right answers, it’s always situational. Source: Nathan Curtis, Consolidating Design Systems. https://medium.com/eightshapes-llc/design-systems-intermediaries-955ef18c9409
- Let’s face it – When you start the design system, it’s a long project to get anything out. You’d need to create or generalize a huge amount of reusable stuff, it will take months, and if you have a team commitment from all these three teams to use the system, what are they going to get? Let’s assume we have six months to put the design system together from scratch. What should we include in the first version? How do we make sure it’s a service that makes the life easier for product teams, not a burden?
- The thing in implementing a new design system, and why new design systems usually fail, is that it requires people to adapt a new way of working. Taking the good ol’ practices people have been used to, giving the new tool to replace those. There is a lot that can, will and has went wrong with this step. So to all the subscribers – what’s the minimum viable benefit we want the system to offer them?
- I think this is the part that essentially makes or breaks the system. Does it actually help to make the design and development so much easier it’s worth adopting? Or is it left alone as design documentation, deemed to have money sinked into it and wither? A wise man at Smartly said, the aim for design system is to help. So while putting colors into the system is good from the documentation perspective, making something like complex web form creation feel like a breeze through the design system is actually already helping in the design and development efforts. Make something worth adopting. Make something that takes the repeating problems easy, so that the teams can focus on the interesting problems.
- Let’s start breaking it down – if a consultancy company built a design system on it’s own, what would we benefit? ??? Usually company has a web presence, several internal tools and various communication channels they use. There might be a brand refreshment ongoing, and it could benefit from a collection of assets, communication tones, set of slidedecks and a bunch of other things to be kept up to date in centralized location. It should be carefully considered if there’s enough internal customers to warrant running a full-fledged design system in consultancy company, but design systems have some things to learn from.
- There are some consultancy companies with design system framework – a starting point for any design system that is built and customized for different client situation. These might include style guide generators, component library software, design tools and practices left flexible enough to be modified for different customer needs. We could use our company as piloting point, or pilot new things through trusted clients with specific contracts for this. This could prove to be beneficial approach if we went all in to the design systems – it includes a lot of boilerplate work but could certainly be an option if we were helping multiple clients working with design systems. Systems work the best when applied to different situations.
- To provide efficient design system consultancy to clients, consultancies have some models they can help with. One is through Design coaching and helping to establish Design leadership and cultural changes. Other is partnering in various parts such as accessibility, UX, UI design, React components, setting up libraries, and doing general design/development work. It’s important to note that it’s very difficult for consultants to own client’s design system. We can provide the service, but need the networks, contacts, commitment and organizational knowledge from the client. We on the other hand can provide the technical excellence, coaching, design, communication and analysis. Consultancies might be best help in design system partnership mode – a mode that connects us to dozens of client projects through the system alone.
- Scaling the design is hard. That’s why design systems are mostly talked in some of the biggest or fastest-moving companies in the world – the ones with either hundreds of designers or the ones moving so fast that the traditional ways can’t keep up. Design Systems Conference had speakers from AirBnB, Amazon and IBM – all which are heavily relying to design systems in their service creation. Google has been pioneering design system work with their material design library. Alibaba’s Ant design system is a good sign that this thing is as global as it gets, while the biggest things have been happening in the United States on this field. I should note, United States and United Kingdom both have design systems for country’s digital services.
- Finland doesn’t yet have country’s design system, but we have big players coming in to the design system game or being in the conversation. This is somewhat new thing in Finland and the current systems aren’t as comprehensive yet as in the US, as the scale is smaller. I should note that Elisa was behind Design Systems Conference through one of their lead designers, Mikko Häkkinen, acting as the lead organizer. It can start with one person with enough fire.
- So if design systems are happening as we speak, it boils down to this: Do we want to be the users of design systems or the creators of them? Do we want to help our clients on building single services using the system or help building their whole presence through design system? Of course both are important, but the design system work touches the organizational way of working and affects the way our clients build the services in whole different manner than any single service that’s being built. It’s a multi-discipline effort and requires strong partnership (as we can’t own the system). So where do we want to be?
- It’s hard to predict the future, but as DevOps has taken the technical world by a storm, it’s hard to not assume that the same methodology will rise in design as well. Once the design system has been initialized and published, the operative work starts. And it will be a long road ahead. We need a lot of just-in-time design work to keep the system responsive and useful. This is the shift from creating something new to maintaining and improving. Design Ops combines design with data, technology, organizational needs and business initiatives. We need to be present in all the levels of organization for the system to reach them.
- Another thing is data and analytics. Design systems should be enablers of experimentation and help us with decision making, not bind us down. So at first, we would like to have some data on how our system is adopted through the organization. Then we could go looking in to A/B testing with current components versus product-specific replacements. These could affect the expansion of the system or just a single component. If we were having several high-traffic well functioning services, each running their own analytics, how could we connect this data back to design system? Can we see what works? Can we provide
- Then there’s artificial intelligence. Structuring design in a way that it provides a library for AI to use, it limits the possible options just enough to consider that AI could be doing design decisions for us. Personalization is one thing where designers can’t control it all – thus giving data-assisted decision making for UI could provide better matches for people. One example is single-step vs multi-step forms – if a person prefers their forms multi-step and another as single-step, AI could handle serving the appropriate version if it knew they are aiming to do the same thing. Same with theming and other customizations. The boundaries of computational design are a hot topic, and constantly expanding – how machine learning could be used and benefit from design systems, the sky is the limit.
- To close it out, here’s one of AirBnB’s projects – it uses Optical Character Recognition, so it consumes hand-drawn design the same way as photo-to-doc apps consume text. It can generate layouts on a fly by using camera to recognize patterns, comparing them to the design system and pushing out pixel-perfect layout with a latency of milliseconds.
- So, where do we go from here? Towards more systematic design I hope!