The bet

I bet we'd get more leverage from one well-designed reporting surface than from a backlog of twelve disconnected feature requests.

Context

When I took the lead on Accountant Console reporting at BILL in 2024, our 700+ partner firms were asking us for reports. Different reports, different formats, different cuts of the same data. The backlog had a dozen requests and was growing every quarter. Each one was a feature ship. None of them was a system.

The temptation — and the path of least resistance with leadership — was to clear the queue. Ship the reports, close the tickets, move the bar chart on the OKR dashboard. The cost of that path was a console that would look more like a filing cabinet every quarter, and a team that would be staffing report requests forever.

Decisions I made

1. Treat reporting as one surface, not a queue of features

   I argued for designing the underlying insight model first — what data, what cuts, what defaults — and treating individual reports as configurations of that model. The unpopular call. It cost us two months of optics on the backlog burndown chart.

2. Design for the firm size that hurts most, then scale up

   We had data across 700+ firms but kept hearing loudest from the largest. I pushed to design for mid-market firms (10–50 accountants) first — they had the clearest mental models and the least patience for bad defaults. Their feedback compressed the design loop.

3. Ship the framework before the polish

   Shipped a deliberately rough v1 in week 10 to validate the model with five design partners. Half the system was placeholder. That call surfaced two structural decisions we'd have shipped past in a polished build.

What I'd do differently

I'd have pulled engineering into the framework conversation two weeks earlier. The model decisions had implementation consequences they could have flagged faster, and I lost a sprint re-cutting the IA after a data-architecture conversation I should have had on day one.

I'd also have invested earlier in a written narrative for non-design leadership. The framework bet was easy to defend in a design crit and harder to defend in a roadmap review where the unit of credibility was "tickets closed." Owning the org communication is part of the design work at this level.

Context

Bridge was Instructure's young corporate-training product. The MVP let trainers build courses, but the way it bundled them into programs was rigid — learners had to take everything in order, authors had no way to visually organize content, and learners couldn't see why a program mattered or what came next.

By 2015 the program was real enough to attract enterprise customers and broken enough to lose them. Two of our biggest accounts were threatening not to renew in September unless authoring got fixed. I was paired with Todd Erickson (Senior PM) to lead the redesign.

The bet

The team wanted a simpler authoring wizard. I bet that what authors actually needed was more control — a flexible workspace, not a guided rail.

Decisions I made

1. Design the author and learner experience as one product, not two

   Most LMS work treats authoring and learning as separate jobs. I argued they were one: every author was building a path, and every learner was walking it. We designed the dual experience together — what an author saw and what the learner experienced were the same thing in two views.

2. Trust authors with the power tools

   The "simpler wizard" path was politically safer and would have failed. Authors at our largest accounts were instructional designers — power users with real judgment. The redesign gave them a flexible workspace with sections, drag-and-drop reordering, and a card/list view. Less hand-holding, more leverage.

3. Ship the prototype to the at-risk customers first

   I built a clickable prototype in Sketch + InVision and tested it with the customers threatening to walk before we built anything. Their feedback re-cut two flows. By the time engineering started, the design had already passed the renewal interview.

Selected screens

A note on the team

This is some of the work I'm proudest of, and a lot of why is the people. Todd Erickson on product, the broader Instructure design team in the offsite where we sketched the early concepts — these became lifelong friends, not just shipmates. The lesson I keep taking forward: the work is durable because the relationships were durable. Hard things stay possible when the people stay close.

What I'd do differently

I'd have invested earlier in a written narrative for non-design leadership. The "trust the authors" bet was easy to defend in a design crit and harder to defend in a roadmap review where the unit of credibility was "simpler is safer." Owning the org communication is part of the design work, even at IC level.

Context

In late 2016, Josh Coates (Instructure CEO) brought the Bridge team a question: could the same platform that handled corporate training also handle talent management?

It was a real question. Bridge had a happy customer base that loved it for L&D. Bolting on a different product line could either build a new revenue engine — or break the experience the existing customers had paid for. I was given a Gartner and Bersin whitepaper, a week of research, and a brief: figure out the skill-assessment piece of this new product. The work would eventually become Bridge Perform.

The bet

The way to add a new product line inside Bridge without breaking what people trusted was to treat the new thing as a system — three connected user experiences (Admin, Manager, Employee) sharing one data model — and to validate it with paying prospects before a line of code was written.

Decisions I made

1. Design the three users as one system, not three features

   Admin configures skills, jobs, and assessment templates. Manager requests assessments and reads team-level data. Employee self-assesses and requests assessments from peers. Each role had a different surface, but all three read and wrote to the same skill model. Designing them as one product meant the Admin's configuration choices shaped what a Manager could see and what an Employee was asked. Three roles, one truth.

2. Make the org chart the navigation, not a feature

   Leadership wanted "a way to see the org at a glance." That's usually a request for a chart on a dashboard. I argued the org chart had to be the primary navigation for the Manager and Admin experience — every question about skills started with "for which people?" If the org chart is decoration, navigation falls back to lists and filters. If it's the navigation, the whole product gets simpler.

