.png)
Food for Thought: redesigning a dashboard for parents
Multi-Case Study: Designing a better dashboard format that provides parents
with essential information and creating sub-flows
JUN - JUL 2023 | PRODUCT DESIGNER | UX/UI
Food for Thought is an organization that focuses on connecting local restaurant businesses to elementary schools to provide healthy meals.
Our project scope was focused on redesigning a dashboard for parents and designing screens for the ordering of meals. We were working on the whole ordering flow which was the biggest challenge in this project, the dashboard for parents, and a few screens with changes in the signing-up flow.
This project was part of my internship at Springboard before graduating. I was given 4 weeks to complete the project, so during this short time, I made every effort to deliver the best possible results.
The key problem for me was to redesign user space and create a user flow. Finally, I developed subpages for the Account page, Voting page, Restaurant Voting user flow, redesigned Adding Children section in the Signing Up flow.
In the process of creating this product, I implemented these types of projects:
​
-
Sketches, Wireframes, User flows, Information Architecture
-
Prototypes, User-testing, and the Final Product.
I utilized pens, paper, and Figma during the product development's Design stage.
Introduction
My Role: I was one of two designers in charge of UX design and UI design. The completed dashboard for parents and the ordering flow is a combined effort between two designers, Food for Thought stakeholders, and Springboard's student engineer.
This is a multi-case study because working on this project included for me the investigation and implementation of solutions for different tasks within the project.
Thus, the following cases are included in this document:
1. Signing Up: Adding Children Section
2. The Parent’s Dashboard
3. Voting for the Restaurant
4. Ordering: Supportive Materials
1. Signing Up: Adding Children Section
Research
By the time I started working on this project, most of the basic flows had already been created. The Signing-up flow was also created. However, one of the tasks for the project was to refine and improve the third step of the Signing-up flow: Adding children.
​
This step allows parents to add their children's details to their accounts in order to easily place school lunch orders and track their status.
.png)
Original Signing-up flow
To achieve a qualitative result for this task, I have identified some goals:
1. Go through an existing Style guide.
2. Keep consistency in all UI elements that are used/added.
3. Follow Usability Heuristics and UI Principles and check their application in the current flow design.
Usability Heuristics & UI Principles Issues
The information I received from comparing current design solutions with the UI Principles and Usability Heuristics allowed me to identify the next problems in the current design:
-
The unpredictability of the next steps when adding the next child
-
Not all fields are assigned titles (values)
-
The "Add Child" button confuses the user because its title can be misunderstood
-
After clicking on the "Add Child" button, a card appears with information about the child, which is placed under the "Add Child" button
-
The selected colors for the progress bar do not contribute to the user's intuitive perception of the Signing-up process
This means that principles and heuristics such as Visual Hierarchy; Discoverability; Keep Users in Control; Reduce Cognitive Load; Clear Next Step / Recognition rather than Recall were not applied.
So the next goal for me was to redesign the step of adding children, taking into account the identified issues.
Ideation
Sketches & Wireframes
While researching current solutions, I recognized a solution idea that allows a parent to add a child in two clicks, technically the same as in the current design. But much more intuitive and user-friendly.
And... I have tried to visualize it:
After discussing the changes with the team, I provided the first version of the display of the changed pages:
.png)
However, the idea of using the UI card to display information about an added child seemed to really limit the amount of information it could contain. No doubt the user could then click on the card to view additional information or edit it. Also, the idea of using the UI card matched the consistency of the website design.
​
But, the question needed to be answered: is it possible to make viewing information about a child and editing it even more clear and simple?
Testing
The results of the Usability Test showed me that the iterations of this part of Signing-ip flow are not finished yet. And that also requires redesigning of some user flows on the website.
The main issues were:
-
Wrong choice of colors and buttons sizes
-
Reviewing information about children and adding new children are confusing for the user
Then I spent time doing a thorough review of the flows, the elements of which were consistent with the elements of the Signing-up flow.
I completely redesigned each user flow, thinking through edge cases, making rational decisions for each UI element, and designing a new format for each page.
My redesigned pages met all of the UI principles and edge cases:
.png)
.png)
2. The Parent's Dashboard
Research
One of the requirements for the project was to create a parent dashboard. The MVP version of the dashboard existed, but it was created just to exist.
So we began to explore possible and appropriate solutions for creating a parent dashboard.
MVP & User Stories
Using project manager’s requirements, affinity mapping synthesis, and the user's hat to make a main solution, I wrote the main user stories that served as the basis for the MVP of a parent dashboard:
1. The current user wants to edit info about themselves
2. The current user wants to add a child
3. The current user wants to edit info about a child
4. The current user wants to vote for the restaurant
5. The current user wants to order a dish
The parent dashboard menu was defined as the following:
-
Dashboard page
-
Votes page
-
Account page
-
Logout
Ideation
Sketches & Wireframes
We explored different ideas for dashboards that could meet the main goals of the platform and clearly navigate parents on the important steps to take for completing the main actions.
The main idea on which we settled was the relocation of the menu pages to the left side of the page so that the user could open the necessary section at any time.
Then I visualized our dashboard idea by creating wireframes. We created the first wireframe together for the Dashboard page, and then I tried to apply the same idea to the rest of the pages.
Interacting as a team, we performed several more iterations of the parent dashboard. During the implementations, we were faced with the need to look for another solution for the navigation menu, as the following difficulties appeared:
1. Due to the fact that we moved the menu pages to the left side of the page, the drop-down menu in the right corner of the page now contained only the Logout button.
2. It would be non-obvious and inconvenient for parents to navigate the platform from the left-side dashboard, because on some pages of the website, this dashboard would simply be hidden, and parents would not be able to continue interacting with it then.
After some iterations, the parent dashboard looked like this:
I was very skeptical about using the UI card as a way to display information about the child on the Account page. This was that user flow that required consistency on all screens associated with it.
However, I understood that choosing such a design solution would not be successful in edge cases:
1. The use of the UI card does not allow sufficient use of white space. Thus, the information on it looks very compressed.
2. The child's name, school, or class name may be too long. How then will the borders of the UI card change as well as the borders of the section? I didn't have an answer to these questions.
3. The display format is deceptive because the user may intuitively try to click on the cards, thinking they are clickable and attempt to edit the information.
However, for editing the information, the user needs to take an additional step, firstly opening a page with detailed information about the children. And already on this page, the user will need to click on the desired card again to edit the information about the child. That's so long!
At this point, I didn't make any more changes to the design. Instead, I prepared Usability Testing Script to make all the changes after receiving the results.
Testing
The results of the Usability Test confirmed my assumptions. Users were really confused by the format for displaying information about children.
Then I decided to completely redesign the Account page. The solution was very simple, although at the same time it was obvious: it was decided to place all the important sections in tabs and allow to the user just switch between them:
3. Voting for the Restaurant
Research
Another requirement for the project was to create a Voting for the Restaurant user flow.
Springboard student engineer implemented the “Vote for” button on the Restaurant page, however the whole voting flow didn’t match the Usability Heuristics & UI Principles. It just wasn't there.
Original Voting for solution
Based on the number of votes this function allows a particular school to select a particular restaurant that can deliver school lunches during a certain period. In our case, designing this function required a design of the whole user flow.
MVP & User Stories
As in the case of working on a parent dashboard, so here, using the project manager’s requirements and the user's hat, I wrote the main user stories that served as the basis for the MVP of the voting flow:
1. The current user wants to vote for the restaurant
2. The current user wants to see the list of restaurants they voted for
However, here the task was complicated by the fact that the parent could not vote on his own. They had to vote for one of their children, depending on which of the children liked this restaurant.
The significance to vote for children was explained by the fact that it was important for the school to associate the vote with a particular child to have information about the preferences of students.
Another problem was that the design of the voting section is significantly different when the parent has two or more children or when the parent has only one child.
Ideation
Sketches & Wireframes
At this stage, a fairly large number of options for the voting section were created and iterated. But first things first.
First of all, we needed to define the core functionality for the Votes page on the parent dashboard. As I mentioned before, it became clear for us that the user should be able to vote for a restaurant and see the list of restaurants they voted for.
So I tried to draw subpages for the Votes page:
Once there was no issue with the sketches, I moved on to the next step: creating high-fidelity designs in Figma.
Votes page: Empty State
Restaurants page (going to vote)
Voting for the Restaurant
Votes page: Filled state
When I got visible results, the discussion of the nuances in our team began with renewed energy :)
Additional requirements were:
1. The user should not be able to vote directly from the list of restaurants page. Because in this case, they will not be able to choose for which child they vote. On the restaurant list page, the user can only see how many votes a particular restaurant has received.
2. The user can vote for the restaurant in two ways: a) go to their dashboard, then open the Votes page, and click Go to Vote; b) immediately open the Restaurants page (that is more intuitive).
3. It is necessary that on the page of their votes, the user can see the number of their votes and not the total number of votes of all users.
Based on this information, it was clear that I needed to consider the following design changes:
-
In order to prevent the user from wanting to vote for a restaurant directly on the list page, it is necessary to make the visual style of the voting icon inactive.
-
For a clear understanding of how many votes the user has for the restaurant, it is necessary to partially change the design on that page.
Updated Restaurant page_inactive vote for icons
​After making the main changes, I focused on finding the most successful solution for the voting section.
Voting Section: Iterations
However, it was important to associate the child with a specific vote:
.png)
Updated Voting Section
I'm sure the iteration above could be the most successful for this flow because it meets all the necessary requirements:
-
The voting section takes up very little space
-
Each voice is associated with a child, so the school receives the necessary information about preferences.
-
A parent can see at any time which children they have voted for by clicking on the drop-down menu.
-
The design of the section does not change even if the parent has only 1 child
However, I was faced with the limited abilities of an engineer who emphasized that she was not yet able to implement such a solution :(
Then I decided to conduct usability testing on the original solution and provide the final design after testing.
Testing
For the Usability Test I used the solution that the engineer suggested to me. I just corrected the visuals a bit.
The results of the Usability Test showed that it is not clear to users what the voting section is for and how voting is carried out.
​
So, it was concluded that creating an independent voting section is necessary.
Independent Voting Section
This option is successful from most points of view:
1. The section occupies its dedicated space within the web page.
2. The ample white space accommodates all the necessary information for parents about the voting process without appearing crowded.
3. Sufficient space allows for consideration of all edge cases.
At the same time, the question remains unresolved:
​
? How to use so much space if the parent only has 1 child?
Updated Restaurant Info page
I have an idea: we can either use the latest iteration of the solution (Multiple choice in the dropdown menu) or try to redesign the independent voting section.
Restaurant Info page_Voting Section: Version 1
Restaurant Info page_Voting Section: Version 2
Updated Votes page_Empty State
Updated Votes page_Filled State
4. Ordering Flow: Supportive Materials
Research
Before creating wireframes, another designer and I worked on this user flow together. Therefore, in this section, I also provide the materials that supported our work.
For this task we needed to create a whole ordering flow from scratch.
The main requirements are:
1. Implement a notification system that allows parents to receive information about placing an order.
2. Enable the ability to place an order for all children simultaneously, even if they attend different schools.
3. Provide the option to place an order for the entire period or make additional orders later.
4. Allow the selection of specific dishes to apply to multiple days within the order period.
5. Offer a clear and accessible view of the order summary based on the requirements above.
6. Integrate a donation feature, enabling users to support children who may need assistance affording school lunch.
7. Include PayPal and Stripe as available payment methods.
The 2nd requirement in the list above seemed to us the most difficult to implement. So after spending a long time in discussion with the project manager, we set out to iterate the order placement screen.
Ideation
Sitemap & User Flows
From the project's inception, we faced multiple requirements, including a redesign of the school and restaurant dashboards to align with the ordering flow. To tackle these challenges, I delved into investigating all the platform's interactions and connections.
First of all, I built a sitemap:
At this stage, I tried to understand the overall picture of the site, to see the main interactions and inaccuracies between them. And also to see what will help make transitions for new user flows easier and more seamless.
Once it became clear to me where the new user flows would be located on the website, I created flow charts for the ordering and voting flows to see more details.
Keeping in mind the requirement to redesign all dashboards, I created a detailed schedule lunch delivery flow for the school account.
The purpose of creating this flow was to see all the requests that the school sends to the restaurant and try to compose logical interaction of requests and responses.
After that, I tried to synchronize all possible requests and responses for all dashboards. To do this, I created text areas for each of the dashboards and tried to build a logical connection for each of the requests.
Attempts to sync all requests
During this stage, I encountered numerous questions, and I unintentionally began working on flows that were beyond my scope. Additionally, our team faced a tight deadline for implementing our assigned requirements. As a result, the project manager decided to remove our responsibility for redesigning the school and restaurant dashboards.
So I shifted my focus to creating and iterating screens for the ordering flow.
Sketches
As I mentioned before, the requirement to develop the function to place an order at the same time for all children, even if they study in different schools, was pretty challenging for us as designers.
My sketch idea for the most challenging requirement helped the second designer turn it into the best possible solution.
At first, she suggested the application of filters, which would help to easily switch between orders. Then the ideal solution became the use of tabs, which was the second iteration of her previous idea.
Sketch: Yaowei's idea of the use tabs for the Ordering flow
Testing
When I asked users to go through tasks in the Usability Test, they took the Ordering flow with great interest and enthusiasm. However, a number of shortcomings were identified, e.g., non-intuitive use of the “Order completed” button.
My solution to the problem with the "Order completed" button was to add the Status bar to the Notification section on the parent dashboard. Thus, the whole process of placing an order/orders for the entire period would look like this:
However, implementation required more detailed research of the nuances, so the final solution was provided by Yaowei, who worked closely on the Ordering flow:
Other minor issues will be solved in later versions of the website since we worked on the MVP.
Conclusion
Working in a team on this project was a truly enriching experience, providing me with valuable insights and knowledge.
First of all, we worked on a business project for stakeholders, and this required the most careful approach to learning the requirements. However, in order to understand the requirements, it was necessary to learn the goals of the project and its entirety. This could best be done only in discussions with the project manager and team members.
Secondly, teamwork opened up new areas for self-development. I really started to communicate better with people, because I realized that the surest way to learn or understand something is to ask or tell my thoughts. This project helped me become more confident.
In addition, I experienced in practice which amazing way teamwork enriches the process of creating a product. Because each member of the team puts their strengths into this process. And while every other team member can learn from each other. It's awesome!
This project was also very important to me because:
1. I could analyze the user flows for UI Principles and Usability Heuristics to apply.
2. Most of the work on the project was devoted to brainstorming, iteration, and finding the best solutions. I have not yet had such an extensive experience in this.
Undoubtedly, I was pleased with the results of my work. If I had more time, I would achieve better results.
To see the final prototype click here
