Adagio
Design System
Adagio is a term for musical tempo between 66-72 Bpm which is also the average human heart rate. To play in this tempo means to play with grace and great expression.
Background
Accenture has hundreds if not thousands of websites internally to help 500,000 employees with varied skillsets from all over the world. These websites have very little consistency between them.
As a result users are not able to perform as well as they could if they didn’t have to adopt entirely new mental models for navigation and interaction. The designs were becoming hinderances in performance. From this a need for a design system was born.
Before Adagio, precursors to design systems lived in the form of UI kits that did not evolve or guide the users with usage and patterns.
Priority and Balance
It was a delicate balance to work on the product and design system at the same time and I was often presented with priority dilemmas.
Development
We began creating Adagio in tandem with the workbench and worked closely with the dev team which chose react to build the website. This would provide an overall responsive feel to the interface.
Problem
Inconsistent experiences across sites
The leadership saw value in making flexible but familiar interactions across the board.
For this, we needed a robust set of values patterns and extensive UI elements that evolves in tandem with the product(s)
A key challenge was to answer
Why do we need a systematic and expansive set of guidelines and components?
This only sounds like a rhetorical question to stakeholders in retrospect
1.It is highly scalable
Emphasising the scalability and applicability of design systems once built to a certain level of detail resonated with the stakeholders. The fact that this could be used as the basis of any new product that would be built in the future is one of the core reason that the stakeholders agreed.
2. The design/development turnaround times will reduce by a considerable margin
As design systems are built for this very purpose. I marched forward with the argument that having all the components laid out would help design less and fewer elements each time a new feature requirement came along.
3. It will cater to the real-time needs of a product if built in tandem.
As the project (Plays) progressed the design system faced real needs of elements to be designed and not synthetically needed because other systems had N number of elements.
Design system
UI Patterns
I extrapolated UI patterns from the design principle decisions made at the start of the project “Play Workbench”
Progressive Disclosure
Refrain from creating interactions that disorient the user from the initial point of focus. This also helps the user grasp information given to them in smaller more consumable pieces
Empty States
Use empty states to indicate system status when there is no content to be displayed. It could be because of several reasons like unsupported browsers, unexpected errors, no match for what’s searched. The objective is to disclose system status.
Onboarding
When welcoming a first time user onto the tool, context-setting is important to disclose objectives
Colour
Keeping black and white usage to a bare minimum
For users spending a large amount of time on interfaces for highly critical. Extremely high contrast is fatiguing. Hence, I chose shades lighter to black and darker than white for the layout and text.
Easy transitions to Dark mode
Colour mappings are set in both the design library and the codebase to facilitate a swift and easy transition between light and dark mode with little design and dev effort for current and future releases
UI Components
Rounded, but why?
We Imbibed ideology from the 2020 company-wide brand refresh which encourages change and human-centred bold moves. Currently, most business-focused websites have sharp edges and angular designs. We took the bold step of 16pt rounded edges to make the user feel that their ideas are safe with us and that they can trust the product with their invaluable ideas.
Constantly Iterating
All components stand the test of new features and functions. As soon as something breaks it is iterated upon to bring about improvements.
Built with purpose.
Each component is built out of a need which arises from a feature or page that needs to be created.
Problem: Button Sizing
This need came about when “edit” states were built for the Live embeds.
Solution: Setting width constraints
I redefined button widths based on optimal target area sizes with Fitts’ law in view.
Typography
The business model canvas challenged the type guidelines
I created a separate set of guidelines to accommodate the elements of the canvas to be able to consolidate all the information funnelling into the canvas form.
Maximizing legibility
The font sizes had to be dropped but I made sure that the type size never dropped under 12pts which would compromise legibility on screens with low resolution
Emphasising Metrics
Canvas is the business model on one page. The numbers are the most important part and for them to be available at a glance is of priority to investors trying to understand the sales/growth forecasts made. Hence extra emphasis was added to all metrics
Expressive Typography
Grids
The grids were constructed in cohesion with the development team who advised a grid structure which would provide maximum responsiveness on computer screens. This product is primarily built for computers since all work this critical is seldom taken to mobile devices.
Usage Principles
Avoid Overstimulation
Use elements with visual discretion
Why do we need these?
I found internally, even within a team of 3 that some patterns and visuals were being created which did not comply with our guiding principles and hence decided to start building a repository for future users of the system
How do I standardise the output?
Daily audits put in place to verify and correct any non-compliance to the principles.
Priority
Setting usage principles automatically took lower priority as features are being constructed and rolled out in agile sprints.
This section is expected to grow with the growth in use cases and adoption of the system
Impact and learnings
Impact
Project onboarding time has reduced from about 2 weeks to about 1.
With a system in place, there is significantly reduced effort towards explaining what kind of designs we need. The new members approach me with any doubts they might have and then most clarification is done through walkthroughs and how the design system is connected to the product
Learning
I learnt to push to prioritise working on the systematic creation of components before building shippable screens
I learnt to stand my ground that building the design system would require time being logged as tasks in the sprint. In times before the MVP had to be shipped it was a difficult task to ask for time and effort to be logged for the design system.
Impact
Adagio is the test bench for bringing the new brand guidelines to implementation
I learned from the effectiveness of the system that it is imperative to build for needs first. Because I work on a product in tandem with the design system elements/components always stand the test of real problems.
More Projects
Play Workbench
End-to-end customer journey design to simplify venture funding for consultants
Enable
Improving the experience of visually impaired test-takers using design thinking