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.
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
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
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
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
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
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
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
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: