Enterprise product · UX & UI, solo
A platform that automates and monitors data transfer between enterprise systems and microservices. I built the backend with a colleague. Once it was finished I took the whole interface on myself: I designed the user experience from a blank page and implemented the UI end to end, with no designer on the project and no template to start from.
- Backend developer, then sole UX and UI designer
- Two developers on the backend, interface designed alone
- MDT Yazılım · 2023 to 2024
- In production
Concept B, the status-first direction the shipped interface grew out of
01The problem
Once the backend was finished, the platform could move data but could not say anything about it: the only way to know whether last night's transfer had succeeded was to read raw logs. There was no designer on the project and no template to start from, so the first design decision had to answer the same question every operator already had at seven in the morning: did it work or not.
02Research & rationale
Before writing any interface code I drafted two full concepts and judged both against that one question, rather than refining a single idea in isolation. I also carried in feedback from LOGO ERP customers whose SQL Server problems I had already solved in support, since their complaints about opaque systems were the closest available stand-in for how an operator would read this screen. Stephen Few's guidance on dashboards, show what needs attention first and cut whatever does not inform a decision, was the yardstick I held both concepts against.
03Iterations
The starting point: a generated scaffold
This is what existed the moment the backend was finished: the default Razor Pages template, an unstyled sidebar, and plain forms wired straight to the database with no visual pass at all. No status, no hierarchy, nothing to tell an operator anything at a glance. This, not a mockup, is the actual before.
Screen 1 of 3
Screen 2 of 3
Screen 3 of 3
Concept A: a conventional admin panel
A sidebar-first layout built the way most internal tools are built: dense tables for every entity, and a raw JSON configuration panel exposed directly in the interface. It surfaced every technical detail (connection IDs, endpoint paths, auth strategy) in full. Rejected because it answered the wrong question. It let someone manage the system, but it made them read table rows to find out whether the system was healthy, instead of just seeing it.
Screen 1 of 4
Screen 2 of 4
Screen 3 of 4
Screen 4 of 4
Concept B: status before detail
A top-navigation dashboard built around the operator's actual question: large status cards up front, a sync performance chart, and a health matrix, a grid of coloured tiles standing in for every connection's state, so failure reads as colour before it reads as text. This is the direction the shipped interface grew out of, carried further once it was refined past a concept.
Screen 1 of 5
Screen 2 of 5
Screen 3 of 5
Screen 4 of 5
Screen 5 of 5
Shipped: the production interface
What actually went live keeps Concept B's bet, status cards and a success rate up front, but strips it down: no chart, no tile matrix, just the four numbers an operator checks first, a searchable entity list, and a connections table with nothing decorative left in it. Simpler than either concept, because production is where the design gets edited down to what the job actually needs.
Screen 1 of 3
Screen 2 of 3
Screen 3 of 3
04Result
The shipped interface kept Concept B's core bet, that status should be visible before it needs to be read, and pushed it further: a status language of running, degraded, failed and recovered designed to stay legible across hundreds of jobs at once, and error views built around what the operator can do next rather than around the shape of a stack trace. The platform is in production at MDT Yazılım.
- .NET
- ASP.NET Core
- EF Core
- SQL Server
- Tailwind CSS
05Limitations
- No usability test. The choice between Concept A and B was my own judgement against the operator's question, informed by support conversations, not by watching operators use either concept.
- No before and after measurement. The before state was a scaffold nobody used in production, so there is no fair baseline to compare the shipped interface against.
06What I would do differently
The decision between the two concepts is the one I would now make with operators rather than for them. A first-glance test, showing each concept for five seconds and asking 'did last night's transfer succeed?', would have taken an afternoon and turned my judgement into evidence.
07References
- Few, S. (2006). Information Dashboard Design: The Effective Visual Communication of Data. O'Reilly.
- Nielsen, J., & Molich, R. (1990). Heuristic evaluation of user interfaces. Proceedings of CHI '90. ACM. doi:10.1145/97243.97281