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

Brazilian quick-print shops handle two sales channels at once: walk-in counter service and a flood of WhatsApp messages. During my first visits to the pilot client, I watched a single employee juggle both — and lose both.

Three problems kept surfacing:

1. No order control. Client, product, and order data lived in the staff's heads, in notebooks, and in scattered chat threads. No clear flow from order intake to delivery meant rework and lost time.

2. WhatsApp overload. On one visit, an employee showed me a backlog of ~30 messages from the previous day with no initial response. For a business selling same-day printing, a customer waiting 24 hours for "hello" is a customer walking to a competitor.

3. Pricing was tribal knowledge. A business card order involves format, size, paper type, finish, special cuts, quantity, and the shop had no documented logic for how those combine into a price. Every quote was a manual calculation by whoever happened to answer.

The insight only field work revealed: the shop didn't think of these as three problems. To them it was just "a busy day." The lack of process was invisible from the inside, which is exactly why an outside researcher watching the counter for hours could see what they couldn't.

Three users, three completely different contexts — one order.

Design implication: one order object had to flow through three radically different interfaces — a dense desktop CRM, a natural-language WhatsApp conversation, and a glanceable mobile app. Consistency of data, not consistency of UI, was the design principle.

Solo designer, AI-accelerated — research to working product in weeks, not months.

I owned the full design process: field research, flow definition, prototyping, usability testing, and iteration. What made this project unusual was the build workflow: I used Figma and Figma Make for design exploration, and Cursor + Claude Code to translate validated designs into working software on Supabase/Vercel, with n8n orchestrating the WhatsApp AI agent.

Why this matters to a hiring team: AI tooling didn't replace the UX process — it compressed 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.

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

• No baseline data. The shop had no metrics on response time, order volume per channel, or quote accuracy. All "before" numbers came from direct observation and manual timing during my visits.

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

• Undefined pricing logic. The client couldn't articulate how prices were built — a hard blocker for both the CRM and the AI agent.

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

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.

What this revealed that interviews wouldn't have: staff didn't complain about the pricing chaos — they were proud of knowing it by heart. The pain was invisible to them; only timing the tasks exposed it. A quote that "took a minute" actually took 4–6 minutes with interruptions.

The hardest interface had no screens.

The WhatsApp agent is trained on the shop's real products, prices, and policies. The design challenge wasn't technical — it was anticipating the messy ways real customers actually order and designing conversation mechanisms that feel natural while still collecting every field an order needs.

My process:
• Mapped real conversation transcripts from the shop's WhatsApp history
• Designed the conversation flow in FigJam, covering happy path + edge cases
• Defined the human-handoff moment: the agent conducts the conversation up to order confirmation, then transfers to staff

When the customer approves the quote, a payment link is sent automatically in the chat.

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. Testing between live customers meant sessions were interrupted, which turned out to be a feature: I saw exactly how the system behaved under the shop's real conditions, not lab conditions.

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: Order abandonment during creation dropped to near zero.

After multiple test rounds and iterations, the streamlined flows produced the measured 35% reduction.

The order board: keep the kanban, rebuild what's under it

Before: Orders lived in Trello. It worked as a team board, but: customers and products couldn't be linked to records - everything was typed by hand with no source of truth; unrelated information like invoice generation was mixed into the same board, creating confusion; the team retyped repetitive data constantly; and the business couldn't answer basic questions - how many orders last month? how much did we bill this year?

AFTER

