⚡ Table of contents
- ⚡ Table of contents
- 👋🏼 Preface —
- 👥 Team
- 🛠️ Tools
- 🥽 Methods
- 🤘🏼 Intro —
- 📍 The product
- ⚠️ User need
- 👷🏼♂️ Prototype
- 🧰 Job to be done
- ✅ Feature goal
- 📋 Requirements
- ✍🏼 The design process —
- 👤 User persona development
- 📖 User stories/JTBDs
- 👨🏼💼 Stakeholder interviews
- II. The space —
- 🕵🏼 Competitor analysis
- 🗒️ Scenario mapping
- 🌊 User flows
- 📒 Sketching and ideation
- 🔬 Collaboration with the developer
- 📋 * List of display modes and example visualizations
- III. The solution —
- 🧰 Material design
- 📏 Wireframes
- 🔆 Compliance with WCAG AA
- 👥 Stakeholder review
- 📬 Final designs
- ⚙️ Interactive prototype
- 🧑🏼🔬 Hand off
- 👏🏼 Conclusion —
- 🌟 Best practices
- ⚡ Outcome
- 🗒️ What I would do differently…
👋🏼 Preface —
👥 Team
Aidan Myers, UI/UX Design Intern
Jacky James, UI/UX Design Lead
Sasa Schwartz, Front-end Developer
🛠️ Tools
Figma
Loom
Zeplin
Material Design
WCAG AA
🥽 Methods
User personas
Stakeholder interviews
User stories/JTBDs
Scenario mapping
Competitor analysis
User flows
🤘🏼 Intro —
📍 The product
Intelligent Assets is a no code, highly customizable IoT application for monitoring assets with various use cases like maintaining aircraft, monitoring railway crossings, reporting machine failures, and controlling microclimate environments.
⚠️ User need
Users are unable to visually indicate in a widget visualization on their dashboard when the value of key metric(s) in their query have gone out of bounds.
👷🏼♂️ Prototype
🧰 Job to be done
When I’m setting up a summary dashboard for my team, I want to create color-coded visualizations that indicate when our assets’ KPI’s are outside the optimal range, so anyone viewing the dashboard can immediately know which assets need maintenance.
✅ Feature goal
User can apply a threshold mapping to any type of widget visualization and select any type of data from their query and input threshold value(s) to display with a unique color and/or dynamic icon.
📋 Requirements
Official Requirements I. Threshold color settings
Definite requirements from the business, customer, and/or product owners. Must be met. |
Select which metric from their (which they created back in the “setup tab”) |
Add one or more individual threshold mappings (see next requirement for what is contained within a threshold mapping) |
For each individual threshold mapping user can:
1. Select a unique color
2. Type or select the corresponding value
2a. Permitted values will be dependent on the metric’s data type ([string,number,boolean]) |
User should be able to delete or remove any added mappings |
Official Requirements II. Threshold color settings
Same general requirements as above, except #3 is different.
Definite requirements from the business, customer, and/or product owners. Must be met. |
For each individual threshold mapping the user adds: |
a. Select a color |
b. Select an icon |
c. Type or select the corresponding value |
✍🏼 The design process —
👤 User persona development
From the body of UX research including user interviews, user personas, and stakeholder interviews, I gained insight into the behavior, motivations, and frustrations of our primary user.
📖 User stories/JTBDs
With a strong grasp on the primary user, I began to explore our customers use cases, the product requirements, and generate ideas about how the solution could be generalized to benefit the greater user base.
👨🏼💼 Stakeholder interviews
After preliminary research into the user, I met with my design lead to strategize the direction of the project to have effective impact on the end user.
Key insights about user needs
- Quickly and easily identify which assets need maintenance
- Highly customizable options to apply threshold mapping to
- any type of widget visualization
- select any type of data from their query
- display them with unique colors and/or dynamic icons.
- A feature that met their requirements while also being feasible for development.
II. The space —
🕵🏼 Competitor analysis
I utilized competitive benchmarking to better understand the user’s conceptual model of setting a threshold for data visualizations in adjacent software like Grafana, Google Data Studio, and Microsoft Excel.
🔑 Key question
“How would the user flow vary on the visualization that was being displayed and the data type that was selected in their query?”
Having display mode options helped me better communicate the impact that a threshold had.
Using a reference line and inputting 1 value, I was able to achieve many use cases on the two axes visualizations.
The numerical and text data types had the same steps with different operators.
🗒️ Scenario mapping
After defining the problem and exploring the current competitor solutions, I culminated these insights into user scenarios that framed the real life use cases of our users.
🌊 User flows
After exploring competing features, I began to map the flow of actions taken by a user to achieve the threshold mapping setting being applied on each of the visualization types.
🔑 Key question
“Could we make the same general UI design/layout/flow work for both the “dynamic icons” and “dynamic colors” settings?”
📒 Sketching and ideation
After using competitor’s tools, mapping out the scenario, mapping out the user flows, I began to sketch and generate ideas for the design of a settings panel in which the user would select their field, display mode, and input values.
First intuition —
Drawer with options in-panel and option of advanced settings with field, dynamic color, operators, input value, and optional text to display
After first round of feedback —
Pop over component with a field, display mode, input/select components, with option to add color and/or icon
Second iteration —
🔬 Collaboration with the developer
Collaborate to balance impact on UX, development feasibility, priority levels, and requirements scope asynchronously with Slack, Slack huddles, and Confluence.
Collaboration with the front end developer was key in selecting widget visualization components from plot.ly that had
- Feasible styling options
- Integrations with the current widget library
- Met user needs and most use cases
They also provided insight into the technical aspects of the feature, which informed the design process.
📋 * List of display modes and example visualizations
III. The solution —
🧰 Material design
We utilized the Material design system and guidelines to streamline the design patterns within the application. From the component specifications, and atomic design principles, I began to design a set of input components that would serve as building blocks in our designs.
🔑 Key question
What MUI components would work best here? Popovers for progressive disclosure of settings/inputs?
→ View a summary after applying the threshold mapping setting
→ Select a field from their query
→ Select a string, numerical, or boolean value from their query
→ Select a display mode for the visualization
📏 Wireframes
After defining display modes with the developer and creating a set of components for the different elements of our design, I began to utilize multiple components together to raise the fidelity of the design in aid of architecting the information and user flow.
→ Option for multi-select input
→ Sub-flow for string data types
→ Sub-flow for numerical data type
🔆 Compliance with WCAG AA
When designing color palettes for light and dark mode, it was important to consider not only use cases of our users but encouraging an accessible experience with suggested color palette.
To create an accessible color palette, our main goal was to select colors with contrast ratio that met the Web Content Accessibility Guidelines (WCAG) to ensure that the design is inclusive for all users.
- 4.5:1 for texts less than 19px
- 3:1 for text greater than 19 px.
The biggest challenge in designing the palettes for light and dark modes was the "yellow problem" or the difficulty with the contrast ratio between yellow and white that often does not meet the minimum requirements for accessibility.
👥 Stakeholder review
After the design team finalized the threshold mapping feature and created a prototype, the stakeholder review revealed some pain points in the current design.
The team needed to address concerns around the error state when a user deletes a metric that was used in a threshold mapping, as well as determining the best option for "null" or unselected items in string outputs. This feedback was incorporated in to the final designs.
📬 Final designs
Select a field User can select any query metric from their widget visualization
Select a display mode User can select from unique display modes for their visualization type that best fit their use cases
Numerical output → Thresholds If the selected metrics have numerical outputs, the user will define thresholds by entering number values.
String output → Value mapping If the selected metrics have string outputs, the user can select from a list of pre-defined values to map to a color/icon
⚙️ Interactive prototype
After finalizing unresolved questions with my design lead and developer, I began to prototype the user scenario that we defined earlier in the project. I used the prototype to demo functionality with the developer and provide insight for the sales engineers that would later be using the feature.
🧑🏼🔬 Hand off
When handing off a software feature from a designer to a developer, there are several requirements that I met to ensure a smooth transition and successful implementation.
First, I reviewed past hand offs that were made at the company to understand the general pattern. Then, I met with the developer to understand what questions, concerns, or needs that I could assist with in the hand off process. Further, with my notes from past hand offs and needs of the developer, in a Jira ticket, I was able to include these items:
- Zeplin - Zeplin was our primary tool for hand off, which provided the developer with organized final screens, annotations about functionality, and design specifications.
- A list of screens - for a naming convention in Zeplin, I followed BEM methodology, I designed a table detailing the block, sub block, element, modifiers, variants, descriptions, and images of each screen.
- Detailed documentation - product requirements, project summary, all relevant Jira tickets for the feature, the components and variants, table of the included copy, WCAG AA compliant color pairings for light/dark mode, wireframes, user flows, and all of the design questions and decisions we made throughout the project.
- Interactive prototype - to provide a clear demo about how the feature should look and function.
And once approved by my design lead, I let the developer know it was ready for development. ✨
👏🏼 Conclusion —
🌟 Best practices
⚡ Outcome
- Users can set thresholds to alert them when connected assets’ KPI have gone out of range within any visualization and data type and take necessary action faster.
- Thresholds can be set for numerical or string data of any asset and aggregated data field in their query.
- User can select from a variety of display modes intentionally engineered for the data type and the visualization of their query to fit best their real life use case.
🗒️ What I would do differently…
- Asked for feedback before it felt “ready” - As a designer, it is difficult to feel that a design is ever “ready”. If I had asked for feedback before it felt ready, not only would I have caught potential issues and ensured that the final product meets the needs of the target audience, but I would have been more improved steps in my individual design process.
- Provided more specificity about details I wanted feedback on - Rather than having my team absorb a lot of information in a small timeframe to provide their feedback, being more specific about the feedback I was looking for could have allowed my teammates to better provide actionable feedback that was more helpful in improving the final product.
- Been quicker to ask questions - As an intern, asking questions to my design lead about design strategy, the requirements, and feedback on my concept ideas more often, I think I could have designed quicker with less mistakes, saved time, and learned more from my teammates.
more work →
