The framework matters less than how I move from a messy problem to a design decision.
HorseKeeper is an example of what my design process looks like when taking a new product from 0→1. But if you ask me, “How do you design?” my first question is going to be:
What are we trying to solve?
Every design problem is different. If I'm working on an existing product that people aren't using, don't understand, or simply don't like, I'm not going to approach it the same way I would a new product.
I start by investigating why. I look at the people, the data, the workflows, information architecture, framework, usability, and visual experience. Where are people getting stuck? What information is missing or difficult to find? Is the architecture working? Does the flow make sense? Is the interface helping or getting in the way?
Once I understand the problem, I begin exploring solutions, usually more than one. I iterate, prototype, test with users, learn from what works and what doesn't, and refine.
Throughout that process, I'm working with engineering to understand technical constraints and feasibility so the solution isn't just desirable. It's something we can actually build.
Discover → Define → Design → Refine → Repeat
That's the framework I use, but the framework itself isn't the important part. What matters is how my brain moves from a messy problem to a design decision.
With HorseKeeper, I discovered that the problem wasn't simply storing horse records. It was reducing the cognitive load of managing ongoing care across multiple horses. That changed the design conversation.
Instead of asking, “Where should we store this information?” I started asking:
That last question became especially important because HorseKeeper is designed as one connected experience, not a collection of individual features.
A horse profile connects to care records. Care connects to service providers and appointments. A service can generate an expense. A purchase connects to a store, products, and supplies. Those transactions roll into expense tracking and reporting. Reminders and notifications surface what needs attention across the system.
From a profile to an expense report, the experience is connected.
And if that model sounds familiar, it should. Profiles, records, forms, filtering, groups, roles and permissions, services, transactions, ordering, notifications, expenses, and reporting, all connected across a shared system, are the same patterns found throughout complex enterprise SaaS applications.
The subject matter may be horses. The product architecture and design problems are very much enterprise.
Wink, wink.
That systems thinking drove the information architecture, hierarchy, relationships, and workflows that followed.