Sole designer on a two-person team — research to working product in weeks, not months.

I owned the full design process: field research, flow definition, prototyping, usability testing, AI conversation design, and iteration. I also built using Figma and Figma Make for exploration, then Cursor + Claude Code to turn validated designs into working screens on Supabase/Vercel, with n8n orchestrating the WhatsApp agent.

Danilo Trivelatto owned the backend, the platform migration and the pricing calculation engine. Where the two overlapped, the pricing model, we worked as a single loop.

What this changed: AI tooling didn't replace the UX process — it collapsed the distance between "validated prototype" and "testable product." Instead of testing static Figma prototypes for months, I was testing the real system with real employees within weeks of each design decision. Every usability finding could ship as a fix in days.

Quick-print shops sell speed, but their own operations are the slowest thing about them.

Brazilian quick-print shops run two sales channels at once: a walk-in counter and a flood of WhatsApp messages. On my first visits I watched the person on shift handle both, and lose both.

What was visible from day one:

The operation had no system underneath it. Orders lived in Trello, products in Google Sheets, customer history in people's memory. Every handoff between those places was a place where information stopped.

WhatsApp was 24 hours behind. An employee showed me a backlog of ~30 messages from the previous day, none with a first reply. For a business selling same-day printing, a customer waiting a day for "hello" is a customer already walking to a competitor.

Those two were obvious. What wasn't obvious was why nobody inside the shop treated them as problems, and that took hours of watching to understand.

A pilot client, no historical data, and a pricing model that existed only in people's heads.

• No baseline data — so I built one. The shop had no metrics on response time, order volume per channel, or quote accuracy. Every "before" number in this case came from direct observation and stopwatch timing during my visits, with 8 employees.

• A live business. I couldn't pause operations to test. Every usability session happened between real customers, with real orders.

• Undefined pricing logic. Nothing about how prices were built existed on paper. The product couldn't be designed until that was extracted.

• Pilot stage. Fellow is live with one client; results are from that pilot, not a broad rollout.

Every number in this case study should be read against those four constraints.

I spent days inside the shop before drawing a single screen.

Across multiple visits, I shadowed counter service, watched WhatsApp conversations unfold, followed orders into production, and sat with the owner during the daily delivery phone-tag with riders. I documented every handoff where information was retyped, remembered, or lost.

Timing changed the story. Staff described quoting as "a minute." Timed against real interruptions, it took 4–6.

No first response

I mapped where the 24-hour delay actually came from: nobody owned the inbox. Messages were answered by whoever had a free hand between walk-ins.

No one could explain the prices

A single business card can be configured 240 different ways: format, dimensions, paper type, finish, special cuts, quantity, art. Stickers and banners stack the same way.

I asked how a price was built and never got the same answer twice. Quotes came from printed price guides with fixed values, plus whatever the attendant remembered. When a request fell between two entries in the guide, the number was decided on the spot.

Nobody saw this as a problem. Staff were proud of knowing the prices by heart - the pain was invisible from the inside, and only surfaced when I timed the task.

What it meant for the project: the pricing rules existed, but only as tacit knowledge spread across the team. There was nothing to design from, and nothing an AI agent could query. Pricing became the blocker for both surfaces of the product.

Three contexts, one order

Design implication: one order object had to behave correctly in a dense desktop CRM, in a natural-language WhatsApp conversation, and in the reports the owner reads to run the business.

The first version slowed people down. Testing told me where.

Initial rounds of in-person usability tests with shop employees exposed flows that were delaying the operation. Sessions were interrupted by real customers, and that was the point: the interruption is the operating condition. A flow that only works uninterrupted doesn't work at this counter.

Example finding → fix:
• Finding: Staff abandoned order creation mid-flow when a walk-in customer arrived, losing all entered data.
• Fix: Auto-saving draft orders, resumable from the dashboard.
• Result: In the following sessions, no order was lost to an interruption. Staff stopped restarting from scratch.

Three rounds of testing reshaped the order flow before a single screen was considered final. The time saving those changes produced is in Outcomes.

But testing exposed a second problem, and it wasn't in the interface.

Second finding → fix:
• Finding: The structured order flow was correct and still too slow for simple counter requests — a copy job did not need the full CRM.
• Fix: A parallel Quick Order flow: Customer → Products → Payment.
• Lesson: The most complete workflow is not always the best workflow.

The next problem wasn't in the interface — it was in the platform behind it.

Fellow started in Lovable, which turned early ideas into a working prototype in days. That speed was real, and it's why the first usability tests happened weeks ahead of schedule.