3. Validate with paying prospects before writing code

   We took the prototype on tour. Several companies said "we'll pay for this right now" before production code existed. The taste decision was confirmed by checkbooks, not internal politics. We caught the parts that didn't translate from prototype to daily-use expectations, and cut them before engineering invested in them.

Selected screens

A note on the team

Four designers and a PM. We critiqued weekly with the rest of the Instructure design org. The reason this shipped fast wasn't AI (it was 2016) — it was the cadence of feedback. Smart people who would tell you when something was off, on the same day you put it up. The kind of team I keep trying to recreate.

What I'd do differently

I'd build the org-chart navigation in week one, not month three. Once we shifted to "the org chart IS the navigation," every prior screen got simpler — and the screens after got designed faster because the structural decision was already made. Lead with the structural decision, not the feature decisions.

Context

In the summer of 2022, the founders behind Verdi had a thesis: product teams were running discovery the wrong way. The methodology was well understood — Continuous Discovery, Learn Kickoffs, opportunity mapping. The tooling wasn't. Teams ran sessions in Miro and FigJam with a designated facilitator and lost a third of every meeting to setup, exercise-explanation, and gathering inputs.

Verdi packaged the methodology into the product itself. A real-time, multiplayer facilitation tool with a built-in agenda, timed exercises, and AI that captured and structured the team's contributions in the moment. The team showed up, the meeting ran itself, and the shared understanding was the output — not homework due Friday.

This was four months before ChatGPT launched. The AI tooling we had access to was real but rough. The product had to be designed around what the model could reliably do — listen, summarize, structure — not what the science-fiction version could promise. They brought me on as the founding designer with one brief: get us to a working MVP we can put in front of investors in eleven weeks.

The bet

Make the meeting structure the product. The team only had to show up — the methodology was already in the room.

Decisions I made

1. Pick a sharp methodology, package it as the product

   Most discovery tools assume the team brings their own facilitator. Verdi shipped the methodology — Goals, Opportunity Brief, Brainstorm Insights, Map Insights, Define the First Experiment — as a timed, guided session with built-in exercises. The structure was the value. Generic "any meeting" tools (Miro, FigJam) had infinite flexibility and zero opinion. We had one opinion, executed sharply.

2. Multiplayer-first, because the product was useless solo

   Designed for 4–7 people in a room or on a call at once: shared real-time state, avatar attribution, advance-together pacing, a "Saving" indicator that made the collaboration legible. The product had to feel like a live room, not a doc. We made the multiplayer affordances central, not an upgrade tier.

3. AI captures the team — it doesn't replace them

   The 2022 models couldn't reliably generate insight. They could listen, structure, and synthesize what the team said. We built Verdi around what the model could honestly do, with citation back to who said what, edit affordances on every AI output, and zero "the AI thinks…" theater. That honesty was what got product teams to trust putting their actual thinking through the tool.

Selected screens

A note on the team

Founders who hire a designer at eleven-week pace either trust the designer fully or they don't ship. The Verdi founders trusted me to make the calls. I trusted them to defend the wedge when investors wanted us to expand it. That's the relationship that gets a product through the round — not a more elaborate brand, not a prettier deck.

What I'd do differently

We optimized for the pitch demo. Some of the magic moments that landed in investor meetings didn't survive contact with daily use — the inline suggestions were powerful in a scripted flow and noisier in a real workspace. The next time I design an AI product on a sprint clock, I'll build the "second-week experience" alongside the first-impression demo, not after.

The thing I'd repeat: the failure-mode design. Every AI product I've designed since has used the same posture — Verdi taught me that the honesty in the interaction is what makes the magic stick.

The shape of the problem

audience.io had a product, a team, and momentum. What they didn't have was a shared bar. Every designer was good. Every screen looked a little different. PMs were spec'ing the same component three ways across three squads, and the Head of Design was spending more time refereeing decisions than raising the ceiling on the work.

They didn't need another IC. They needed someone who'd already built and scaled a design system inside a growing team — and who could coach the people doing the day-to-day so the system stuck after I left.

The bet

A design system isn't an artifact. It's a way for a team to agree with itself faster — and the only way it sticks is if the leadership and the ICs are coached on the same surface.

What I was actually hired for

On paper: consult on the team and the practice. In practice, three jobs braided together — and one of them (build the system) I added, because the team's ceiling wasn't going to lift without it.

1. Advise the leadership

   The original brief. Stood up a weekly cadence with the Head of Design on team structure, hiring bar, and how to delegate craft decisions without losing the thread. Worked async with the CEO on what "design as a function" should look like at their stage.

2. Coach the team

   The other half of the original brief. Open office hours for PMs and ICs. When a designer or PM brought a question, I taught them how to answer it next time — what tradeoff they were making, where they had freedom, and where the team needed to be opinionated. The goal was a team that could ship without me.

3. Build the system — the work that emerged

   It became clear in the first month that no amount of coaching was going to land if everyone was rebuilding the same primitives in different files. The system wasn't the brief — it was the thing the brief made obvious. So I built it: tokens, components, patterns, documentation. A real foundation, not a Figma library cosplay. Every component shipped against a real screen someone was actively designing. Nothing speculative.

