Inheriting a Design in Motion — Continuity, Systems, and a Platform Built to Scale

When I joined the 1-800Accountant engagement at Tech9, I hit the ground running — and the ground was moving. I was new to the company, new to the accounting industry, and immediately dropped into active design sprints with deliverables due and no roadmap for where anything lived. Figma files sprawled across years of work, decisions were made fast, and the team moved faster.

Tax season was approaching, and it was an immovable deadline — no significant workflow changes could ship during the busiest period of the year for the platform, which meant everything critical had to be completed before the calendar forced our hand. I didn't know the acronyms, the processes, or the history of years of design decisions baked into the product. What I did know was how to stay above the weeds, read a room, navigate bold personalities, and get work done. That experience was the only orientation I had — and it was enough.

The foundation I inherited was the work of a designer I came to deeply respect. His approach was methodical and intentional — nothing existed without a reason, which meant I was never untangling arbitrary decisions. The challenge wasn't the quality of the work. It was the geography of it. Nearly six years of design lived across multiple Figma files — one for each major product area — and within those files, numerous pages. Components were linked to the original library, to local component pages, and in some cases back to older files entirely.

Combing through every file to find the source of truth for each section forced me to develop a comprehensive understanding of the product faster than any onboarding document could have provided. What looked like disorganization on the surface was actually a complete history of every decision the product had ever made.

The harder challenge came when sections like Documents, Calendar, and Invoicing — well designed but naturally dated compared to the newer dashboard — needed updating. Finding the latest version of a design that may already be in production wasn't the taxing part; it was selling the business on modernizing it to current components and keeping all of it within developer scope that required a level of finagling that became its own skill set.

Beneath the surface of the product lived a different kind of challenge — one that didn't show up in any design sprint but touched every single one. The component library and design system were the backbone of the entire product, and both needed serious attention. The internal library was thorough and expansive — years of components, variants, and documentation built up over the life of the engagement. But as the product evolved, so did its needs.

Newer sections introduced evolved components that didn't always reconcile cleanly with older designs that were still in use and still valid. Decisions had to be made constantly: is this worth updating? What does modernizing this section cost in time, and what does leaving it cost in consistency? On more than one occasion, a newer component slipped into developer documentation before those questions were resolved, and the design and development teams would meet to negotiate the path forward.

The audit took weeks — digging deeper into the Figma archives revealed more list view variations, each section having developed its own style and data requirements over time. The result was two distinct but complementary bodies of work.

The AI Tax Organizer was the product's most impressive feat of automation — and the simplest experience to interact with. Users dragged and dropped their prior year's return or current tax documents into a loader, and an AI agent handled the rest, auto-populating fields from the uploaded documents and surfacing only the questions it couldn't answer on its own. No redundant data entry, no navigating a wall of input fields. The system asked what it needed and nothing more.

Alongside the organizer, I was responsible for originating several features from scratch — among them, a suite of in-app dashboard ads that walked a careful design line. They needed to be noticeable without being obnoxious, informative without feeling like an interruption. Unlike external advertising that blinks and claws for attention, these were styled to feel native to the product — clear, calm, and always pointing the user toward help or an immediate next action.

The dual user base — external small business owners and internal specialists — shaped nearly every design decision, though the tension between the two was less about conflicting needs and more about permissions. The same design served both audiences, with certain features simply switched off for external users. One interface, two experiences, no seams showing.

And underneath all of it, the dashboard was quietly revealing its next challenge. Built originally to guide a first-year customer through the rhythm of the tax year, it was never designed for the person coming back for year two. Dashboard 2.0 wasn't just a visual refresh. It was a fundamental rethinking of what the product owed a returning customer.

Perhaps the most forward-looking work happened quietly alongside everything else. As the engagement matured, I began spearheading a collaborative effort to pioneer an agentic front-end practice — connecting Claude to GitHub to rewrite production JSX files, replacing AI-generated UI with design system components while preserving the underlying back-end logic.

It was a proof of concept that became a conviction: that the next evolution of design isn't just about what a designer creates, but about what a designer can orchestrate.

The design system I built wasn't just a reference document — it was the foundation that made that kind of AI-assisted production possible. A system an agent could follow. A source of truth precise enough to automate against. Design has always been about solving problems at scale. The tools for doing that are changing faster than most teams are ready for. I intend to stay ahead of that curve — and bring teams with me.

Taking over design responsibilities for 1-800Accountant was a genuinely new experience for me. For years I had started projects from scratch — rarely inheriting a foundation someone else had built. It required a mental shift, and not just for the obvious reasons like learning an entirely new industry. It was the granular things too: matching established styles, honoring patterns I didn't create, working within a color language that wasn't mine.

That might not sound taxing — and yes, I did that on purpose — but we all have a comfort zone. A personal style. Even within the boundaries of a company's brand guidelines, there's usually room to put your own flavor on things. This engagement asked me to set that instinct aside and make someone else's vision work as well as it possibly could. That turned out to be one of the more valuable exercises of my career.

My time with this client has come to an end. And as straightforward as designing tax and accounting software might sound from the outside, it was anything but. It was challenging, rewarding, and worth every "what does that acronym mean?" moment along the way.