I was hired on at Black Diamond and my first initial task was to start building a style guide. Upon using the application for the first time, I knew this was going to be a marathon project. There were, and still are, enormous challenges involved with building, implementing and maintaining any standardized styles or system. The product was in development long before any designers were added so there was a lot of clean up and the task of evangelizing design thinking.
As part of a newly formed, 4 person design team (2 Senior UX’rs, 1 Researcher and 1 Intern), I would soon be juggling this project with other upcoming product features and enhancements.
I had to get to know this application and see what was up. It was pretty messy.
There were multiple libraries being used simultaneously: Bootstrap, Kendo UI and custom. The application was converting from its predecessor “Blue Sky’ and there weren’t any designers involved for the first year of development. Most common UX processes were not followed, there was a lack of personas, large inconsistencies, no visual design etiquette or brand recognition.
All page types, layouts and components were printed out, put on a wall and categorized. This wall is our source for identifying which components to target and in what order. Our source of motivation so to speak!
I built a freshly styled UI Kit starting with styles and form controls based off the Atomic Design Methodology. Defining core elements such as colors became a challenge because Black Diamond did not have a brand identity. So I started some branding work and chose colors that would be the Black Diamond (Default). See branding project>
Black Diamond was originally built to allow massive amounts of user color customization based on the firm/company’s (users) logo. This made designing standard styles & components very difficult because a user could choose any color to change primary buttons, text links, headings, icons, labels and data visualizations. It would be practically impossible to develop any usability standards around components with that amount of customization.
User chooses any color possible...
And the result of poorly selected colors is illegible buttons, tabs and headings.
Control the UI using ‘Themes’ and limit the amount of components that could be colorized. To generate usable and efficient themes, we queried our current client (financial firm) data base for custom color usage and found certain patterns:
• Heavy usage of deep and dark colors in blue and green
• A noticeable percentage of firms that do not customize the interface
• The firms that made our company big $$$ DID customize their interface
Therefore my proposed solution is:
1) User can choose from a selection of predefined color themes. A UI preview of selected theme is shown on the right.
2) If “Use my own color” is chosen, the user can input one #color to colorize the UI and choose a greyscale palettes option that best matches their entered #color
While building the UI Kit Sketch file, I customized a Bootstrap library to test visual styles across browsers. It is a temporary reference for developers to find the states and micro-interactions until the individual component specs and documentation are complete. Plus, it has been a design playground for some side project exploration: Design Principles, About Experience Design, updated Product Landing Page.
The actual component library for Black Diamond is written in React.js. In fact, the entire application is in process of being rewritten in React. Therefore, the development and implementation of the library is moving slowly. The design team now has a dedicated developer focusing on the library. Together, we can closely scrutinize every components behavior, interactions and variations. (More to come on our process.)
Progress had been made defining our visual styles, core elements and form controls but the next big hurdle was fixing inconsistencies amongst page layouts & behaviors. Going back to the audit, we were able to establish these major page patterns: 1) Dashboard 2) Table 3) Chart & Table 4) Form 5) Split View: Right 6) Split View: Left.
These page types are the generic starting points for the design of the product. They were designed bland enough to be used in multiple scenarios across the platform and allow flexibility to handle a variety of workflows. Because the amount of agile teams outnumber the designers, these page types offer the ability for agile teams to solve simple business needs on their own. But still please let a designer know! :)
These page types are also being used as part of a conceptual “evolution” project. See Conceptual BD4 >
So we had a functional component library but were lacking guidelines on how and why they would be used to build solutions that really impacted our users. We have established common rules and behaviors that apply to certain components, patterns and page types but a ‘system’ or philosophy leaves us asking more brand related questions like: >
“What is the Black Diamond value?”
“How do we solve problems for our users?”
“Why are we different?”
“What separates us from the competition?”
We want to have a better understanding of these types of questions to further develop our design thinking approach to problem solving, workflows and user stories.
As mentioned, this is a marathon project. Right now the team consists of two people: a developer and myself. Together, we design, build and document and regularly gather the whole XD team together for some feedback. We have found this process to be successful for us:
1) Component Request - Why do we need this? What does it solve? Describe some brief functional requirements
2) Sketch It Out(on paper or in Sketch App :) - Gain a general understanding, design how it works, looks, the different variations, states and usages
3) Build it in React - Work alongside the developer. Find the gotchas, special occasions, complications and work through the interactions
4) Test/Feedback - Internal testing across all devices, look for bugs, get some feedback and iterate.
5) Document - After component is marked approved, write final documentation and spec it out
6) Implementation - If a brand new component, then it’s ready to use. If its replacing an old component, it is marked as UX Debt and requires an impact assessment and code refactoring.
Here are some examples of file structure and documentation:
Sketch files are built as webpages that will get placed into our style guide site.
And that's it! So far this process is working for us. Thanks for reading all the way through.