Alex Jolley
Hi, I'm Alex - a design leader, product engineer, and software enthusiast.
I have 15 years of experience putting care and purpose into everything I build.
I believe that good design is a competitive advantage, and having a strong design org is a catalyst that drives business success. I can help you build and scale that catalyst.
Here are some of the projects I've been building in my free time:
blipJar (beta)
tudo
QuickTick
MacZones
airmark
ResTest
Signals
Patch
Case Studies
The Arivo Design System (ADS) is the shared visual language behind Arivo's products — a token-driven foundation and component library I built to replace years of drift with one source of truth that design and engineering could both rely on.
The Problem
Arivo's products had grown faster than any shared foundation. The same button, alert, or input existed in a dozen near-identical variants, and nothing agreed on colour, spacing, or type. Handoff was slow and unreliable — engineers rebuilt patterns from scratch because there was nothing authoritative to point to. As the team and the product surface scaled, the absence of a single source of truth quietly taxed everything.
My Approach
I built ADS end-to-end on top of Vuetify, so it aligned with what engineering already shipped instead of fighting it. I started at the foundation — a full token layer for colour, type, elevation and strokes — then rebuilt every component on those tokens, so a single change could ripple everywhere consistently.
Naming mattered as much as values. Tokens are semantic — bg-surface-300, text-secondary, border-error — so intent is legible in both Figma and code, and the two stay in lockstep.
Foundations · Colour
A Tailwind-slate neutral base carries the interface; Material-derived accents handle brand and status. Every value is a named, semantic token.
60+ tokens across surfaces, text, buttons, shapes, borders and status — on top of a full primitive palette.
Foundations · Type
One typeface — Inter — on a Material-derived scale. Size, weight and letter-spacing are tokenised, so headings stay consistent wherever they appear.
Body · Inter Regular 16/24 anchors long-form text beneath the scale.
Foundations · Elevation
Soft, low-opacity shadows on a tight offset — enough to lift a surface without the heaviness of a big drop shadow. Two tokens cover the whole UI.
Foundations · Strokes
A neutral hairline for structure, status strokes for feedback, and a signature soft gradient stroke for emphasis — all on generous radii.
The Component Library
Every component is built on the tokens above, so brand, states and spacing stay consistent — and one token change ripples through the whole set. A sample, rendered live from ADS values:
25+ components ship in ADS — buttons, alerts, banners, chips, checkboxes, radios, switches, text fields, selects, comboboxes, steppers, tabs, snackbars, tooltips, pagination, progress and data tables.
The Outcome
ADS is now in active use across Arivo's products. New screens start from agreed components instead of a blank canvas, handoff carries a shared vocabulary, and consistency became the default rather than a cleanup task. It's the foundation the design org keeps building on — and the groundwork that made moving design handoff onto version control possible.
The account overview is the densest screen in Norman, Arivo's loan-servicing platform — the one a collections agent lives on all day. Everything about a loan converges here: two people, a financed vehicle, protection contracts, a complete financial picture, and a running log of every call. The job wasn't to add anything. It was to organize what was already there so an agent could read a whole account in seconds and spend their attention on the borrower, not on hunting.
The Problem
A servicing account is a lot of object at once. On this one screen an agent needs to see who the borrowers are and how to reach them, the collateral securing the loan, the GAP and service-agreement contracts, a full amortization and fee breakdown, key dates, and the entire history of contact — all live, all at the same time. Earlier iterations laid it out as an undifferentiated wall of fields. Everything was present, but nothing was prioritized — so the screen technically worked and practically slowed people down.
The whole screen
Here's what an agent actually opens — the account overview in full. It's a lot at once, and that's the point: every piece dissected below is carved straight out of this one screen.
My Approach
I treated it as an information-architecture problem rather than a layout one. I inventoried every data point on the screen, grouped each by the question it answers, ranked the groups by how often an agent actually reaches for them, and then chose a disclosure mechanism to match — always visible, one glance down, or on demand. The design system supplied the components; the work here was deciding what deserves the agent's eyes first.
What the screen has to hold
Before moving anything, I counted it. One account resolves into six distinct domains — roughly a hundred discrete values, plus an open-ended activity log.
Six domains on one surface. The count is the argument: at this density, grouping and hierarchy aren't polish — they're what makes the screen usable at all.
Zoning the screen
Each domain became a region with a fixed job, laid out along the agent's natural reading path — identity first, then collateral, then the financial detail — with the activity log pinned to the right so it never scrolls away during a call.
Colour marks the domain — blue identity, amber collateral, slate money, green activity. The persistent rail on the right is a deliberate break from the reading order: contact history has to stay put while the agent works everything else.
Ordering by the agent's job
Density only hurts when the wrong things are loudest. I ranked every group into three tiers by how immediately a collections agent needs it — and let that ranking decide what's shown outright, what sits one glance down, and what waits behind a tab or the side panel.
The tiers map straight onto the mechanisms below: tier 1 is always on screen, tier 2 is grouped detail, tier 3 lives behind the tabs and the side panel.
Three layers of navigation
Rather than one overloaded menu, the screen uses three navigation mechanisms — each with a different job, so an agent always knows where a given control lives.
Zone in focus · The people
Each person compresses to a scannable card, rebuilt here from the real screen: name and how to reach them up top, sensitive IDs de-emphasized at the bottom, and status flags — pronouns, language, an address warning — surfaced as chips so an agent adapts to the call without reading prose.
- (801) 888-8888
- arnie.boy@gmail.com
- 12345 South Dredge Lane, Sandy, UT 84094 · 7:09pm local
- The Government of California · (712) 777-7777
- (801) 999-9999
- carol.schwarz@gmail.com
- 12345 South Dredge Lane, Sandy, UT 84094 · address flagged
- No employment on file
Two people, side by side and identically structured — so an agent's eye lands on the same fact in the same place whether they're looking at the borrower or the co-signer.
Zone in focus · The money
The financial picture is the largest domain, so it gets the most structure. Four headline numbers answer “where does this account stand right now,” then the detail fans out into four labelled groups — payments, balances, fees, dates — instead of one long column. Values that have moved get an explicit original → current chip.
Same data, grouped. Splitting one long table into four labelled columns lets an agent jump to the number they need — a balance, a fee, a date — without reading the ones they don't.
Zone in focus · Collateral & protection
What secures the loan and what protects it sit together: the vehicle summarised in a single line, then the two contracts an agent might be asked about mid-call — each with its status and the handful of fields that actually come up.
Collateral and contracts are tier-2 detail — grouped and ready, but never competing with the borrower and the balance for first attention.
Zone in focus · The activity rail
Every account carries a conversation. Notes are timestamped, tagged, and attributed, with the composer pinned to the top of the rail — so logging a call is one step, and reading what happened last is the first thing an agent sees. This is the one zone that stays fixed while the agent moves through every tab.
Tags turn a free-text log into something filterable — an agent can pull just the recovery calls, or every no-answer, without reading the whole thread.
The Outcome
The account overview now holds everything about a loan on a single surface, but it reads as a hierarchy instead of a data dump: the borrower and the balance land first, the full financial detail sits one glance down in labelled groups, and the tools and history wait exactly where an agent expects them.
Work
The Problem
Design-to-developer handoff at Arivo was a persistent source of friction. Specs changed mid-development, versioning was informal, and developers had lost trust in what they received — reasonably so. About ten handoff changes were happening per month, and engineering time was getting absorbed by rework that shouldn't have been necessary.
My Approach
I saw the problem as infrastructure, not process. I built an internal tool connecting our Figma files and design system to Git, giving every handoff a maintained version history and a reference point developers could actually rely on.
The harder part was the culture shift. I trained the design team on Git fundamentals — not just the mechanics, but why version control matters and how it's useful outside of work too. I wanted it to feel like professional growth, not a new rule to follow.
The Outcome
Handoff changes mid-development went from about ten per month to zero, and stayed there all year. Designers also came away with a real fluency in versioning and systems thinking — skills that make someone a stronger product builder over time. It started as a process problem and ended up being a meaningful piece of the team's development.
The Problem
The team was fragmented. Designers were juggling multiple PMs and developers across projects that had nothing to do with each other, and the constant context switching was killing momentum. Projects dragged on for months not because the work was hard, but because the structure around the work wasn't set up for focus.
My Approach
I restructured how the team was organized so projects aligned with each other rather than pulling in different directions. Sprints got reshaped around related work, and I started planning further ahead so designers weren't constantly reacting. I also set clearer expectations with business and user stakeholders around what could realistically interrupt a sprint — which meant fewer emergency requests, less back and forth, and more predictable output.
The Outcome
Projects started landing on time. PMs and stakeholders now know what to expect from the team each week, which has changed the dynamic from reactive to collaborative. The bigger win is what opened up as a result — the team now has dedicated time for research and user interaction that simply didn't exist before.
The Problem
Designers at Arivo weren't allowed to talk to users. Even though our users were internal employees within the company, there was a standing rule keeping them out of the design process entirely. The intent was probably to protect people's time, but the effect was software being built without the people it was built for.
My Approach
I challenged it directly. I brought together the heads of each department and made the case with data, sharing research showing that user involvement improves both software quality and the satisfaction of the people using it. I also framed it around expectations: users want to be heard, and excluding them was working against that.
Once the right people were in the room, it wasn't a hard sell. The data helped, but so did the fact that this clearly benefited everyone, not just the design team.
The Outcome
The ban was lifted. Research and interviews started, and user satisfaction with the software went up 86%. The more lasting change is cultural though. There's now a shared expectation that users belong in the process, not outside of it.
The Problem
When I joined Arivo, the design team was two UX designers. That was it. Graphic and marketing design lived in other departments, brand had no real owner, and there was no infrastructure for things like design systems or internal tooling. The team was capable, but it was set up to execute tasks rather than drive outcomes.
My Approach
I treated it as an org design problem. The first move was redefining the existing UX designers as Product Designers, which wasn't just a title change. It came with broader ownership and higher expectations around product thinking. From there I built out the branches the team was missing.
I hired senior graphic design talent to bring marketing and operational design in-house, creating a team that could own the full visual output of the company. I stood up a Brand Design function to take on the foundational work that had never had a home: logo, voice, color, typography. And I built a Design Engineering team to maintain our design systems, handle one-off technical projects, and support internal tooling.
The Outcome
The team went from two UX designers executing tasks to a full design department with distinct practices and senior leadership across each one. Design became something the company could actually rely on at scale, across marketing, product, brand, and engineering.
The Need
Our brand assets lived in Google Drive folders, with files scattered across different locations and no reliable version control or history. The team couldn't confidently tell which file was the latest or which version had been approved. Finding a file was only part of the problem; knowing whether it was the right one was the harder part.
My Approach
I built an internal Digital Asset Management (DAM) platform for the brand design team. Rather than treating it as another place to store files, I brought the asset workflow together: upload, storage, tracking, review, approval, and archiving, all in one platform for assets from across the company.
The focus was giving the team a clear way to manage an asset through its lifecycle, so review and approval were part of the workflow rather than context someone had to remember. All company files and data stayed internal.
The Outcome
The team now has one internal place to manage company assets from upload through review, approval, and archiving. Tracking and approval sit alongside the assets themselves, giving the team a shared workflow for answering the question that scattered folders couldn't: which file should we use?
The Need
I wanted to give our designers more room for the work that draws on their strengths: spending time with users, exploring ideas, and building on each other's thinking. Reducing busywork was an opportunity to make that time available and bring more of the team's creativity into the work.
My Approach
We introduced Claude Code alongside MCP connections to tools the team already used. That brought AI into our existing workflows, where it could help with synthesizing user research, building rapid prototypes, and preparing demos.
Training was an important part of the rollout. I taught designers the basics of HTML and CSS so they had a foundation for working with code. As that became part of our practice, we started handing off more work in code, moving beyond the canvas to communicate designs through working interfaces.
The purpose was to reduce repetitive work and make room for more time with users, shared exploration, and collaboration. We wanted the team's creative energy going into ideas and conversations, with less time spent working in silos.
The Shift
AI became a practical part of research synthesis, prototyping, and demos, and code became a bigger part of design handoff. The training gave designers a foundation for participating in that shift.
More time with users and more opportunities to create together remained the goal. Those priorities guided where we introduced the tools and what we wanted the time saved to make possible.
Experience
-
Head of Design
Arivo2023 — Present
Building and scaling the design org and shaping product direction across the software organization.
-
Lead Product Designer
BOOM Interactive2022 — 2023
Led design on core products and mentored a growing team of designers.
-
Sr. Product Designer
Keller Williams2021 — 2022
Designed and shipped features end to end, from sketch to release, while growing the team.
-
Lead Designer
FNX Fit2019 — 2021
Lead on product, brand, and visual design for the multi-brand umbrella.
-
UX Designer
Day One Logistics2017 — 2019
UX design for freight logistics tools — research, flows, and interfaces.
-
UI / Web Designer
AdvancedMD2015 — 2016
Designed web and software UI for medical practice management software.
-
Web Designer
FATFISH2013 — 2015
Designed and built websites for a wide range of clients.
-
Graphic Designer
Sizzling Platter2011 — 2013
Print and brand design across a portfolio of restaurant brands.