Case study 02 · 8 min read
One design language, five surfaces
Building the Nexudus design system and redesigning our companion apps
- Problem
- After an agency redesign, Nexudus had a new design language, but it only existed as a set of one-off page mock-ups. Nothing was reusable or connected, and the rest of our product family looked and worked differently.
- Role
- Sole designer. I built the design system, maintained it for five years, and led the research and redesign of three companion apps.
- Team
- Me as the sole designer, a handful of front-end and app developers, and our CTO, who leads the development team
- Timeline
- Around five years. The design assets were handed off in 2021, and the bulk of my work was done in 2022. As with any design system, it was a constantly evolving project until the system was retired in 2025.
- Outcome
- One adaptive system across web, tablet and mobile, with a unified naming convention. Check-in on NexIO went from Visa required.
Five surfaces, no system
We started with five products that each looked and worked their own way.
Nexudus is used by coworking and flex space operators around the world. Their members and visitors interact with it across five surfaces:
- Members portal: Web app used by members to book, buy and manage their account
- Mobile app: The above portal designed for iOS and Android
- NexIO: A check-in app at building receptions for members and guests
- NexBoard: A tablet outside each meeting room, showing availability and booking on the spot
- NexKiosk: A self-service kiosk and point of sale
These are very different devices, used by different people in different moments. A member glancing at a meeting room door and a receptionist ringing up a coffee don’t need the same thing.
The starting point
In 2020 we worked with an agency to redesign the members portal and mobile app. I was leading the project from our side while still in my training and customer experience role, and it became part of my move into design.
The agency was brought in as a UX agency, but what we got was mostly a UI redesign, page by page. At the end we had mock-ups for each section of the portal. There was some consistency in the design and the start of a structure, but every mock-up used its own individual elements.
Nothing was built from shared components.
It looked good and fit the purpose overall, but it wasn’t a working file we could maintain or build on as a company, especially with one designer. As soon as we received the assets, I started working on the system. It took a while, as I was learning on the job and doing other work alongside it.
Building the system
The mock-ups looked right but they needed to become something we could build on.
I extracted the design language from the mock-ups and turned it into a proper design system in Figma. Reusable components, styles and a shared library, following best practice as closely as I could, with variables added once Figma had them. It was built up in layers: foundations like colour, type and spacing, then the components made from them, followed by the larger patterns made from those.
The goal was simple:
One source of truth, so that when I changed something it updated everywhere.
Because the system was published as a library, every mock-up in every file picked up changes when we synced.
One system, not three
Rather than having one design system for web, another for tablets and another for mobile, I built a single adaptive system that worked across all of them.
In 2021 Figma didn’t have a lot of the features that it does now, such as wrapping layouts, instance swapping, and variables. Simple things like buttons adapted easily. For components where the layout had to properly change between devices, such as larger cards, booking components and tables, I designed the device versions as variants inside the same component. You’d pick the version you needed from the component itself, rather than hunting through separate libraries.
Speaking the same language as the developers
I made sure the system matched how the product was actually built. Tokens, component names and the overall structure followed the structure of the web app, so a component in Figma and a component in code were the same item and same name.
The members portal is built in React and the mobile app in React Native. Translating between the two wasn’t always easy, but the components were close enough that we could reuse the same design system for both.
Starting points, not blank pages
On top of the components, I created starting-point mock-ups for the key pages in each section of the product. New features started from these rather than from scratch.
It also changed how we documented design. The system itself documented the components, so feature documentation only needed to cover new components in detail, plus the experience and logic of what we were building.
Keeping it alive
The agency’s original designs didn’t cover everything the product would need. As Nexudus kept growing, I kept extending the system with new components and patterns. I was the main person looking after it for its whole life, around five years.
Putting it to work
The real test of a system is using it, so next came the companion apps.
NexIO
Check-in at the entrance
NexBoard
Booking at the meeting room door
NexKiosk
Self-service and point of sale
With the system in place, I used it to redesign three of our companion apps. Bringing them in line with the new design language was part of it, but I didn’t want these to be visual refreshes. Each one had real usability problems, and a lot of them came from how complex the product is underneath.
I interviewed around 15 operators for each app, a few more for NexIO and NexBoard and a few less for NexKiosk, which isn’t as widely used. I also went on site with operators to test NexIO and NexBoard in the real environment. For NexKiosk, I focused on the customers using it most heavily to get into the detail of what they needed.
NexIO: check-in
NexIO sits at the entrance. Members use it to prove they have access that day, and guests use it to sign in when they visit.
The main problem was that everything took too long. Checking in could take Visa required. I cut that down to Visa required, and introduced checking in by tapping your phone if you have the app, which removes the taps altogether.
I also added deliveries. Nexudus already handles parcels, so now a delivery person can drop off an item at the NexIO device, and the member is notified straight away that it’s waiting at reception.
NexBoard: meeting room booking
NexBoard is a tablet outside a meeting room. It looks simple, but bookings in Nexudus are complicated. There are rules about who can book, when, for how long, what it costs, credits, teams, guests, check-ins and extending a booking. The original app didn’t account for a lot of this.
I designed around all those rules so the person standing at the door doesn’t have to think about them. They just book the time that’s free, and the app handles the rest.
I also simplified the layout. The old version put everything about the room and its bookings on one screen. The new version has a standby mode that shows the room and its availability at a glance. When you wake it, you see the room details and features, and can book or check in depending on what you want to do.
NexKiosk: self-service and point of sale
NexKiosk is our point of sale, used both as a self-service kiosk and by staff behind the counter.
I introduced a guest checkout here too, and a lot of case handling. The biggest example is payments. If someone who’s part of a team with a paying member buys something, who pays? A coffee might be charged to them, while something that’s always included should go to the team. The design now shows that clearly, so both the customer and the admin using the POS know which payment process that person will go through.
What happened
Here’s what the system did for us, and why we retired it.
The results here are less about numbers than about how we worked. Design got quicker, handoff to development got cleaner, and the structure underneath was robust enough to maintain and evolve for as long as we needed it.
NexIO check-in taps, or a single phone tap
5
Surfaces on one system: web, mobile and three companion apps
Around 5
Years in use, from 2021 to the end of 2025
- One system used across web, mobile and three companion apps, for around five years
- Starting-point pages and shared components made designing new features much faster
- Handoff got cleaner, because designs and code shared the same components, names and structure
- New components and patterns slotted into the same layers, so the system kept up as the product grew
- Documentation got lighter, because the system carried the component detail
- NexIO check-in went from Visa required, or a single phone tap
Why it was retired
In 2026 we launched a completely redesigned members portal. It’s a white label product, and we moved to a more brand-agnostic approach, with a template builder operators can use to shape their own site, rather than the single default website we provided before. That needed a new foundation, so at the end of 2025 we retired the system.
What replaced it isn’t another Figma library. We now develop with LLMs, so the design system lives directly in the codebase, with reference docs, workflows, checks and reviews that keep the design consistent as developers keep improving the product. I wasn’t involved in setting that up, but I’m taking part in a similar project now, for our new admin panel. How I design with AI will be its own case study, told through building this site.
What I’d do differently
I learned most of this on the go, and there’s a lot I knew at the end that I didn’t know at the start.
Split the library. Everything lived in one file: foundations, components, layouts and page mock-ups. That made it complex to manage, and when I was designing a new feature I’d get everything in the library, every icon, illustration and component, instead of just what I needed. I’d split it into separate libraries for foundations, components and layouts, which is the approach I’ve taken since.
Plan for React Native from the start. We designed and built for the web first and then made the mobile app follow. React and React Native share a lot, but designing components for a mobile codebase is quite different, and we ran into problems because of it. Next time I’d plan the two together with the developers from day one.