How I worked

Retainer, not project-shaped. The problem wasn't one deliverable — it was a quarter-over-quarter raising of the team's ceiling. Standing time with the Head of Design, async with the CEO, open office hours for the rest of the team.

Built the system in the open. No six-month "big reveal." Shipped foundational tokens and the first ten components in the first month so the team could start adopting immediately. Every component after that was driven by a real screen, not a speculative spec.

Documentation that respected the reader. Wrote the docs for the IC designer who needs to ship today, not for the future system maintainer. Every component answered three questions in this order: When do I use this? When do I not use this? What are the edge cases?

Coaching, not gatekeeping. The job wasn't to be the bottleneck. It was to teach the team to ship without me.

Selected artifacts

What it taught me

The seniority that matters in a growing design org isn't taste — it's the willingness to treat the leadership coaching and the IC coaching as the same job, on different surfaces. If the CEO and the Head of Design aren't aligned on what "good" means, no token spec is going to fix it. If the designers and PMs don't trust the system, no leadership decree is going to make them use it.

The thing that holds it all together is taste — shared, defended, modeled by the most senior people in the room. My job at audience.io was to be one of those people for a while, until the team could be it for themselves.

What I'd do differently

I'd push harder, earlier, for a single named "system steward" inside the team — the handoff would have been cleaner. And I'd have started writing the documentation in week one, not month three. Docs are the system; everything else is scaffolding.

The thing I'd repeat: the retainer shape. Patience buys depth, and depth is what makes the work survive after the engagement ends. I'd take this shape over a fixed-scope build every time.

The shape of the problem

Sendola was solving a real problem for a real audience: migrant workers moving money across borders — transfer, banking, the financial plumbing that everyone else makes hostile to people without the right zip code. They were funded. They had a brand. They had a small design team and a junior product designer carrying more than they should have been.

What they didn't have was a direction set, a backlog organized, and the muscle to drive the work all the way to launch. I was hired to be that person — senior enough to make the calls, hands-on enough to ship alongside the team, deliberate enough to bring the junior PD along instead of around.

The bet

A small team can lose months to a single un-made decision. The job of a design lead at this stage is less about drawing the right rectangle and more about removing the ambient indecision so the team can draw rectangles in parallel.

Three jobs, intentionally braided

1. Set direction

   Make the architectural and product-shape decisions that were stalling: what the surfaces are, what the IA looks like, what's v1 vs. v2, what we're not building. I made those calls in writing, with reasoning, so the team could move and the founders could push back if they disagreed.

2. Organize the work

   Took the brand designer's identity work and the junior PD's screens and pulled them into a coherent product the team could execute against. Less "redo everything," more "give everything a spine."

3. Lead the team to ship

   Pair, critique, unblock, make calls. The bar wasn't "Aaron designs the product." The bar was "this team ships a product they're proud of, on time, and gets stronger doing it." Player-coach — the same shape I ran at Kuali, applied to an external team in a hotter environment.

How I worked

Listened before pitching. Two weeks in, no decks, no redlines. Sat with the founders on the why, with the brand designer on what was already settled, with the junior PD on where they felt stuck. The biggest unlock was usually permission — telling the junior PD which of the four directions they were holding was the right one and why.

Designed the hard parts, gave the rest away. Owned the surfaces where the wrong call would cost the company — onboarding, money movement, the trust-laden moments. The junior PD took the surfaces where the right call was already in reach with a little coaching. The brand designer kept owning brand application across the whole thing.

Built three products in one engagement. Mobile — the consumer surface, where trust got built or lost. Web — the equivalent flows on a different device class, IA decisions made once and applied to both. Admin — the internal tool ops used to support customers. The one the team underrated and I prioritized, because a fintech that can't help its customers in real time isn't a fintech.

Coached the junior PD into a stronger one. Weekly 1:1s. Critique that was specific and warm. The goal wasn't that they finished the engagement having drafted screens — the goal was that they finished as a stronger designer than they started.

Selected artifacts

[ Drop in: onboarding flow (mobile) before/after · money-movement core flow · Admin console (the surface most fintechs underbuild) · one example of the brand designer's identity work applied inside product · one artifact from a coaching moment (critique doc, IA sketch, written decision). ]

A note on the company

The v1 I shipped took Sendola to market. The company has since evolved into a different product — that's the shape of early-stage work. The receipt is the launch and the team that shipped it, not the company's current state.

What it taught me

The seniority that matters most in an early-stage team isn't taste — it's the willingness to make calls in writing and own them. And bringing a junior designer along is a senior responsibility, not a charity move. The PD I worked with had real judgment that needed altitude, repetition, and someone who would say "yes, that's the right one, ship it" out loud. That's leverage. That's how a senior person multiplies themselves across a team they don't run.

What I'd do differently

I'd write the launch criteria down in week two, not week ten. Teams converge faster when "done" is visible from the start. And I'd be even more explicit about the player-coach split with the junior PD upfront — they would have asked for more reps, sooner.