QUICK READ ➤ For over 10 years as the sole product designer at TestMax, a legal test prep platform for the LSAT and bar exam, I led end-to-end design across mobile, web, and live instruction, helping grow the company 12× and establishing it as the category leader. I shaped product strategy directly with the founders and engineering lead, mentored junior designers, and coordinated cross-functionally with engineering, marketing, and growth.
12x
Total revenue growth over 3 years
75,000+
LSAT prep users acquired during platform expansion
5x
Increase in free to paid conversion rate over 3 years
$2.5M
Tutoring revenue in the first year after launch
15.3%
Peak conversion rate on bar course, over 3x industry average
Bar exam students regularly hit dead ends mid-study. A concept that isn't clicking, a rule that won't stick, an essay outline that feels incomplete. Human tutors are expensive and unavailable at 11pm. General-purpose AI tools like ChatGPT can help, but they don't understand how the bar exam is tested, what the graders are looking for, or how BarMax instructors actually teach. The opportunity was to build something that could fill that gap. Not a generic chatbot, but an AI study companion that thinks and explains the way a BarMax tutor does.
Building Solomon meant solving four problems at once. We needed to architect an agent system that could give jurisdiction-accurate, exam-aware responses at scale. We needed to design an in-product interface that would feel native to the existing course experience without disrupting student study flow. We needed to position the product clearly enough that students would understand why a specialized AI study companion was worth paying for when free tools were everywhere. And underneath all of that, we needed to design for a user base where AI familiarity couldn't be assumed. Some students had used ChatGPT for school or work; many hadn't, and many were uncertain about whether AI belonged in their high-stakes bar prep at all. The product had to teach students how to use it as much as it had to do the work.
Working closely with the CEO and head of engineering, I helped shape the conceptual architecture of the agent system, including the decision to route queries through jurisdiction-specific vector stores rather than feeding a single agent the full course corpus. This keeps responses accurate and focused while reducing token overhead. The content structure and training approach were a collaborative effort across the three of us; implementation was handled by engineering.
My primary design and engineering contribution was the in-course integration. I designed and built a dedicated chat UI: a fixed chat bubble in the lower right of the screen, consistent with familiar patterns like Intercom, that opens into a full chat overlay without pulling students out of their study flow. The interface connects to the Solomon API endpoint I integrated into the web product. The system surfaces context-aware responses informed by the student's current lesson, so explanations stay relevant to what they're actively studying rather than requiring them to re-explain their question from scratch.
To address the AI-familiarity gap, I designed the chat interface to surface concrete prompt suggestions instead of presenting an empty input field. The opening state shows examples like "Explain negligence elements," "Test me on hearsay exceptions," and "What's the rule for service of process?" The result was an interface that behaved as both a tool and a tutorial. Students who knew what they wanted could ignore the suggestions; students who didn't could use them as starting points until the tool became familiar.
I also designed and wrote the Solomon landing page in full, including the visual design and the differentiation argument against generic AI tools that sits at the core of how the product is sold. The landing page surfaced specific use cases that students were actually using Solomon for, including MBE clarity, rule tightening, essay issue spotting, and sanity checks. Naming the patterns gave prospective students a concrete sense of where Solomon fit into their study workflow.
TestMax had always offered tutoring on a limited basis, typically to bar exam students who were really struggling, but it was a manual, ad-hoc service rather than a real product. As both bar and LSAT course usage grew exponentially, we recognized a much larger opportunity. Tutoring could serve as both an upsell to existing students who needed help over a hump and a new acquisition channel for prospects who wouldn't convert to self-paced study without a human in the loop.
To test the vertical, we built an MVP with paid marketing funnels, web and mobile purchase flows, automated post-purchase messaging, and tutoring balances tracked by the hour. Tutor assignment and scheduling were handled manually. The MVP quickly validated demand and grew into a real revenue channel, but it was high-friction enough that we had to hire two tutoring coordinators to manage the operational load. Their pain points and student feedback gave us a clear list of what the full product needed to solve: scheduling, rescheduling, cancellations, no-shows on both sides, reminders, student-tutor messaging, and tutoring balance calculation.
Translating the manual MVP into a scalable product meant designing for three distinct user types, students, tutors, and administrators, each with overlapping but different needs. The challenge wasn't just the scope of the pain points to solve. It was building a system that felt like one cohesive product rather than three disconnected tools stitched together, while reusing components and flows wherever possible to avoid unnecessary engineering lift. We were also designing for an additional layer of complexity: the underlying system was being built with the possibility that the same backend could power a white-label tutoring service outside the TestMax brand. That meant the architecture had to be general enough to re-skin while feeling native to TestMax in this first instance. And we were launching on web and mobile simultaneously.
Three personas, multiple flows, many states, and two platforms added up to a lot of surface area. I started with loose wireframing to identify where the personas overlapped and where they diverged, before going deep on any one of them.
The schedule view had strong overlap. Students saw a timeline of upcoming sessions with one tutor, and tutors saw the same timeline with multiple students. Hours management and session history used identical UI with different context. Students saw scheduled and used hours; tutors saw scheduled hours with students and remaining availability. Booked-session management also used shared UI across all three personas with diverging affordances. Tutors could message students with prep materials and access phone numbers if there were issues with the meeting link. Students and tutors could cancel or reschedule within constraints. Coordinators could do the same without constraints.
Where the personas diverged, I designed for the diverging need rather than trying to force a single pattern. Scheduling lived in the same wrapper and flow for students and tutors, but the UI did different work. Students used a calendar day and time picker to book one session at a time. Tutors used a different interface to set weekly availability and one-off date overrides. Coordinators needed a zoomed-out view of every tutor's schedule, which meant a weekly view wouldn't work because of session volume. I solved that with a side-by-side daily dashboard with horizontal scroll and tutor filtering. Coordinators also got their own dedicated flows for adding and removing tutors and reviewing student-rated session quality.
During wireframing, I pulled patterns from products with relevant scheduling and two-sided dynamics, including Zoom, Google Calendar, Calendly, Uber, Lyft, and Soothe, to understand how others solved comparable problems. Once I had alignment on the core architecture, I tightened up persona by persona, starting with students. I built prototypes for both web and mobile, presented to the team, iterated on feedback, and worked within the dev team's phased agile framework so design and engineering could move in parallel. Naming conventions and flow organization mattered at this scale. Without it, neither I nor engineering could have kept the system legible. After student flows reached sign-off, I added comments and callouts for handoff and walked engineering through the spec, then moved to tutor and coordinator flows on the same cadence.
One signal from the MVP was that students wanted to evaluate the backstory and ratings of every available tutor before booking. They wanted the best tutor possible, which is an understandable instinct. My research into other tutoring services confirmed the same pattern: most allow students to browse and select up front.
That model didn't fit our business. Our tutors were effectively our employees, not independent marketplace participants, and we needed to give every tutor a fair chance to build experience and reviews. Letting students cherry-pick the top-rated tutor on every booking would have collapsed the system. So we designed a round-robin assignment for the first session, with tutor switching available after the student had completed at least one session.
The design problem was making this system legible. Students needed to understand it without feeling like the choice had been made for them. We leaned on two communication strategies. First, the assignment UI made the round-robin nature of the first session visible rather than hidden, and reinforced that all tutors were 99th-percentile scorers and thoroughly vetted to a consistent quality bar. Second, the UI changed state after the first completed session to surface tutor-switching options, so students saw the system open up to them rather than feeling locked in. The model worked. Friction dropped, and the tutor base stayed strong.
This was one of the cleanest projects I've shipped at TestMax. Strong process, good cross-functional alignment with engineering, and outcomes that matched what we believed was possible. The one thing left on the table was the broader two-way marketplace evolution. The system was architected to support a white-label tutoring service that could exist outside the TestMax brand, and we never got to build it. If we had, the design system underneath this product was already prepared to scale into it.
I joined TestMax at a pivotal moment. The team had just begun expanding from bar exam prep into LSAT, with a rough MVP in place. The CEO had a clear strategic vision: LSAT was a larger market and earlier in the legal pipeline, which meant capturing LSAT students could funnel them into the higher-stakes BarMax product later. My role was to bring real design quality to that expansion at the moment it most needed it.
The existing iOS app had been built ad hoc. The visual language was dated, the navigation treated all major functions equally without hierarchy, and the overall experience didn't scale into a coherent system. The UX, IA, and visual language all needed work. At the same time, LSAT required its own back-end architecture and content patterns that bar prep didn't have. So the work was simultaneously about modernizing what was there and building forward into a multi-exam future.
I needed to do three things in parallel: modernize the visual and interaction language of the existing bar exam app, restructure the information architecture so students could actually navigate to the most important parts of the product, and design the LSAT experience as a parallel exam type that shared a foundation with bar prep but had its own content modalities. All of this needed to set up a system that could scale to additional platforms and exam types in the future.
The original app's navigation treated all major functions equally through a left-side icon bar, with no visual hierarchy that guided students to the most important areas. The course home, lesson modules, and a blog feed all had equal weight in the UI, which meant students had to figure out for themselves where to focus. I restructured the IA around a clear primary path through the course content, with secondary functions deemphasized appropriately.
For the visual language, I modernized to a flat, contemporary aesthetic referencing Apple's HIG (which had recently moved in this direction) along with patterns from Duolingo and Chegg for educational context. The final palette landed in a restrained register appropriate for a high-stakes professional exam.
Bar and LSAT shared a lot of structural overlap, but they had real differences in study modality. Bar prep was audio-lecture focused. LSAT is a visual exam that depends on logical diagrams and reading comprehension passages, which meant the LSAT product needed video lesson types and visual question formats that bar didn't require.
I designed both products in parallel, reusing layouts and components where the overlap was genuine (the assignments list, the course home structure, performance analytics) and designing for the differences where they appeared (lesson modalities, question types, exam-specific affordances). The result was a system where bar and LSAT shared a coherent design language and architecture, with each exam expressing the patterns appropriate to its content.
Mobile was where TestMax started, but most of the company's revenue was already coming through web by way of WordPress marketing sites and checkout flows. The economics also pushed toward web. Selling courses through iOS meant 30% of revenue went to Apple, which wasn't sustainable as the courses scaled. Both factors pointed in the same direction.
Designing on mobile first turned out to be a strategic advantage when we expanded. The constraints of mobile had forced clear hierarchy and tight information design, which translated cleanly to web. The course home went through a couple of iterations as the product matured. The current version uses card-based layouts on both mobile and web, adapting to platform conventions where it mattered. Mobile uses a stacked card list with a tabbed Study and Practice nav; web expands into a multi-column layout that surfaces supplemental content alongside the primary course list. The assignments view on mobile used an interactive swipeable card pattern; on web, a more familiar list pattern was the right call. I designed for parity wherever the experience benefited from it and made platform-specific decisions where parity would have hurt. Android followed the same logic, holding parity with iOS where it made sense and following Material Design guidelines where it didn't. I maintained a source of truth in a design doc with key screens and flows so the parity work stayed coherent across platforms over time.
This was foundational work that set up the next decade of TestMax product development. Looking back, the visual modernization, IA restructuring, and multi-exam architecture all became the substrate that everything else (Tutoring, Live Classes, the community message board, Solomon) was eventually built on. The decisions held up well over a long horizon, which is the truest test of foundational work.
This project represents the fullest expression of what I do: joining a product early, owning the design end-to-end, and building something that compounds over time. Starting from a single outdated iOS app, a decade of design decisions across AI, tutoring, live instruction, course platform, and community added up to 12× revenue growth and category leadership.
