Designing Dashboards for Design Systems
Project
Dashboard guild created to develop consistent dashboard guidance across the Sustainability Software organization
Role
Core UX Designer
Responsibilities
Evaluation, consolidation, and publishing for dashboard layout, header, and organization patterns
Sustainability Software builds and maintains its own subset design system called a Pattern Asset Library (PAL). It is based in IBMās Carbon Design System, but provides extended guidance specific to offerings within our business unit to promote consistency at our more granular level. A common pattern within our offerings, a consistent dashboarding experience is vital to optimizing the value our offerings provide. A dashboard guild was created within the PAL to drive this effort.
Challenge
Dashboards across our offerings have unique use cases with varying complexity. To solve for these use cases we should understand that one size does not fit all, and consider layout, content, style, configuration, and scalability ā a pattern that may work well in a simple dashboard may break in a more complex one.
Goal
The guildās objective is to build common dashboard design patterns and guidance across Sustainability Software to establish consistent experiences across IoT, Sterling, and Weather offerings.
Team
PAL Lead
Lead UX and Visual Designer for all PAL operations
3 Core UX Designers
(my role) Representation across all 3 design organizations
3 Content Designers
Representation across all 3 design organizations
4 Design Reviewers
Third party designers that provided feedback during our iteration cycles
Process
-
Phase 1: Evaluate
Evaluate existing dashboard design patterns and guidance across offerings.
-
Phase 2: Consolidate
Consolidate common design patterns and terminology to drive consistency that works across all brands.
-
Phase 3: Publish
Publish dashboard pattern guidance to the Sustainability Software PAL and contribute back to Carbon.
-
Phase 4: Adopt
Adopt dashboard patterns across Sustainability Software offerings with stakeholder support.
Evaluation
We started by evaluating the content models and terminology currently used across our products to describe different components of dashboards. We found inconsistencies such as some teams using ānotificationā while others use āalert,ā some using āwidgetā while some use ācard.ā
We then took a high-level look at existing dashboards across our organization. While there are similarities, there are quite a few differences regarding layout, spacing, and even colors and styles. This helped us start to understand all of the different elements and patterns weād need to explore.
We gathered screen shots from all products within our organization to evaluate all different patterns associated with dashboards. This included layouts, headers, CRUD, filtering, and organizing at the dashboard level, as well as widget-level functionality and widget types.
After organizing all of our screen shots in the previous Mural, we aggregated a list of all different possible guidance areas, and chose a subset to focus on for the duration of our guild.
My focus
Once our scope was narrowed, each core designer took on ownership of specific items from the list. My focus areas were grid and layout, page header, and organizing dashboards into views and sections.
Dashboard layout
Page header
Dashboard organization
Consolidation
I dove deeper into Mural and Sketch to begin the consolidation phase for my focus areas.
By color-mapping content areas on our existing headers, I identified some natural placement patterns that I could lean into as I worked through consolidation.
While we did diverge to work on our focus areas, the core design team met twice weekly to share progress, iterations, and feedback on each othersā work. Having representation across all product areas ensured our emerging patterns would meet each teamās needs.
We also held playbacks with the wider organization and our stakeholders every few weeks. We incorporated their feedback from each playback into the next iteration cycle.
Publishing
I drafted the guidance and documentation for my work in Box using markdown. This allowed for the content to easily plug in to our website and be formatted correctly.
After being reviewed by our content designers, the guidance was published to our team site, along with supplementary images I created for our product teams to reference.
I created symbols and component variations in Sketch for the pieces of my work that would require library elements. This was handed off to the PAL library owner for final review and publishing to our cloud library.
Outcome
š” Successfully designed solutions that solved for 80+% of our use cases and provided enablement to a team of ~150 designers
š£ Stakeholder buy-in drove adoption efforts
ā³ Working on the guild allowed me to keep my product team informed of our direction as we progressed. By the time the guidance was formally published, we were steps ahead of other teams in the adoption process.
āThis is impressive. Iām already slacking other leaders asking when Iām going to get this in product.ā
Personal takeaways
+
Gained more experience designing for and contributing to design systems
+
Gained familiarity with products outside of my organization
+
Formed relationships with designers across other product suites
+
Gained eminence through collaboration with designers and stakeholders
All UIs Ā© International Business Machines Corp. This material is not for redistribution or modification without consent from IBM.