Decision: Keep the kanban method (Jakob's Law), rebuild the data model beneath it. 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: zero retraining cost, and the shop moved from "we think it was a good month" to knowing exactly what it sold, to whom, and by whom.

Solo designer, AI-accelerated — research to working product in weeks, not months.

I owned the full design process: field research, flow definition, prototyping, usability testing, and iteration. What made this project unusual was the build workflow: I used Figma and Figma Make for design exploration, and Cursor + Claude Code to translate validated designs into working software on Supabase/Vercel, with n8n orchestrating the WhatsApp AI agent.

Why this matters to a hiring team: AI tooling didn't replace the UX process — it compressed 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.

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

Previously, creating an order meant moving between Trello, WhatsApp, product references and spreadsheets.
I redesigned the order as a central workspace.

AFTER

From a single order, employees can access customer information, product configuration, payment and relevant context.

Designing for speed at the counter

During testing, we discovered that a structured order workflow could still be too slow for simple counter requests. That was an important failure.

The interface made logical sense, but real counter interactions demanded something faster. The team asked for a Quick Order workflow for simpler products such as small print runs and copies.

I redesigned the flow around three focused steps: Customer → Products → Payment

The objective was not to expose the full power of the CRM. It was to expose only what was necessary at that moment.

UX lesson: The most complete workflow is not always the best workflow.

The correct amount of interface depends on the context of use. This redesign contributed to the 16% faster order creation time observed during pilot testing.

The pricing engine: the heart of the CRM

Before: A single business card can be configured 240 different ways. Pricing was manual, from memory or fragmented spreadsheets, making every quote slow and error-prone. New employees lost significant time just learning prices.

Problem: The client couldn't articulate how prices were built. There was no document to design from.

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.

• It was designed the variation matrix: each variation (format, size, paper, finish, special cuts, quantity, art) carries its own price component, and their combination generates the final price. I ran the working sessions with the owner to extract the tacit rules and modeled how variations should compose.

• Danilo Trivelatto turned that model into a calculation engine that holds up under real conditions - handling the combinatorial explosion of variations, the rounding and rule-precedence edge cases, and the performance needed for both the counter and the AI agent to query it in real time. Several rounds of attempts and failures were needed before the model was correct; his engineering judgment on how to structure the calculation is what made the design viable rather than theoretical.

Designing a real customer database

AFTER

Fellow introduced structured customer profiles containing contact data, addresses and purchase history.
That enabled a subtle but meaningful experience improvement.

When a known customer contacts the company through WhatsApp, the AI Agent can identify them by phone number and address them by name.

From:
“Who is this customer?”

To:
“We already know who we're talking to.”

That transforms the CRM from a passive database into part of the service experience.

Customer record shortcut: main information, phone, address, order history, and notes one click away instead of hunting across screens and systems.

What if the customer didn't have to wait for the first reply?

AFTER

The first opportunity

Centralize WhatsApp conversations inside Fellow.

Instead of treating customer service as a completely separate tool, we integrated it into the operating context of the CRM.

Employees can now see:

- Customers;
- Current products;
- Existing orders;
- Payment context;
- Conversation.

New messages are surfaced directly from the Fellow interface.

Before: Service happened directly in WhatsApp. Staff told me they got lost among simultaneous conversations and couldn't tell:

• whether a customer had paid: the trigger for starting production. Paid orders sat idle because a message slipped past unnoticed.
• which conversations were stale: they archived chats manually just to keep the inbox usable.
• how to quote quickly: they typed the product name, every variation, and sent reference photos and prices by hand, stretching each conversation.

• The AI agent replies at any hour, so nothing needs archiving to stay manageable.

• The agent builds the quote/order itself and hands the conversation to a human only for validation.

• Pause AI: staff take over instantly by typing a message or pressing a button.

Why the Pause AI button matters more than it looks: it's the trust mechanism. Automation a user can't interrupt is automation the user resents. A one-tap override is what made the team willing to let the agent run.

Designing data the company never had

AFTER

The system now brings together revenue, orders, customer data and product performance so managers can make decisions without manually requesting fragmented reports.

Design evolution

This represents an important shift:

Fellow started by organizing work.
It gradually began creating information for decision-making.

Configuration instead of assumptions

AFTER

Research also made something clear:

No two print shops operate exactly the same way.

Rather than hardcoding one “ideal” workflow, we created configuration options for:

- Kanban columns;
- Employee flows;
- Order rules;
- Labels;
- Payment methods;
- AI Agent instructions.

The goal is for Fellow to adapt to the operation instead of forcing every operation to become identical.

Product design principle:

Standardize the experience where consistency helps. Configure the workflow where the business genuinely differs.

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, enabling verified payment status and automated payment links instead of relying on receipt screenshots.
- Delivery & rider experience, connecting dispatch, drivers, delivery status, and the order lifecycle.-
WhatsApp voice-message support for the AI Agent, reflecting how customers actually communicate.
- Full-funnel analytics, measuring the journey from first contact to quote, payment, production, and delivery.

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.