Scaling an Enterprise Design System
•Télécharger en tant que PPTX, PDF•
18 j'aime•2,881 vues
You'll learn: - How to create a unified design language for a complex organization. - How to use the most efficient processes and tools for maintaining the design system. - How to scale code and interaction patterns across platforms and products.
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Scaling an Enterprise Design System
Similaire à Scaling an Enterprise Design System (20)
Plus de uxpin
Plus de uxpin (20)
Dernier
Dernier (20)
Scaling an Enterprise Design System
- 1. Creating and Scaling an Enterprise Design System Brian McLaughlin Chief Experience Officer
- 2. Enterprise: Enterprise software is used to satisfy the needs of an organization rather than individual users. Such organizations would include businesses, schools, or governments. Wikipedia
- 3. WE ARE THE WAY BUSINESSES PAY AND GET PAID Our solutions make complex business payments simple, secure and seamless
- 4. Portsmouth NH Portland ME Providence RI Wilton CT Garden City NY New York NY Englewood Cliffs NJ Marlton NJ Herndon VA Morrisville NC Charlotte NC Alpharetta GA Toronto CAN Reading UK London UK Hertford UK Paris, FR Hainburg, DE Geneva, CH Zurich, CH Kosovo Israel Singapore Melbourne, AU Sydney, AU Across the Globe
- 5. 10,000+ Global Customers 1,600+ Employees Worldwide Award- Winning Technology & Patents Across the Globe
- 6. A Large Enterprise Line of Business Product Product Product Product Product Product Product Line of Business Product Product Product Product Product Line of Business Product Product Product Line of Business Product Product Product Product Product Line of Business Product Product Product Product Line of Business Product Product Product Product Line of Business Product Product Product Product Product Product Product Line of Business Product Product Product Product Product Product Line of Business Product Product Product Product Product
- 8. The Typical Enterprise Design Challenges • Disparate components across LOBs • Minimal documentation and specifications • Lack of communication between product teams LOB’s • Little-to-no UX testing • Lack of UX/D version control • Numerous design tools
- 9. 9
- 10. 10
- 11. 11
- 12. 12
- 13. 13
- 14. 14
- 15. 15
- 16. 16
- 17. 17
- 18. This was a successful, revenue-generating product.
- 19. MULTI- DISCIPLINE TEAM THE DESIGN SYSTEM IS < 2 YEARS OLD GREW TEAM BY 50+ IN 5 YEARS AWARD WINNING UX Since 2011
- 20. How we got to an award-winning team • Executive support • Executive presences • Fantastic work • “Punching above our weight” • A unified team of UX and UI Development • Positive customer and market reaction • Positive visible revenue increase
- 21. How did we get here • Executive support • Executive presences • Fantastic work • “Punching above our weight” • A unified team of UX and UI Development • Positive customer and market reaction • Positive visible revenue increase These are all great. And they are the things you would expect to hear about at a conference.
- 22. How did we get here • Executive support • Executive presences • Fantastic work • “Punching above our weight” • A unified team of UX and UI Development • Positive customer and market reaction • Positive visible revenue increase For an Enterprise it’s all about scale.
- 23. Getting to one… Date Picker File Upload Data Grid Form Elements Navigation Widgets
- 24. Getting to one… Bottomline’s Design System VISUAL DESIGN PROTOTYPE UX CONVERGENCE TEAM SPECIFICATIONS GLU
- 25. Convergence: The merging of distinct technologies, Industries, or devices into a unified whole. merriam-webster.com
- 26. • Mission and purpose – Think holistically to create ”One” – Communicate and partner with all product team disciplines • Team composition – UX designers with varying backgrounds – Senior UI development attendance • Culture – “Humility is not thinking less of yourself, it is thinking of yourself less.” – Respect for each other creates strong partnerships – Communication fosters clarity and efficiency UX Convergence Team
- 27. • Process – Establish a baseline design framework – Design and approval – Governance – Consistency – Maintenance • The finite details are needed but are not the goal UX Convergence Team
- 28. Design System Tools Adobe CS Interaction Adobe CS Interaction UXPin Interaction UXPin Interaction UXPin Interaction Atlassian Document Glu Design System Line of Business Solutions Design Prototype Document Develop UX Convergence Involvement
- 29. Visual Design
- 30. Visual Design • Design with requirements in mind • Establish a baseline to mitigate design churn • Use Photoshop for initial design and experimentation • Leverage UXPin as a design tool not just prototyping • Delegate a smaller, skilled group to govern design
- 31. Prototype
- 32. Prototype • Team library: global repository of “approved” components • High fidelity, branded interactive prototypes • Usability testing of workflow options and iterations • Detailed annotations illustrate functional requirements
- 33. Specifications
- 34. Specifications • Use design specs with UI Dev and QA but not everyone • You can only spec so much
- 35. GLU
- 36. GLU • Recognized as an internal brand • Multi-discipline governance team • Product integration capability • Rapid development • Multi-device capable • AA accessibility compliance • Able to be white-labeled
- 37. • Establish baseline framework • Governance • Foster a judicious and collaborative design culture • Company awareness of the design system • Institute a global design tool set • Implement single design system across all LOBs • Globally available assets at all points of the process • Constant review and maintenance Overall Design System Take-Aways
- 38. Results
Notes de l'éditeur
- Hello and welcome I am Brian McLaughlin and I am the Chief Experience Officer for Bottomline Technologies. Today I am going to talk about Creating and Scaling an Enterprise Design System. While this presentation is focused on Enterprise, this is not to say that enterprise and consumer some somehow completely different beasts. They are not. It is just that there are certain characteristics of dealing with the enterprise world that exaggerate some of the challenges that are shared by both consumer and enterprise. Rather than talking in sweeping generalization about a topic as broad as Creating and Scaling an Enterprise Design System, I am going to use what we have done at Bottomline Technologies as a case study with the hopes that you can take away some of what we did to apply it to your own situation.
- First, I have used the word “enterprise” a few times already, so lets look what I mean by “Enterprise”. This is pretty broad but rather than spending a lot of time defining these term lets just go with this definition for the next 60 minutes.
- I know you are wondering “who the heck is Bottomline Technologies… Simply put, We are the way businesses pay and get paid. Our solutions make complex business payments simple, secure and seamless.
- We are head quartered in lovely Portsmouth, NH with offices across the globe. I am not going to get into the details what our products and solutions but to give you an idea of our impact into the business community… (next slide)
- 10,000+ global customers. Keeping with the Enterprise theme, when I say “customers” these customers are banks, corporations, financial institutions, etc.
- OK – while we have a working definition of what an enterprise company is, this is what a typical enterprise company looks like from the inside. You have different lines of businesses. The different lines of business have various products that support the line of business. In some cases a line of business may share a product or parts of a product. Believe it or not, this type of structure can be very beneficial from a business perspective. …don’t worry we are not going to talk about that... But this type of organisation presents some very interesting challanges to creating and scaling great UX.
- OK now lets look at Bottomline Technologies as a use case of successfully creating enterprise UX. While the company was started in 1989, we are going to start in the year 2011 because that is when Bottomline Technologies decided to put it’s toe in the UX water.
- From the company’s start in 1989 until 2011, Bottomline was typical for a public company building business based solutions. The focus was on ensuring the growth of the business and that the plumbing worked for the products. From a UX perspective it meant: Disparate components across LOBs Minimal documentation and specifications Lack of communication between product teams LOB’s Little-to-no UX testing Lack of UX/D version control Numerous design tools And as it typical for a company focus on providing business solutions in which the plumbing works you get products that are like this (see next slide)
- I can not emphasis this enough. This product was working from a business perspective. It generated revenue. It had little/no competition. The focus was on ensuring the plumbing worked and continued to work…which is no small task for a solution like this. However business conditions are always changing. And what it took to be successfull in these business to business markets was changing. Bottomline Technologies had the forsight and appitite to change before being forced to. This brings us to 2016 (see next slide).
- Since Then 0-50 team members In 5 years The Multi-discipline team is made up of: Creatives UX research, design, and testing Ui development Native mobile The design system is ~2 year old
- Our ability to scale Our ability to move from ideation to delivery
- Largest impact came from… Thou shalt only have one date picker, one data grid, one widget presentation/management, one menu, etc, etc. No more building multiples of the same thing because people think that their needs are unique. As an a company that is the leader in B2B payments, there is more commonality than differences in what the end user’s needs are. So while one product group may think that somehow their data grids are unique, from an end user perspective the needs are the same. But our various controls and interactive patterns are not always straight forward. They can be complex. For example a date picker may need additional features such as the ability to quickly select the last 7 days / the last 2 weeks / the last 3 months / etc. And there is only 1 UI Development Architecture for everything. Pick a direction and go with it.
- This is an overview of what “Getting to one” looks like for us. And I am going to walk through each step.
- Remember one of the primary characterizes of larger organizations (enterprise and non-enterprise) is having multiple groups. An in many cases these multiple groups are solving the same problems. One of the most important things to ‘get to one’ is to ensure that everyone is on the same page. A convergence needs to take place. Most people are thinking about what tool and library to use not about the management and oversight of the entire process. Getting to One is not a tool. It is not a library. The tools and libraries are part of the final execution. It is a culture. It is a process. It is working with and for each other throughout the entire company.
- Here is what the Convergence Team is and does… Before we cover these bullet points, we need to talk about the secret behind the management of the convergence team A smaller group needs to own this The non-product designers need to be involve Not everyone gets a vote
- The “nuts & bolt” are need but not the goal. It is very easy to focus on all the execution details (file naming conventions, where things are stored, etc), but if these items dominate the Convergence Team’s time then the group has lost the plot. The focus needs to stay on creating “the 1”. This is not design by committee. A smaller group needs to own this Not everyone gets a vote The non-product designers need to be involve
- Once the Convergence team is up and running, you do need tools to actually deliver work. We, like pretty much every organization, have a process that goes from originating designs through products going live. What you are seeing here is what tools we use in which stage of the UX lifecycle. In 2011 we had a heavy reliance on Adobe products. This was a reflection of the team at the time and the team’s skillset at the time - as well as what interaction tools we thought were going to give us the biggest bang for the buck. Remember were were starting from zero and we did not go from zero to 50 people in one year. As the team grew, we brought one some fantastic UX people that were not well versed in the ways of Photoshop and/or illustrator. UXPin help naturalize ‘tools skills’.
- Discuss the baseline designs We needed to establish the visual language of our design system. Initial assets where designed in Photoshop. We needed to establish this visual design so that the focus could become the interaction design and not continue to tweak the aesthetic. Visual is minimal compared to interaction design We anticipate that we will redo the visual language every 3-4 years. This is a bit of a luxury as an enterprise software company. Plus we have a number of products that are white labeled. Though they are ultimately white-labeled, it is important to get this ‘right’ because customer are shown the Bottomline brand during the sales process. Creating the basic designs- baseline Show the complexity that we need to move away from Show Artboards in photoshop – Product Design Drive
- Team library- few owners of this. Create and maintain Interactive prototypes Usability testing and iteration Show Blank UI with a header, and drag in Forms, Buttons with a grid in the background: Research Center in Confluence:
- -Benefits of product and dev seeing a prototype -Communicate, communicate, communicate
- Lets take a look at some of what involved in the spec phase. Show Glu Checklist: What to get to one? Keep track of what you have and where it is in the process. This is our internal documentation system (Confluence) Interactive Guide: As you can see we are using UXPin to create an interactive guide to all of our design system elements. UX Guide:
- Show GLU site
- There is only 1 UI Development Architecture Glu Governance Broad education and communication of what Glu is and what Glu isn’t Establish a self guided training system - Glu Gun Requires either a dedicated team or use the open source model (we use the open source model) Show Glu Glu home page
- As you can see the majority of this is about ensuring there ‘is one’ and it is because there is one that we can scale.
- It’s about speed, value, consistency Employee Onboarding Faster, more efficient new hire assimilation Allows designers to focus on problem solving not component creation White labeling All Bottomline products have a consistent baseline brand For products that are white labeled, clients have a definitive guide illustrating areas that can be rebranded The deployment of new, legacy and acquisition products New products are ready-for-market faster The design system is used in full or in part to refresh legacy or acquired products Development teams use the same repository Multi-product integration We have several lines of business and many different products We have a common UX We can now combine products (or product elements) to create new offerings Full company adoption In nearly every product and development conversation, the phrase Glu is used The entire executive staff at Bottomline knows what Glu is Mention how you familiarize designers with the system. Formal trainings and walkthroughs? Would be interesting to explore how much faster, if you have an idea. Give people a tangible idea of improvement. Would be great to explain how you Glu to refresh legacy or acquired products. What does that retrofitting process actually look like? If you have a live example that demonstrates this, would be awesome to show. Show Results Paymode Testdrive: