Redesigned the entire OpenWater platform - a decade-old application and review system running programs for 750+ organizations, hundreds of pages deep. New design system, new component library, and three new modules built on top of it. Shipped in three months, solo.
United StatesOpenWater is the software behind awards, abstracts, grants, scholarships, fellowships, and competitions for associations, foundations, and universities. Submissions come in, committees judge them, decisions go out. Twelve million submissions have passed through it.
The product had ten years of features stacked on an interface that had not moved in ten years. I was brought in to rebuild the surface of all of it.
The hard problem was not making it look current. It was building one component system precise enough to survive 500+ pages without stripping out the configurability that is the reason people buy it.
Every customer uses OpenWater differently. An association running 80 award programs with 320 volunteer judges. A foundation tracking grant disbursements. A conference collecting abstracts and building session schedules from them. The platform is configurable to the point of being a builder, and that depth is the product.
Which is exactly what made the interface a liability. It looked like a Windows 98 system. Not a cosmetic complaint. When a screen has forty controls and no visual hierarchy, configuration becomes memorization, and the power of the system stops being available to anyone who has not lived in it for a year.
Management knew this. They also knew the risk. Ten years of accumulated logic, and no appetite for breaking any of it.
Mine. The design system. The component library. The full UI of the existing platform. The design of three new modules: the Scheduler, Participants, and the new authentication layer.
Shared. Feature definition with the CEO, CTO, and PM. Small IA and UX adjustments made along the way, where something clearly did not fit once it was drawn.
Set by others. Scope, roadmap, and what got rebuilt in what order. The product logic already existed. I was not inventing what the system does.
They owned what it does. I owned what it looks like, how it holds together, and how the new modules work.
People were lost in configuration. The system could do almost anything and the interface offered no help deciding what to do next. Density with no hierarchy. Admins who had used it for years still worked from memory rather than from the screen.
I did not run research. There was no budget or timeline for it, and I want to be straight about that: everything I know about user pain on this project came secondhand, through the CEO, CTO, and PM. I designed against a problem I was told about, not one I observed.
How I framed it. Not “how do we make this look current.” The question was: how do you replace the entire surface of a system this large without losing the depth that is the reason it exists. Every decision below follows from that.
Discovery went into the product, not into users. Weeks before I drew anything, I mapped the information architecture. What lives where, what repeats, what only appears once, which screens are builders and which are just views. On a system with hundreds of pages, that reading period was the work. Redesigning a screen I did not understand would have quietly deleted a feature someone depends on.
Success was defined structurally, not numerically. Ship in three months. Every page in the platform rebuilt on the same system. The new modules read as native rather than bolted on. The judgment was whether the system held at scale, and whether the people who live in it every day found it better.
Reading before redrawing.
The first real decision was to not restructure. I had a mandate wide enough to re architect the IA, and a system old enough to justify it. I did not take it. The structure was not what was failing. The surface was. Re architecting would have added a year of engineering risk to solve a problem people were not actually having, and any restructure I proposed would have been built on secondhand understanding of how admins work. I kept the architecture and changed everything on top of it. Small IA and UX adjustments happened where they were obviously right once drawn, but no wholesale reorganization.
The 500 page constraint.
The component library had to work everywhere. Admin configuration screens with forty fields. Reviewer screens built for volume. Applicant screens built for people who will use them once. Public gallery pages. If a component only worked in one of those contexts, it was not a component, it was a one off, and one offs are how the last system got to where it was. So density had to be a property of the system rather than a page level improvisation. Same table, same form, same modal, tuned by state instead of rebuilt by page. That constraint drove the whole library.
The Scheduler.
Sessions across multiple conference days, laid out against rooms on a timeline. Custom start and end times per session. Conflict detection surfaced live, because a room double booked at 2pm is a failure the system has to catch, not the admin. Notes per session. Events assigned to speakers.
Participants.
An entire new module, and structurally the most interesting one, because it is two products at once. On the inside: participant types, how they attach to a session or an event, tasks assigned to them, what information they submit for their application to be accepted, and the emails that carry all of it. Every piece of that configurable by the admin. On the outside: a branded public site the participant actually receives, with login, profile and settings, their own dashboard, their tasks, and the gallery. So every configuration choice on the admin side has a visible consequence on a public site the admin never sees while making it. Designing the admin surface meant designing the participant experience at the same time, in the same head, in both directions.
Authentication.
Rebuilt login, added 2FA, redesigned session management. Driven by usability and trust, not by a security incident. The system needed to feel like something you hand your organization's data to. The login page also had to carry ad placement for revenue, which meant designing the ad into the page as a considered element rather than leaving a rectangle for someone to drop a banner into later.
The component library is what makes this one product rather than seven. The Scheduler and the Participants site were built from the same parts as a grant review screen, which is the only reason three new modules could ship inside three months.
Everything shipped. The full platform UI, the design system, the component library, the Scheduler, Participants and its public site, and the new authentication layer. Three months, solo.
The new interface landed well with both users and management, and it replaced a system that looked and worked like it was built two decades ago.
The more durable outcome is structural. The component library is what let three new modules ship in the same three months as a full platform redesign. It is still what the platform is built on.