Tasks

I was limited to 2-3 hours total to complete the exercise

1. Make a plan for how I would carry out providing design recommendations for displaying profit and loss while also figuring out where in the dashboard this new P&L component should fit.

2. Pull out specific insights that would inform design of the features and potential layout the dashboard could have, showing profit and loss in a way that would most favor a users experience.

3. Analyze my findings and design a few visual UI recommendations of the dash based on what I've learned.

4. Bonus: Provide a summary of what UX/UI skills or tools I used to arrive at my UI recommendations and how I would get stakeholders to buy in, see progress, QA, handoff, etc.

Plan Overview

1. Understand Profit and Loss through research to clarify component requirements

2. Break down current dashboard hierarchy, ask questions, develop hypotheses to test

3. Research competition and identify existing UI patterns

4. Iterate solutions, prototype solutions, check against UX heuristics, and test

5. Leverage competitive analysis and user research findings to acquire stakeholder buy-in

6. Prepare design and assets for design-to-developer handoff

Identify Component Requirements

The team has expressed that there should be a historical list showing date, shares, price, and total amount with total profit or loss as the main focal point.

I highlighted the elements to include on the component design.

Outline Current Dashboard Hierarchy

I visually blocked out the navigation and separated primary components from secondary and tertiary components to breakdown the hierarchy of the dashboard. I used this to identify opportunities for how I might include the new Profit and Loss component.

My questions for the team

Do we have existing data/research to support the current hierarchy?
We do but it's not concrete as a lot of the hierarchy and priority of the components was prioritized internally.

Do we have existing data/research that could inform where P&L component fits in the hierarchy of importance to users within these other key components?
We do not have any research around P&L nor do we have an idea of the priority it exists to the user. After discussion, the team decides that seeing a few hypotheses at play would allow the team to make these assumptions together.

Assumptions

‘NGN earned’ and ‘Total Balance’ should remain primary as both contain key performance information and calls to action

Hypotheses

Important to retain the un-cluttered feel
The new component should not need to “squeeze in” or cause the length of the page to increase significantly. Users want to quickly scan and digest the information.

Alter ‘Success Rate’
This component has significantly fewer elements and less complex data. Its accompanying data visual could be simplified to reduce the space it requires.

Change the location of ‘Messages’
‘Messages’ could be it’s own section in the left-side navigation or top navigation. It’s the only component not directly related to understanding performance.

Competitive Research

To stay within the 2-3 hour time limit for the exercise, I omitted this step.
This is an outline of my approach:

See how competitors are currently displaying P&L components

• Are they consistent?

• What structures for the P&L component might be most useful and familiar?

Learned UI vs. innovation

• Should we innovate or follow existing patterns?

• How can we keep it straightforward for our customers but offer something that stands out or makes it even easier?

Iterating Component Solutions

I began exploring data visualizations for the sample P&L data from the spreadsheet. Default charting tools did not provide a satisfactory representation of the message of the data - highlighting the loss.

I took a step back to work on simplifying the visual in a way that would feel cohesive with the other existing dashboard components.

Option 1 uses the visual styling provided in the dashboard sample and highlights the key loss amount while separating out changes in shares. Users can hover or click on segments of the visual to see details for the segment.

Option 2 highlights the key loss amount while separating out changes in shares but addresses accessibility issues with the current site styling. The darker gray text provides better contrast but the size of the font is still a concern.

Prototype 1

• Replaces Success Rate component with new Profit or Loss component

• Hypothesis: Profit and Loss offers more valuable information to users than the Success Rate and therefore should be prioritized if keeping the total number of components to a minimum is a requirement

Prototype 2

• Simplifies the display of Success Rate while enabling it to remain included on the dashboard

• Hypothesis: Profit and Loss contains more elements of data to display whereas Success Rate can be simplified

Prototype 3

• Replaces Messages with Success Rate

• Hypothesis: The Messages component is the only part of the dashboard that is not directly related to performance data and therefore could be moved to the left navigation without being missed by users

UX Heuristics - Evaluating Best Practices

UX heuristics help identify baseline performance and usability strategies for implementing new features. We can use them to help craft the experience prior to seeking user feedback.

I leverage these heuristics to ensure the use of best practices for new features and product designs prior to collecting performance data or feedback.

Descriptions from https://lawsofux.com/

What do we want to know?

• Did we build the right component?

• What information are users looking for? Can they find it?

• What questions to do they have? What steps would they take to answer those questions?

• How would users describe the purpose of the P&L component?

• Would they recommend Coine? Why or why not?

Test hypotheses through user research using prototypes

• Recommend recruiting users from existing user base

• Reduce amount of processing time so users can focus on providing feedback on the new component/changes

Analysis: Based on the feedback received, will the component will achieve business goals?

• Raise our retention users have when viewing their dashboard

• Provide an in-depth look at a company's financial performance.

Analysis: What changes, if any, should we make based on the feedback?

• Do the changes warrant additional research and testing?

• What, if any, additional insights were captured?

  • Future feature ideas

  • Experience enhancements

  • Confusion, friction, frustrations

Stakeholder buy-in

• Review prototype and user research findings

• Bucket all feedback in one of three categories: Blocking, test in a future iteration, non-blocking ideas

• Make necessary adjustments based on stakeholder feedback while remaining true to user needs and appropriate for scope and technical constraints

Design to Development Handoff

• Review designs with developer team, address questions and tradeoffs

• Make adjustments if needed to stay on track with deadlines but honor user and business goals

• Document key changes and behaviors for developers

• Breakdown with product and engineering: Create front and back end development tickets to implement design