Design audit
Originally, Allovue was comprised of three distinct apps: Balance, Allocate, and Manage. Each had its own codebase, design language, and set of UX patterns which needed to be brought together.
Gathering our starting point(s)
One of our main goals was providing a seamless experience for the growing amount of users engaging with multiple apps.
Steps for assessing our current design language:
- Identify key personas and workflows
- what roles are using each app?
- how are they using each app in their daily workflow?
- Establish design goals
- what are our design pillars — for the team, and for the app?
- what standards of accessibility are we trying to meet?
- Catalogue design choices and patterns
- what design rules have we implemented?
- what patterns should we keep or avoid?
Accessible, modern component library
As we worked on unifying the design language, we made sure to build in accessibility to our process — from defining tokens, components, and patterns in Figma to writing robust, semantically-correct web components for use in-app.
Developing a design system
Rather than reinvent the wheel, we looked to other folks’ resources on managing and maintaining design systems for multiple applications — including the Design Systems Repo, The Design System Guide, Brad Frost’s Atomic Design, and the Figma design systems community.
Some illustration, as a treat.
Listen: sometimes, designers can have a little treat. I firmly stand by that. While working on the refresh, I got to add some fun spot illustrations to explain budgeting and education-related concepts to users. Pictured below are some examples.
Refreshing our patterns
As we worked on unifying the design language, we took the time to revisit some of our old patterns, and introduce some quality of life features to make data management and analysis easier.
Continuous updates
Our roadmap features product improvements from both our end users and our internal team — so we use a mix of tools and processes to document user research.
UX refresh: account groups
As we started to introduce new features surrounding account types, we also took the opportunity to improve on the user experience for the original Buckets (account groups) dashboard.
Users often found it difficult to understand at a glance the key information pertaining to their accounts: the relative spending across all accounts, which accounts were near full or empty, and which had pending transactions.
We gathered feedback in a couple of different ways, to make sure a wider variety of folks had the opportunity to weigh in: user sessions over Zoom, asynchronous surveys, A/B testing with images and Figma prototypes, and small proof-of-concept code demos with our existing tech.
During user testing, we ended up discovering that folks had wildly different opinions on what their preferred chart direction was — and at a glance, different reads of the information described by it.
In the future, we might investigate looking at other chart types or visual indicators for account health to further improve legibility here.
Automated documentation? 📝
Over the course of a product’s life, its processes, development team, and goals all may change. That’s where the quest for good documentation comes in!
As we continue to expand the design system, we’re looking to establish documentation practices that support humans: ones that are useful, easy to maintain (automatic, even?), and understandable in a variety of ways.
We’re still experimenting with how to automate our docs from research, design, and development to customer success. Given our more modern tech stack, there’s less official resources out there for us to adopt — but that also means there’s more flexibility to figure out our specific team’s needs and goals for the system.