The ceiling appeared with the pricing engine. As the system grew, each change started breaking parts that already worked - the codebase was there, but we had no direct control over it, and every fix risked something else. A prototype platform is built to show an interface; it isn't built to hold the logic underneath one.

The migration was Danilo's call to make and mine to validate. He owned the architecture; I owned whether the product still behaved the way the tests said it should. We moved to Cursor, gaining the flexibility and implementation control the pilot needed.

The lesson: prototyping speed and production foundation are different problems, and using one tool for both costs a migration. I'd start in Lovable again, the weeks it bought in early testing were worth it, but I'd plan the exit from day one.

With the foundation settled, the design decisions below are the ones that shaped the product itself.

The ORDER BOARD: keep the kanban, rebuild what's under it

Before: Orders lived in Trello. It worked as a team board, but nothing underneath it worked:

- Customers and products couldn't be linked to records: everything was typed by hand.
- Unrelated information, like invoice generation, was mixed into the same board.
- The team retyped the same data constantly.
- The business couldn't answer basic questions: how many orders last month? how much did we bill this year?

AFTER

Decision: Orders now pull from a real customer base and product catalog. Every order gained a code, a history, and a report. I added two views Trello never had: by order status and by employee, giving the manager a full panorama.

Why it mattered: the shop moved from "we think it was a good month" to knowing exactly what it sold, to whom, and by whom — without a single day of retraining.

Two flows, because the counter has two speeds

The full order flow was right for a business card with seven variations. It was wrong for someone who walked in wanting forty copies.

So Fellow has two: the complete workspace, and Quick Order: three steps, nothing else. Customer → Products → Payment.

Design principle: the correct amount of interface depends on the context of use, not on how much the system can do.

Quick Order is where most of the time saving in Outcomes came from.

The pricing engine: the heart of the CRM

Before: every quote was rebuilt from scratch. The spreadsheet below held product data, not pricing logic. The logic was in whoever happened to be at the counter.

AFTER

Decision - and how it was built: This was the most challenging part of the project, and the one that most required design and engineering to work as a single loop.

How the rules came out: the owner couldn't describe a pricing rule, but he could price any order I put in front of him. So I stopped asking and started reconstructing: I brought past orders, asked him to price them out loud, and wrote down every "it depends." Three sessions in, the depends started repeating — and the repetitions were the rules.

• The variation matrix. I designed a model where each variable: format, size, paper, finish, special cuts, quantity, art - carries its own price component, and the composition of those components produces the final price. The hard part wasn't the math: it was deciding which variables were independent, which ones override each other, and where the shop's exceptions were real rules rather than habits.

• Danilo Trivelatto turned the model into a calculation engine that holds up under real conditions: rounding, rule precedence, and the performance needed for both the CRM and the AI agent to query it in real time. Several rounds of attempts and failures were needed before it was correct.

This is the module that broke Lovable. It's also the module that made the whole product possible.

Designing a real customer database

The hardest interface had no screens

AFTER

Bring the conversation inside the CRM. Instead of treating customer service as a separate tool, the WhatsApp thread lives next to the customer, their orders, the product catalog and the payment status. New messages surface inside Fellow.

Design the conversation before building it. I mapped the full flow in FigJam: service guidelines plus the range of situations that actually occur — vague requests, mid-conversation changes, price objections, customers who vanish and return days later. The open questions were: how should the conversation open, what tone should the agent hold, and what must it collect before it can quote.

Let the agent close the quote, not the sale. The agent builds the quote from the same pricing engine the counter uses, then hands the conversation to a human for validation. Returning customers are identified by phone number and greeted by name from the first message.

Pause AI. Staff take over instantly by typing a message or pressing a button.

Insights gathered during field research also uncovered opportunities that go beyond the scope of the first release. Rather than adding them prematurely, I proposed validating the core product with more print shops first and using those learnings to prioritize the next phase.

Recommended Phase 2 opportunities:
Validate Fellow with additional quick-print shops: to identify shared patterns and business-specific differences.
Payment integration: verified payment status instead of receipt screenshots.
Delivery & rider experience: connecting dispatch, drivers and delivery status to the order lifecycle.
WhatsApp voice-message support: reflecting how customers actually communicate.
Full-funnel analytics: from first contact to quote, payment, production and delivery.

The first item is the one that matters. Everything in this case study was learned inside one print shop. Until Fellow runs in a second and a third, I treat these patterns as hypotheses that held up once.

Fellow’s first phase transformed a fragmented operation into a connected workflow. Phase 2 is about taking what worked at Gráfica SF, testing it across more businesses, and turning those learnings into a product that can scale.