The 5 principles that guide design at Savvy
The most common feedback in design is also the least useful: "I don't like how that looks." That feedback is about taste, it says something about the reviewer and nothing about the work itself. The designer defends, the reviewer softens, and the thing on the screen stays exactly as it was.
Designing products requires quick decisions made by lots of different people all the time. Small teams can rely on tribal knowledge, but as the team grows it’s harder to stay aligned on what “quality” is.
Our products won’t feel cohesive unless everyone is working from the same definition of “quality.” Design principles fix this.
How we got to these
A design principle is a durable decision filter. It helps a team make tradeoffs when constraints exist, and it turns "I don't like how that looks" into a question about the work that anyone in the room can ask, even if they're not a designer.
Ours came out of Creative Lab, a monthly session where the design team steps back from individual tickets and looks at the product and our practice as a whole. We started with our own work, and next to it we put things advisors had told us, in their words:
"As an advisor with an older client base, I need the technology I use to be as unobtrusive as possible, because my clients aren't tech savvy."
"As an advisor group, I need to configure the product to my practice's needs, but these systems are too brittle and too opinionated."
Then everyone wrote candidates on their own, silently, against 3 tests
- Is it actionable? It influences a decision someone is making.
- Is it opinionated? It implies what not to do. If nobody could reasonably argue the opposite, it's a platitude.
- Is it durable? It holds across products and across time.
That second one killed most of our first drafts. "Navigation should be intuitive" is not a principle. No one is out there arguing for unintuitive navigation.
These are the 5 that survived.
#1 Optimize for the service, not the surface
Our responsibility extends beyond screens: we design the full service experience across operations, advisors, and clients, prioritizing end-to-end clarity and reliability over isolated UI optimizations.
In practice: A "complete" design accounts for downstream ops workflows and client communication, not just the UI an advisor sees.
#2 Human signals build trust
We prioritize human cues (voice, personalization, and advisor presence) over generic system messaging during moments of risk, uncertainty, or vulnerability.
In practice: In high-stakes moments like onboarding, account transfers, money movement, or errors, we surface clear advisor presence and personalized messaging so clients understand what's happening and who's responsible. The advisor is the human behind the software, and the design should show it.
#3 Patterns guide us, not limit us
We rely on design consistency to provide a cohesive experience, but we don't let the design system limit thoughtful solutions.
In practice: We start with established patterns for layout, interaction, and components, but adapt or extend them when a use case (like AI-driven guidance or complex workflows) requires a clearer or more effective solution.
#4 Direct attention, don't divide it
We use color, hierarchy, and selective visibility so advisors, ops, and clients can focus on priorities and next actions without distraction.
In practice: Service Calendar shows advisors their client meetings and tasks while ops sees only their assigned requests: each role sees only what they need to act on.
#5 Teach through use, not instruction
Our product is designed so that users can easily learn a feature as they use it, whenever they need to use it. We don't force them to stop, search, or train separately.
In practice: Empty states, progressive disclosure, and contextual prompts explain what to do next as advisors work, so they learn the system by using it, not by reading documentation or completing training.
What didn't survive
The 5 above beat about a dozen others. A few of the ones we cut are more instructive than the ones we kept:
- "Predictable paths over guesswork." True, and nobody would argue the opposite. Failed the opinionated test.
- "Design for confidence." Confidence is the outcome we want. It doesn't tell you what to do on Tuesday.
- "Surface what matters, hide what doesn't." A better-written version of an idea already covered by "direct attention, don't divide it." We merged them rather than shipping 2 principles that would compete in the same critique.
- "Design for recovery and progress, not perfection." Strong idea, and it lost the vote. It may come back.
Where the design principles live
Principles only matter if they show up when a decision is being made, not just in a doc nobody reopens. Outside Creative Lab, ours show up in 2 primary places.
1. On our desks. We turned the principles into a deck of physical cards. Every designer has one, and new designers get theirs in their onboarding kit. You pull a card when you're stuck mid-project or when work is up for critique. The front names the principle; the back reframes it as a question. Flip over "Direct attention, don't divide it" and it might read:
“Where are we using color as decoration vs. communication? If color is used on every button and header, it loses its meaning. Document every use of brand, accent, or status color, stack rank the list, and see whether color is directing attention to what matters.”
2. In our codebase. Everything Creative Lab produces feeds a design.md file that our design agents work from: the principles, design system guidelines, brand voice, common mistakes. When a recent session decided our charts should use neutral blue instead of Savvy green (green conflates "money" with "positive" in a wealth platform), that decision shipped into the file the same week. The same lens that guides a designer in critique now guides the tools we design with.
Run this yourself
The output of a principles exercise matters less than most teams expect. The argument is the point. If you want to run one, this is the version that worked for us, in about an hour:
- Start with your own work. Put your last quarter's output on the board next to verbatim user observations. Principles borrowed from another company's blog post describe another company's problems.
- Write silently first. 3 to 5 candidates per person, one per sticky. 2 constraints: each one must imply a tradeoff, and each must be phrased as a belief or a rule, never as a feature.
- Cluster, then argue. 15 minutes, 3 questions per candidate. What decision would this help us make? What does this push us away from? Would this hold 2 years from now?
- Dot vote. One dot per person per cluster. Aim for 5 or fewer survivors. If you can't rank them, what you have is a values statement.
- Pressure-test what's left. Does it translate to the client experience, and are we okay if it doesn't? Is it broad enough to apply to the whole business and specific enough to prioritize with? Will it survive a delivery deadline?
Conclusion
We're building an AI-native RIA, which means the design problems here are rooted in service design, on top of a domain where being wrong has consequences for someone's financial future. If that sounds like the kind of hard you're looking for, we're hiring across engineering, product, and design.
