Shipped
Product Design @ Beca
2026
The Problem
No client visibility
Unless you were a developer, there was no visibility on any sort of data about the product unless you had access to all the databases.
Developer bottleneck
Every task, from simple visibility to routine operational checks, depended on developer intervention, slowing workflows and limiting autonomy.
Fragmented access
There was no unified place to view backend information, manage client permissions, or check analytics. Tools and data were scattered across systems, making even basic oversight difficult.
Leading and understanding a cross functional team to build the relevant solutions
The initial user research surfaced enough insight to begin shaping low‑fidelity mockups for our second round of interviews. We interviewed 5 Product Managers, 3 Tech Leads, 3 business analysts, 3 QA Testers, and 3 Developers.
With no existing interface to compare against, these early sketches became a useful catalyst - helping stakeholders explore what might be possible, identify what needed improvement, and surface additional feature ideas. They also revealed clear thematic patterns and major pain points, allowing us to prioritise the right features for the first iteration.
High level overview of workflows, translating the backend architecture into user friendly and understandable pages in the frontend
Low fidelity mockups with key workflows and notes for each stakeholder.
Synthesising interview feedback by aligning themes, requirements, current state, and features
Images blurred for confidentiality reasons
Working with constraints and ambiguity
Although we were able to interview 17 internal users, we had to work with certain constraints that strayed from a linear research -> prototype -> feedback -> design -> delivery loop.
Short delivery window
We were expected to deliver a set of designs to the developer team within 2 weeks. This meant we had to gather user research fast, and fill in the gaps with our own intuition and judgement, and iterate quickly based on feedback and what doesn't work. In the example below, we had to pump out designs to understand what worked and what didn't work - hence there were features with almost 4-5 redesigns.
Prioritisation/budget constraints
With a fixed project budget and developers split across multiple client commitments, we had to make sacrifices on certain features that we had originally planned to design and deliver with our roadmap. In the image below, the highlighted areas were features we had to let go after we found out our development time was cut in half - we need to only focus on the features that really mattered to deliver business impact.
Dead ends and pivots
Balancing technical feasibility with craft became a constant part of the work. I’ve learnt that the most effective approach is to interrogate how essential each design decision truly is, and weigh that necessity against simplicity. It keeps the design purposeful without overextending the build. Below are a couple examples, out of a handful, that became dead ends or pivots.
In the example above, we ended up getting rid of the Breadcrumbs feature.
I was challenged on the assumption that users would frequently navigate from a parent page into deeper pages. In reality, that behaviour occurs only in rare cases. Because of this, the development effort required to implement breadcrumb logic didn’t match the actual impact of the feature - its usage would be minimal, and the return on complexity was low.
We ultimately decided to scrap the breadcrumb feature.
In the example above, we scrapped the Audits Page feature.
I was challenged on the design I proposed for the audits page. The two‑column split interface, while visually appealing, would require developers to build the layout entirely from scratch and couldn’t leverage any of our existing CSS components. When we interrogated the necessity of the design, the effort‑to‑impact ratio didn’t hold up.
We opted instead for a simple table that displays audit history, with each row representing a change. This approach offered a cleaner balance of simplicity and technical feasibility, while also unlocking additional filtering capabilities.
Useful product data, all in one place
Instead of having Product Managers, Business Analysts, and QA Testers hunt for user metrics across fragmented systems, all insights are now consolidated within the Analytics tab. Designed as a five‑part feature set, the analytics surface login activity, user roles, product performance, and system health in one place.
The dashboard brings together data from multiple sources - including Azure services and SQL databases into a single, consistent view.
Regardless of which solution a Job Manager is reviewing, the dashboard automatically filters to that solution and displays only its relevant data, ensuring clarity, accuracy, and immediate operational value.
First iteration
Metrics blurred for confidentiality reasons
After feedback
After releasing the first iteration of the reports, we realised a few things:
The navigation sidebar was taking up too much space, especially in smaller screens. It also caused too much noise with the many icons it had.
The report itself was a bit too cluttered and noisy.
Users wanted more focused metrics.
Hearing this feedback, I shipped a collapsable sidebar, opted for cleaner UI/less information and focused on the data that really mattered by removing a few pages as well as visuals.
Metrics blurred for confidentiality reasons
Managing the components that shape a product
To make each product instance easier to manage, we introduced a simple structure using Solutions and Workspaces. A Solution groups everything for a single client into one place, and Workspaces hold the settings for each part of the product.
This means teams can now configure how certain pages look, adjust module behaviour, or access files stored within the product - without needing a developer to step in. Instead of jumping between scattered tools or bookmarked URLs, people can open any workspace, see what’s inside, and make changes directly from a single, consistent interface. It gives admins a clear, intuitive way to manage the building blocks of a product and reduces the dependency on developers for everyday tasks.
Structure of a solution
Managing a workspace
Workspace and workflow identity through visual experience
To make Workspaces more intentional, each technology received its own custom Figma‑designed icon, giving users a clear visual cue in the navigation bar. Because names can be customised, we added subtitles to ensure workspace types are instantly recognisable. Primary pages also received distinct icons for consistent wayfinding. Together, these custom icons form a unified visual language that improves clarity across the Admin Center and remains maintainable through shared tooling (Figma).
Final Design
Earlier iterations
Final workspace icon design
Final primary navigation icon design
Giving admins full control over product access
To simplify how access is managed across a product, we introduced a clear set of five standard role types that can be assigned to any user within a product instance. Each role comes with different levels of permission, allowing admins to control who can view, edit, or manage specific parts of the product. This page gives product managers a straightforward way to assign and adjust these roles without relying on a developer, making access control faster, more transparent, and far easier to maintain.
Making it easy to find anything
To streamline navigation across the Admin Center, we introduced a universal search bar that lets users instantly jump to any solution, module, workspace, or user. This reduces unnecessary clicks, supports industry‑standard navigation patterns, and helps both configurators and developers quickly locate the exact resource they need - even when working only with IDs.
Search results respect existing permission roles and display clear grouping, icons, and identifiers so users can confidently navigate directly to the correct page.
Feedback
The shift in response was striking. Coming from a team that historically focused on shipping something that simply worked or ticked the boxes, the level of enthusiasm for UX and UI was overwhelmingly positive.
My hope is that this feature becomes a cultural turning point - encouraging the product team to invest more effort, budget, and care into design craft and detail‑driven execution, alongside strong strategy and meaningful business impact.
"Great to have this progress! We've been talking about permissions like this a while so SUPER exciting"
Business Director, Digital Management Team
"LOVE this data!! Important for adoption guidance"
Business Director, Digital Management Team
"I'm so happy with all the recent changes"
Senior Product Manager, Digital Products Team
"Great stuff, Wynn! Looks fantastic, like all your work does!"
Associate Business Analyst, Digital Services Team
"Wynn has been writing very good PBIs and actually creating figma mockups vs my janky screenshot+MS Paint mockups"
Associate Product Manager, Digital Products Team
"I didn't realise BEYON could look like this"
Principal/Technical Director, Digital Products Team