Where it started

As Coherent matured, parts of the interface were starting to feel functional, but not always clear. We were collecting a lot of data, but we weren’t always utilising it in a valuable way.

In the workspace dashboard for example, hosts could see all of their member bookings, with each row showing the basics; what was booked, when, and by whom - but little else.

From user feedback, I learnt that hosts were finding it difficult to get the answers they need from their dashboard:

• Where did this booking come from?
• Does the member have the right level of access to the building?
• Has this booking been paid for?
• What did they pay for this booking?

I wanted to reveal more data, and improve how it was presented, so that hosts could make decisions with more confidence

During this time, we were also preparing to launch our design system, Hotdesk, alongside a new UI component library, and introduce Vue into our tech stack. I’d built this design system from the ground up and this project presented the perfect opportunity to begin its gradual rollout through the introduction of a small set of new components

The problems

The question of "Where did this booking come from?" was a simple one caused by inconsistent labelling - it wasn’t always clear about who the booking was made for and who it was made by

Billing was more complicated. Bookings fall into two billing types; pay-as-you-go (billed instantly) and monthly (added to an "active" invoice and billed at the end of the month).

Pay-as-you-go was straightforward - the invoice exists immediately, and the numbers don’t change. Monthly bookings however, aren’t final until the end of the month, so the amount billed changes as bookings are made or edited throughout the month.

If a member has 5 hours of meeting room credit per month and they make a 3 hour booking, the booking uses 3 hours. If they make another 3 hour booking, the system redistributes things so their first booking is now billed at 2 hours of credits, plus 1 paid hour

The challenge wasn’t just showing the price, it was explaining a moving target without overwhelming the user

Access control had similar complexities

Coherent integrates with SaltoKS. Locks are created in Salto and then assigned in Coherent to the workspace, to resources (like a meeting room), and to tariffs (like casual monthly membership). When someone makes a booking, we create an access group in Salto that bundles all relevant locks - front door, first floor, meeting room, bike shed etc. - into an access group

This granularity was powerful for creating access management solutions, but came with a downside; hosts would sometimes forget to assign locks in all the right places. This led to members making bookings, but not getting the access needed.

Hosts needed a way to quickly confirm a booking’s access without having to dig for details

Approach & iteration

I needed to find a solution that would surface this information, without adding complexity to the dashboard. Hosts needed to answer their questions quickly, without losing context or feeling overwhelmed

At the same time, I worked with our backend developer to map the data that we already captured, and find out where gaps existed. This helped to ensure that my designs would be feasible and aligned with constraints

With a clear picture of our starting point, I shared my concepts with hosts to understand their strengths and weaknesses. Their feedback revealed two priorities:

• Maintain context - hosts didn’t want to leave the dashboard
• Access key information immediately - they did want to dig for details

Some of our existing patterns fell short here - navigating to a new page or opening a dialog was too disruptive and unstructured data in expanded rows was too difficult to scan at a glance

I landed on a drawer to show booking details without pulling the user away from their current context, and key-value table to make data easier to scan whilst still allowing easy access to the full dataset as needed.

Using the tokens and design-decisions in Hotdesk, I built the drawer Figma component from scratch, and refactored our existing key-value table. Alongside this, I created a documentation template for components to ensure consistency was baked in to our new library from the get go. This set us up with a consistent format that covered usage, behaviour, props and design, all in one place

Tackling the data

Booking ownership

A booking could be made by an admin, by one of their team members, or by a host on their behalf - but in all 3 cases, the booking would be assigned to the admin. This would often lead hosts to ask: where did this booking come from?

To resolve this issue we started storing extra pieces of data so that we could clearly display who the booking was made by and who it was for. We added 'Created by' and 'Created for' rows into the tables, and added avatars alongside names to make this data easier to consume at a glance

Access control

In my first iteration, access control data was represented as a key-value pair: "Locks" : "Has access to 4 locks", with an arrow to expand and view the full list. In testing, hosts said it took too long to confirm that the right locks had been included. They did value seeing the full list but didn’t want to dig to get their confirmation

Next, I tried a "Lock 1, Lock 2 + 3 more" pattern, that worked in theory, but in practice, the most important lock was often hidden behind the "+ 3 more", making it somewhat redundant

I worked with our backend developer to apply a priority to the order the locks were returned. Resource-level locks (like "Meeting room") would appear first, followed by tariff-level locks (like "Front door" and "First floor"), and then workspace locks (like "Bike shed")

This small adjustment had a big impact on UX. Hosts could now confirm, at a glance, that the important locks were present, and still expand to see the full list when needed

Billing

Monthly bookings were dynamic, so displaying their billing status was complex. Credits could shift and amounts billed could change through the month as bookings were created or edited

I worked closely with our backend developer, to map out all the billing states that a booking could move through. To make them understandable at a glance, I designed a combination of helper-text and key-value table that clearly communicated the billing status of each booking.

Regardless of whether a booking was fully paid, partially paid, or still pending, hosts could quickly answer the question "Has this member paid for this booking yet, and what did they pay?", without needing to interpret the numbers themselves

API

Introducing Vue into our tech stack allowed us to more cleanly detach our code, using APIs to send backend data into frontend components. Whilst this brings a variey of benefits, it also adds some risk - what if an API doesn't respond the way it should

I worked with our developers to understand the range of errors that we could experience from both the Salto and Coherent APIs. We developed a new banner component and carefully considered the messaging to educate the user without confusing them with technical terminology

As part of the developer handoff, I produced a series of wireframes showing the different error states, and paired this with a table showing all of the error code + error messages combos

Key design decisions

Drawer component

We chose the drawer to reveal booking details because it preserved context while giving hosts access to the full data. This pattern kept the dashboard clean and allowed users to confirm information quickly without unnecessary navigation or extra clicks

Key–Value Table Redesign

Redesigning the key-value table made individual data points easier to scan while keeping the full dataset accessible. Prioritisation of important data, combined with helper text, helped hosts understand complex states at a glance - whether it was billing status, booking creation, or access control.

Access Control Prioritisation

Introducing a priority order for locks solved a subtle but critical pain point. By showing the most important locks first, hosts could immediately verify that the correct level of access had been granted, while still allowing easy access to the full dataset if needed

Dynamic Billing Display

Monthly billing was inherently a moving target. By combining helper text and structured data display, we made billing transparent and predictable, so hosts could answer “Has this member paid for this booking yet, and what did they pay?” without needing to mentally calculate allocations

Component documentation

I developed a documentation template for our new component library. Standardising how components were documented ensured consistency, reduced developer friction, and made it easy to scale Hotdesk across the product

Collaboration & Systems Thinking

Working closely with the backend developer ensured the interface reflected real data capabilities and edge cases. At the same time, the drawer and key-value table were built with Hotdesk, our new design system, contributing early patterns to the component library and reinforcing design consistency across the product

Outcome

• Clarity & confidence - Hosts could confirm booking details at a glance, reducing friction and second-guessing
• Error prevention & efficiency - Access control prioritisation prevented mistakes and the billing status data reduced confusion and support requests
• Systems - Hotdesk and the new component library went live, establishing a foundation for consistent, scalable UI patterns

Reflection

This project shipped a lot of small improvements that made Coherent easier to use and easier to develop. The feedback from hosts reflected this - we had fewer questions and less second-guessing

Seeing Hotdesk running in production, supporting our new component library was a big milestone. It improved our workflow; we now had clearer guidelines, better documentation and a new level of collaboration between design and engineering. It set a solid foundation for future frontend development