A Final Year Project with Health Promotion Board
Data Access and Approval Dashboard
My Role
UX Designer, Project Manager
Project Timeframe
~ 2 months
Tools Used
Figma, inVision
My Impact
Worked as a sole UX designer, collaborating with developers and product owners. Successfully conducted the whole end-to-end UX process and delivered the product where HPB is currently utilising it in their daily workflow.
The Problem.
The Data Governance and Compliance department receives a large number of data requests submitted by users through PDF forms sent via email. This approach has demonstrated its resource-intensive nature and time-consuming tendencies in terms of request upkeep. Unfortunately, the team currently lacks a dedicated tool to systematically monitor request metrics such as volume, context, and status.
In light of this, the objective of this project is to establish an automated workflow for extracting data requests and integrating them into a business intelligence dashboard. The intended outcome is:
​
​
"To deliver a dashboard that not only presents but also succinctly summarises data and insights in a manner that is both user-friendly and operationally efficient."
The Overall UX Process.
User Interviews.
Prior to initiating the prototyping phase, a series of user interviews were conducted involving team members. The primary objective was to gain comprehensive insights into their daily workflows and to capture their perspectives on how the dashboard could effectively enhance their tasks.
Furthermore, an in-depth analysis was conducted on actual operational data. This exploration aimed to pinpoint the crucial elements to include in the dashboard. Employees also helped to rank data of the utmost importance they would need to see on the dashboard.
Meet Jessica, our user persona!
After conducting user interviews, Jessica, our user persona was created.
Jessica is a senior data officer with Health Promotion Board, representing her fellow colleagues in the department.
Mid-Fidelity Prototype.
Mid-fidelity prototypes were designed to capture the initial user requirements, including visualisations of how data was to be presented and what kind of data to include. These screens were utilised during usability testing to obtain users' feedback and suggestions.
Below are some mid-fidelity screens created.
%20Pop-Up.png)
First Round of Usability Testing.
Usability testing was conducted with end-users from the team using the mid-fidelity prototypes. The main aim was to get their thoughts regarding whether the dashboard meets their requirements and whether any improvements to the visualisations can be made.
Subsequently, insights from user interviews were grouped and synthesized, allowing for the uncovering of common themes being discussed.
Some important insights identified are summarised below.
What's good
-
Dashboard successfully captures requirements, showing useful visualisations and enhanced insights
-
Particularly liked the graphs shown on the overview page as they can see analytics clearly
-
The idea of having a further details page/pop-up is useful as data officers will be able to obtain more information of the request
What can be improved
-
Some information is not intuitive enough such as the listing of the most requested databases
-
Adding features to the dashboard such as flagging out requests with sensitive information
-
Allow users to set the threshold for average processing time to be deemed acceptable
-
Colour code when a data requested is sensitive
Style Guide.
Before moving on to the creation of high-fidelity prototypes, a comprehensive style guide was created to serve as a valuable resource for my design process and provide developers with clear and concise guidelines for implementation and utilization.
High Fidelity Prototype.
Incorporating the feedback from users, the project advanced to the development of high-fidelity prototypes. The screen below showcases a few of the final screens created and the main features of the dashboard.
1.0 Overview
Provides all the analytics a data officer would find useful in their workflow. It helps them in keeping track of the number of requests, and whether the team's processing time is acceptable. Toggles were included to allow a user to view the charts most relevant to them.
3.0 Further Details
Provides all the details related to a data request. The left side panel allows a data officer to obtain crucial information easily such as the date of request and processing time.
2.0 Internal & External Requests
Includes all the details related to internal and external data requests. The donut chart acts as a filter for the table below. Data officers can obtain details of data requests that require their attention, helping them to streamline their workflow.
4.0 Side Panel
Clicking on the hamburger icon reveals a side panel consisting of additional features including the amendment of processing time. The panel was also added for future use cases when HPB wants more features.
Feasibility check with developers.
As the developers started implementing the designs, they faced technical challenges. Thus, there were various aspects of the designs that could not be implemented. Certain design elements needed to be modified to align with these technical limitations.
In the initial stages, I conceptualized a pop-up modal containing tabs that allow users to access additional information for each data row, facilitating navigation between different sections. However, it posed technical challenges. Thus, I opted for a scrollable page layout to accommodate the necessary functionality.
Apart from the mentioned example, this situation occurred in various other instances. For example, many of the details can only be shown in a table format. Although a table format is the most ideal in this case, I made sure that the information presented was as intuitive and comprehensible as it could be - even though it may not be as aesthetically pleasing.
While this presented a significant hurdle, it offered a valuable lesson in adaptability and flexibility as a designer. A lot of times what we design may not be implementable or it would take up too much effort, thus there is a need to find a sweet spot between visual aesthetics and technical effort in the real world. Additionally, it also proved the importance of constant sync-ups with developers to be able to spot situations like these.
Round 2 of Usability Testing.
Following the implementation of features and functionalities by the developers, a second round of usability testing was conducted with the implemented dashboard. The main aim was to test whether the dashboard is easy to use for end users and if they can perform necessary tasks. Some of the test cases included:
-
Making changes to the average processing time
-
Finding out requests which require attention
-
Obtaining details of a particular request
Encouragingly, at this juncture, there were only minimal changes required such as the copy being used and minor colour adjustments.
​
It's important to highlight that the team maintained regular sync-ups with our product owner throughout the project's lifecycle. This collaborative approach led to multiple rounds of iterative changes, which were crucial in reaching the stage of user satisfaction when it came to usability testing.
Reflection & Key Takeaways.
Throughout my journey, I've acquired profound insights that improved me as a UIUX designer.
As previously mentioned, there were several instances where I needed to modify proposed designs to accommodate technical limitations. Thus, my role as a designer entails the responsibility of devising alternative solutions that are equally effective. This underscores the need to strike a balance between aesthetics and functionality in order to deliver a seamless user experience.
​
Furthermore, maintaining constant communication with developers is essential to promptly identify situations like these. Early recognition allows for timely resolution, preventing project delays and mitigating the wastage of efforts. This practice emphasizes the significance of a collaborative and proactive approach in project management.