The software is starting from scratch and previous design documents. The client wants a dashboard built for his application which will streamline accounting practices.

We conducted an interview with the client in two steps - the first to listen to to the clients needs and wants for the applications dashboard.
‍
The second step was to show the client competitive designs of dashboards in existing programs to discern preferences of layout, space, and utility.

We compiled the information we had gotten from the client and created a chart to prioritize our findings.

The client's most important need was to see at a glance all recent and ongoing projects in one space. This is followed in priority by a clear and readable space for ASU updates - accounting memos put out by international organizations.

Next in the heirachy of information are software alerts, and a group messaging service.

Of lowest buildable priority are a time management widget, user permissions and tracking, and customizable settings.

With hierarchy of information in mind, I drafted a sketch of the application dashboard.

Using the methodology of the 'F'-shaped reading pattern, the collection of Current Projects sits at the highest level of visual hierarchy.

Next in priority sits the ASU's, followed by messages. Team Tasks and working timeline are visible, but at lowest priority.

The client wanted a modular-type dashboard - with the ability to reorder components, and add componentrs as the program grows.

We built each component as a card, using research from Google's Material Design documentation as well as competitive research.

For the 'Current Projects' cards, I settled on five pieces of information: title, folder, creation date, editor identification, and completion status.

I learned that font, color, and text size will make a huge difference in perception of information here. As the client pointed out, creation date is not as important as the title, and that should be reflected in the visual heirachy.

We created a mockup of the dashboard using our components.

After presentation with the client and developer, we gained some key feedback.

1. Current projects should be given even more priority than allowed - they are the central and core feature of the application.

2. Less rigidity with the components - allow each to take up space

3. Indications of completion status for projects and message boards - needs to be obvious

Our UI kit was based on two principles the client outlined for the project - professional and reserved.

We wanted to avoid the bright, garish green assosicatedd with money and financial systems. We instead blended a green with a professional blue to create a soothing, refined teal that would be our primary color.

Looking across the color chart, a refined ochre for our accent reflects the monetary gold while staying subltle.

The fonts are open source and readable - softer than the traditional serifs while staying away from adornment.

Using the feedback we had gathered, we built the components for the hi-fi mockup.

The most important addition to the components were call to action buttons - interactivity is a must in this program.

Use of primary and alert colors highlight the most important information - project status - and interactivity.

Having addressed all the feedback from the last dashboard, we built our final screen.

1. The current projects are highly visually prioritized, sortable, and interactable.

2. The ASU and FASB alerts are interactable, sortable, and take advantage modular sizing.

3. Color and font size are used according to the UI Kit to give visual weight and clarity to the information.

At the end of the design sprint, I learned a few things:

1. Sketches should be done live with the client - listen to their feedback and draw many iterations till they feel comfortable.
‍
2. Clients often know what they want, but do not know how to visualize it. That is why we are designers.

3. Don't be afraid to deprioritize work - we dropped the team tracking and messaging components from the final deliverable. Using the MoSCoW priority chart we had constructed, we realized only a couple components were essential to hand to the developer.