Portfolio
When the Database Starts Designing the Product
The product supported operational work in traffic monetisation and had developed from an API-led technical foundation. Its information structure closely followed backend processes. Working from a UX role, I examined with the team where that model conflicted with users’ work and which feedback mechanisms they needed. Product names, partners, internal metrics and implementation details are omitted here.
Process
Phase 01
Separating Product Logic from Backend Logic
My team and I flagged early that the visible structure represented technical processes rather than users’ goals and mental models. The issue was larger than navigation: the product lacked a coherent domain model for the work it was meant to support.
Phase 02
Naming the Missing Control Loop
I argued early for notification and alerting capabilities. Operational users needed to recognise relevant states and deviations in time to respond. This connected usability to the product’s ability to support the work at all.
Phase 03
Strategy Without Decision Rights
My team and I raised the structural concerns repeatedly. The anticipated implementation effort meant changes were initially deprioritised. I could make the issues and their implications visible; other roles held the resource and sequencing decisions.
Phase 04
The Eventual Rebuild
A subsequent rebuild addressed a more user-centred model along with notifications and alerting. The sequence shows that the earlier concerns remained relevant, without proving that every proposed solution would have worked.
Methods
Systemic Diagnosis
Treat the information model, operational workflow and commercial feedback loop as one system rather than reviewing screens in isolation.
Domain Before Architecture
Technical entities may shape implementation. They should not quietly write the product’s conceptual model.
Operational Feedback Loops
Treat alerting and notifications as control infrastructure, not convenience features waiting at the bottom of a backlog.
Influence Through Consequences
Explain how structural concerns affect navigation and operational control, and keep them available for discussion as priorities change.
Key Takeaways
Technical Logic Is Not User Logic
A coherent backend can still produce an incoherent product when its structures reach the interface unfiltered.
Feedback Is Part of the Product
People steering commercial processes need signals, priorities and actions — not merely access to data.
Early Evidence Does Not Guarantee Early Action
A sound diagnosis does not automatically change priorities. I would now articulate the risks and the conditions for reconsideration more precisely.
My contribution was the early diagnosis and repeated escalation of structural concerns: the product needed a model people could work with and feedback mechanisms that supported intervention. Prioritisation remained with product and management. These topics were addressed in a later rebuild, which does not establish sole authorship of its direction or a commercial result attributable to my recommendations. Looking back, I would make the consequences of each risk and the conditions for revisiting the decision more explicit.