Based in Austin, TX— I help teams untangle problems, design product solutions, and do my small part reaching business goals. Currently at Tally helping people get debt free and better off financially. I thrive in the company of good people, favoring teamwork over "me, me, me-work.”
Design Systems Lead at Tally
Currently v.1 of this site, additions on the way
Description: Rethinking our design operations and workflow
In 2015 I joined Insamotor— a private-party car marketplace offering commission-free transactions, protection from fraud, and financing. As the first design hire on a small team we had a long road ahead of us; tasked to solve problems at an intersection of marketplace and fin-tech spaces.
We moved quickly and hacked our way to feature completion— though, at the cost of an inevitably messy process and a few cascading effects. Fast forward to today, poised to expand our markets nationwide and grow our team, we knew that how we operated achieved what we needed but didn’t lay a proper foundation moving forward.
Our head of product led with a few initiatives and adjustments to workflow, and as a design team took this opportunity to stay proactive and re-evaluate our own process. We collected feedack across product and engineering teams, identifying two key areas we could improve on:
By iterating on our process, we could improve our output. But first, not without a few important guidelines: avoid attempting to solve every issue at once, install structure only where needed, and keep our ability to move quickly and adapt.
To establish a baseline we gathered feedback and took notes to mirror how engineering operated, with the intent to improve communication and collaboration across those teams.
QUALITY & COHESION
We drafted a version of Tim Van Damme’s Component Worfkflow, and modified it based on our needs. Using this hierarchy we could provide a cascading framework to lean on and standardize design without being too restrictive. It’s nothing inventive or novel but gave us just the right amount of structure
Core spec guidelines consisting of grid, spacing, color, type, etc.
Base elements (avatars, iconography, etc.) — basic components that inherit specs from it's parent category (Blueprints).
Block elements (buttons, inputs, forms, cells, etc.) combined with base elements that inherit specs from its parent category.
Structures (cards, modals, sidebars, menus, etc.) are composed of a combination of base and block elements.
Environments (composed of blocks and structures) are the views these exist in.
With this system set in place, we took existing UI to test against and applied these rulesets, shared our results/process with the rest of the team, and received buy-in with product + engineering to operate this way going forward.
Some nice things we got out of this:
Using the framework above we then defined a production workflow that leveraged a combination of tools, allowing us to:
Symbols, text-styles, shared libraries
Anima: Sketch plugin
Version control + shared libraries
Our workflow was nothing special, but at the least captured a bit of our development and inner workings as a team
Description: Quick-fire iterative improvements
Working with financial partners has its fair share of variables, which made it a bit tricky on us mid-process. But with that said, our V.1 financing product was live and it was time to examine our initial metrics and iterate.
After parsing through early top of the funnel numbers, our head of product distilled the data and highlighted two issues to investigate:
Primed with our high-level goals, we dug further into our product metrics:
The numbers/data above only told one-half of the story, we needed to understand “why” and were there any other things we haven’t considered. For this we interviewed users and ran a few scrappy usability tests to get an idea of what made sense/what didn’t, were there any specific difficulties they ran into, etc.
USER FEEDBACK & USABILITY NOTES
One of the more obvious fixes to a low initial number of applicants was increasing visibility and targeting the top of the ‘buyer’ funnel (where, of course, the highest number of users were). In our case, the marketplace entry— nice.
However, this only solved for vanity metrics. You can superficially influence volume, but driving users with intent is what’s really important here. One interviewee noted: "I'll browse sometimes, but I just want to take a look around."
Driving users with intent, although, was a multifaceted problem (customer acquisition, demo, supply, seasonality, etc.) and couldn’t be solved with a silver bullet. Instead, we operated within the constraints of the project and focused on what we could affect through copy and design.
We zoomed out and took a high-level view of the ‘buyer’ path, and with the help of our content writer, drafted messaging that progressively became more detailed and granular depending on where the individual was in the product. Doing so, we were at least able provide information that was more relevant and useful as people shopped.
At this point, we gathered insights from metrics/user interviews + testing and prioritized based on frequency, level of difficulty, and rough estimates for implementation.
After implementing our adjustments we were able to triple the number of users entering the application, but more notably bump our…
It was, of course, important to tackle these issues as a business objective, but even more important to ensure people were given proper education around financing, clarity to make informed purchase decisions, and a no-nonsense application process. After all, buying a car and getting finanicing can be stressful enough.
Description: Designing for simplicity, transparency, and trust
Improving product lists
Designing for trust