EdSmart Enterprise

EdSmart makes software for schools. EdSmart Enterprise was a new, larger product built for the people who run things at the district and multi-school level: administrators who live in dashboards, track the health of dozens or hundreds of schools, and can't afford to misread what's in front of them.

I joined as the UI designer on this build. The brief sounded simple and wasn't: design a consistent, intuitive interface for a platform that didn't have one yet.

Because Enterprise was a greenfield product spanning an entire suite, there was no existing design language and no component library to build on. Every module had been designed in isolation, so the same idea looked and behaved differently depending on where you found it.

For an administrator, that's not a cosmetic problem. Inconsistent layouts and shifting interaction patterns mean a steeper learning curve, and a real risk of missing something important in a tool where missing something has consequences. The product worked, but using it cost more mental effort than it should have.

One constraint shaped everything: this was a new build with no baseline usage data. I couldn't lean on analytics to tell me where people struggled. I had to find the problems by evaluating the product directly and testing with users, not by reading a funnel.

I started with heuristic evaluation to find where the inconsistencies and friction actually lived, then worked the fixes back into a shared system: colours, typography and components that every module could draw from. The point wasn't to make screens prettier. It was to make the same thing look and behave the same way everywhere, so people could stop relearning the interface.

The clearest example was on the main dashboard. School "health" was shown as ring graphs, and in testing those rings were consistently misread. People couldn't tell at a glance which schools were fine and which needed attention, which is the one thing that view exists to answer. I replaced them with a flat bar graph. It gives immediate visual confirmation of status and surfaces the schools that need attention without the reader having to decode anything.

The same thinking ran through the rest of the work. On the onboarding view, I reorganised the hierarchy and grouped related information so administrators could track progress without hunting for it. On task management, an ambiguous double call-to-action was causing hesitation and errors, so I simplified the logic to a single clear action. On slip creation, I added a template preview and a step indicator so people could see where they were and what they were making, instead of guessing and reworking.

Small changes, but in a complex environment small changes compound. Each one removed a little friction; together they made the product feel like one thing instead of many.

The headline outcome is the system itself. Enterprise went from having no shared design language to having a foundational one: scalable patterns and components the product could keep growing on, rather than a set of one-off screens.

The interface-level improvements were validated through internal usability testing rather than live metrics, which is the honest limit of what I can claim here. People understood the flat bar graph immediately where the rings had tripped them up, moved through tasks with less hesitation, and made fewer errors on the actions they did most often.

Two things stuck with me. First, that establishing a design system early is one of the highest-leverage things you can do on a complex product, because consistency is what lets people stop thinking about the tool and start using it. Second, that you can design well for users even without baseline data, as long as you're willing to evaluate honestly and test what you make.