Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Implementing a Design System in a Small Team by SnapTravel

This session will provide a blueprint for how a team of 2 Designers and 3 Frontend engineers can work together, in a lean way, to build and implement a design system within 6 months while still working on other important company initiatives/features.

  • Login to see the comments

Implementing a Design System in a Small Team by SnapTravel

  1. 1. Implementing a Design System in a Small Team by SnapTravel
  2. 2. Join 40,000+ Product Managers on Free Resources Discover great job opportunities Job Portal
  3. 3. CERTIFICATES Your Product Management Certificate Path Product Leadership Certificate™ Full Stack Product Management Certificate™ Product Management Certificate™ 20 HOURS40 HOURS40 HOURS
  4. 4. Corporate Training Level up your team’s Product Management skills
  5. 5. Building and Implementing a Design System in a small team T O N I G H T ’ S S P E A K E R Mostafa Elhefnawy Jake Janosik
  6. 6. 6 Design systems are collections of elements with interconnections and rules supporting them in order to drive purpose.
  7. 7. 7 By utilizing a collection of repeatable components and a set of rules to use them, teams are able to change the pace of creation and innovation.
  8. 8. Purpose: Create a visual cue or text to indicate an action Interconnection & Rule: 3 levels to indicate importance and hierarchy Elements: Colour, contents and indicator
  9. 9. Only for purchase path Main action on the page Links and actions on a page High Emphasis Low Emphasis Purpose: Create a visual cue or text to indicate an action Interconnection & Rule: 3 levels to indicate importance and hierarchy Elements: Colour, contents and indicator
  10. 10. A design system brings a team together around a universal language. Provides teams the time to solve more significant problems, and the ability for teams to communicate more precisely. Why make one? ● Bring order to chaos ● Improve the user experience ● Improve workflow efficiency ● Allow you to iterate faster ● Faster standardized employee onboarding ● Lower the cost of long-term maintenance
  11. 11. Why do we need a design system?
  12. 12. Without a design system... Every new project and every new hire increases chaos in the process and slows down velocity.
  13. 13. That leads to... ● Software development process becomes gradually slower and slower ● The users’ experience suffers from growing inconsistencies.
  14. 14. Do you answer no to some of these questions? ● Are we always happy with the speed of product development? ● Do our interfaces share the same design patterns, colors, typography and other styles? ● Do we always have enough time to deliver a quality product to meet KPIs/OKRs? ● How much time and money do we spend on redundant design or code tasks? ● How much time and money do we spend cleaning up design or technical debt?
  15. 15. Let's take a look at an example Every single one uses different styling, CSS classes, and JSS components. Purpose: These all seem to have similar jobs? Interconnection & Rule: Different structure, layout, and no consistency Elements: Each is custom use of elements
  16. 16. Every unnecessary colour slows us down, forcing confusion, hard coding and overrides everywhere. No order or purpose to the choices made. All the versions of gray (20+) 9 versions of green OR what was happening with colours
  17. 17. But, we are not alone.
  18. 18. To overcome these challenges thousands of companies are investing in Design Systems
  19. 19. Getting buy- in to start this ● Figure out who you need buy-in from ● Involve allies and emphasize design system co- ownership ● Focus on the value proposition ● Be prepared for questions and push back
  20. 20. Getting buy-in to start this ● Figure out who you need buy-in from This varies from company to company. It will probably be a CEO, a head of product, or a head of engineering. In our case, it was the CTO
  21. 21. Getting buy-in to start this ● Involve allies and emphasize design system co- ownership. Don’t go to war on your own. Build a combined initiative with the front-end/engineering team, and your chances of getting executive buy-in will be much higher. It’s not just a set of beautiful components built in your preferred design program, but a set of design and coding principles and UI components ready to be used in your products. So for them, it’s as important as it is for you.
  22. 22. Getting buy-in to start this ● Focus on the value proposition Scalability: you’ll be more prepared to scale both the design and front-end areas in the future. This allows you to move faster. Creativity: by building a repository of rules and components, you’ll spend less time on pixels, which gives you more time to redesign your customers’ experience and come up with disruptive solutions. Themes: you will prepare your products for themes! This is especially important if you’re planning to build white-label solutions or products for third-parties. User Learning-curve: once your products are consistent, their interfaces will be more predictable, leading to a reduced learning curve across products. Employee Onboarding: you’ll get the most out of every new hire, due to faster standardized onboarding with the design system. Updates: it will be faster and easier to update your products’ UI.
  23. 23. Getting buy- in to start this Be prepared for questions and push back ● How much time will it take to implement? ● Will it have an initial negative impact on your already arranged deliveries? ● How are you planning on rolling this out? ● What if it lowers our funnel conversion? ● Are we going to change it all again in a couple of years? ● Will this slow down the team as they learn a new system?
  24. 24. Mindset when starting
  25. 25. ● Moving fast but not reckless ● Not always 100%, taking risks for rewards + learnings ● This is a living thing not a piece of art to hang on the wall How did we build this in 6 months
  26. 26. Prepare to move fast and test Approach this like any other project, it is going to have fails, learnings, and iterations.
  27. 27. Ok, now where to start
  28. 28. Audit and understand The first step is to audit and understand what you currently have designed. ● Ask what components are doing the same job? ● What can work as one? ● Why do we have different components? ● What are we missing?
  29. 29. Components: ● Cards ● Lists ● Tables ● Navigation ● Headers ● Tabs ● Footer ● Forms ● Error cards ● Drawers ● Overlays UI atoms + Elements: ● Palette ● Buttons ● Inputs fields ● Radio buttons ● Check boxes ● Search bar ● Tooltips ● Typography ○ Headers ○ Paragraph ○ Lists ○ Labels ○ Links ● Icons ● Dropdowns ● Progress indicators ● Loaders ● Alerts ● Dividers Templates: ● List view ● Map view ● Hotel page ● Sub-pages ● Error pages Creating a catalog
  30. 30. Leverage a base framework (material) ● We don't need to spend time building the basics and the base of our system. ● Don't be afraid to leverage existing frameworks or libraries to assist you. ● We took advantage of a react material design library. Material is the base of a lot of common apps and still gives the freedom to be your own. Others who have used this: ● Airbnb ● Lyft ● Momondo ● Simple Habit ● Eventbrite ● Evernote ● Uber (until 2018)
  31. 31. Design language (Building blocks) Rules and Documentation Review and Governance Colour Palette Typography Scale Grid Definition Icons and Assets Spacing Structure Design Library Templates Elements Components Modules Design Principles Implementation Guidelines Voice and Tone
  32. 32. Building a system for spacing, grids and colour ranges allows things to be consistent and organized. Design becomes faster and more organized while development spends less time measuring and creating. Grids, Spaces, Colours and Type
  33. 33. Rebuild the base layers We first created a system for navigation and page templates. This gave the team the framework to start building on.
  34. 34. Using the base for Material we were able to customize the small pieces to make them uniquely ours. UI Elements
  35. 35. Elements are combined based a purpose using the grids & spacing system, this give us the components we use. All of this is constructed so that modifying copy, states and sizes are done without breaking our rules. Elements into Components
  36. 36. Understand how the component will work across devices, scenarios, states that you would need based on the purpose of the component. Versions & states
  37. 37. Now we build With these component and elements it makes it easy to construct pages and flows based on our needs.
  38. 38. Implementation guidelines
  39. 39. Some of the final product
  40. 40. Review process & maintaining the system We have collaborative design reviews and discuss items as a team. During this, we look at the experience, its needs and how the purpose fits into existing components.
  41. 41. Ability to test fast Some of the first tests we did were to help find the direction for the palette and design system. We did a CTA test to help find the primary action colour.
  42. 42. Getting it built 🛠
  43. 43. ● What are your code bad practices? ○ Containers vs components ● What could be done better? (more functional, reusability) ○ Reusability: React is component-based to reuse those components, but we don’t ○ More functional components (hooks) ● How much effort it takes? Step 1: Evaluate the current state of your app
  44. 44. ● Sit down and hear them out! ● Discuss with the design team what components they need built: ○ Layouts ○ Components ○ Elements ○ They might have some suggestion ● Make sure we are all on the same page ○ Px or Rem! ○ Color pallette ○ Grid size and spacing Step 2: Figure out design requirements
  45. 45. ● No duplicate components ● Better/More test coverage ● Ensure components are SSR (Server-Side Rendering) compatible ● Theming ● Ability for other teams to easily implement this system (NPM package) ● Backward Compatibility IE11, iOS 9, Android 5 Step 3: Discuss with the engineering team the technical requirements
  46. 46. A. Build it from scratch B. Adopt a good component library and tweak it to your needs ElementsUI pieces Components Templates Step 4: Make a call
  47. 47. We are not reinventing basic elements to create standard patterns. ● It’s a react library ● Well tested ● Good documentation ● It has the components that we need. ● Surrounded by a huge community Choosing B saves you a lot more time!
  48. 48. ● Are we separating mobile vs desktop? ● Are we going to release it all at once or page by page? ● Are we going to A/B test it? ● Do we want to roll it out to all users? (or 10%, 40%, 60%, 100%) Consider all of these and figure out what is best for your team and situation. Step 5: Figure out how you will roll it out
  49. 49. ● Configure the design system library itself (ssr functionality, theme, folder structure) ● How many engineers do you have to dedicate? ● Set-up a/b test experiment env ● You might want to: ○ Use Storybook to independently test and document our components ○ Use dynamic import eg: react-loadable to prevent a bundle increase ○ Implement the components in a reusable manner Step 6: Build it
  50. 50. With our theme file we are able to make fast global changes to components and UI
  51. 51. Storybook: Our source of truth
  52. 52. THANK YOU! Q+A We’re hiring! ● QA Engineer ● Data Analyst ● Product Manager ● Product Designer
  53. 53. Part-time Product Management Training Courses and Corporate Training