Designing a dashboard from scratch

“Pharos is a web-based evidence generation tool and research framework that uses its integrated data streaming and AI capabilities to efficiently capture online patient experience data, and enables teams to quickly discover evidence when they need it.” (Semalytix)

As the sole designer at Semalytix I provided UX insights and UI prototypes during the development of the company’s lead product- a data analytics dashboard called Pharos.

My day to day work often involved multifaceted interactions with all levels of the company: from senior management, getting sign-off on high-level features, to back-end engineers, sanity checking concept functionality.

Through my close collaboration with the frontend team I developed a better understanding of developer capacities and how to balance them with other stakeholders’ requirements. I feel like this empathy for customers and co-workers, and regular collaboration has made me well suited to complex design tasks.

User focus

At Semalytix we were always exploring avenues to open up the possibilities of our backend analysers to users. The frontend was obviously the most important channel through which users could explore the data and gather insights. However, based on user feedback, stakeholders requested some exploratory design work for a feature that would allow users to submit their questions and queries to in-company experts to manually produce reports. This was called ‘knowledge extraction’ during the exploratory phase.

Case study - Creating an in-platform framework for user generated queries

My first task was to imagine myself as a user. What steps would I take? What would count as a successful use of the platform? When and where should I be able to make use of the query system? Etc.

After gathering feedback from users and consulting my colleagues in the product development team I put together a flowchart that would guide the design process.

With this flow in mind, I created mockups of the main landing page with the query function located in the top right: unobtrusive for regular workflow but visible enough to be easily found. Being in the header meant that it would be accessible at all times, including inside the report dashboard.

Next up was designing the interaction for creating the query itself. This took the form of a simple form, in line with others found on the platform. Users would be able to see their submitted queries in their Preferences tab. This feature was a really useful exercise in visualising user flows and proceeding from them to quickly apply the insights to mockups.

Accessibility

Pharos needed to serve a variety of users during its lifetime, from data scientist power users, to sales and marketing professionals requiring easily digestible stats for internal meetings.

This presented a variety of design challenges during my work on the platform but also helped me to develop as a user-centred designer.

I had to better understand users by trying to empathise with them in a variety of contexts and find sometimes unconventional ways to implement features and functions.

Case study - Date Picker

After some really great conversations with users I determined that data recency was a key requirement for an important subset of our users. Our standard date picker was adequate for long term and custom data assessments but I could improve the user experience with little to no extra mental load on users by implementing some quick filter controls.

With a bunch of quick sketches done, I wanted to determine which location would be better for users. Our hypothesis was that the subset of users who requested the feature was small enough that the quick filters should not be front and centre but they should not be hidden either.

I expected that the quick filters at the bottom would not distract regular users from selecting dates on the picker as normal, and would still be easily accessible for our target users. I still needed to test this and determined that A/B testing the static images would give us adequate feedback for us to proceed.

Evolving capabilities

Pharos was a platform that underwent continuous development during my time at Semalytix as our understanding of product fit and our user base became more in depth.

The basis for Pharos was a solid foundation of data visualisation and dashboard design, which had to be managed and maintained during the incremental improvements that occurred.

Case Study - Design Systems and component development

As the sole designer it fell to me to maintain some semblance of order in the design systems of the product team. Luckily for me, as I learned and grew, so too did Figma become more powerful, in ways that really helped me to stay on top of styles.

Figma’s versioning system for components was a really great update that improved my design workflow immeasurably. It was also invaluable for my work with the development team. Using versions I could clearly communicate the desired appearance of different states and at different resolution breakpoints. In the example below, the filters of an interactive element needed to appear at all three breakpoints.