Fast-print businesses need to move quickly.

Gráfica SF is not a struggling business. Two decades in the market, born as an arm of the largest print shop in a city of nearly a million people, operating from a first-class space inside a shopping mall.

So you'd expect defined processes and a clean workflow.

What I found instead:

• No CRM or ERP ❌
• Products managed in spreadsheets ❌
• Pricing logic living in the owner's and manager's heads ❌
• No order history ❌
• No customer database ❌
• Decentralized control across disconnected tools: Trello for orders, WhatsApp for customers, spreadsheets for prices ❌

And the consequence customers actually feel: a WhatsApp inbox where the first reply can take a day. On one visit, an employee showed me roughly 30 messages from the previous day still waiting for a first response.

For a business whose entire promise is speed, that's not an operational detail, it's the product failing at the front door.

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 end-to-end design process: from field research, user flows and information architecture to prototyping, usability testing and iteration. I worked closely with Gráfica SF’s real employees, observing how orders were handled in practice and using those insights to continuously refine the product.

AI-assisted tools helped me shorten the distance between design and implementation. I used Figma and FigJam to explore flows and interactions, Lovable for early functional prototypes, and later stayed close to the build through vibe coding, allowing ideas to move quickly from research to something users could actually test.

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.

Multiple visits to Gráfica SF across the project - shadowing counter service, watching WhatsApp conversations unfold in real time, following orders into production, observing how the team coordinated pickups and deliveries.

What observation revealed that interviews wouldn't have: the team didn't describe most of these as problems. Pricing from memory was a point of pride. A slow WhatsApp reply was "a busy day." The pain was invisible from the inside - normalized by twenty years of doing it that way.

Methods: contextual inquiry across in-shop visits · task observation and timing at the counter · analysis of the existing Trello board and WhatsApp history · working sessions with the owner to reverse-engineer pricing rules · iterative usability testing with real employees during live operation.

The hardest interface had no screens.

While observing WhatsApp conversations, I realized that customer service followed no predictable path. Customers rarely provided all the information needed for a quote upfront — they changed specifications, asked unrelated questions, sent incomplete requests, returned hours later, or requested multiple products in the same conversation.

What looked like a simple chat was actually a complex order-building process hidden inside messages. Employees had to identify the customer’s intent, collect missing product specifications, answer questions, remember what had already been discussed, and determine when there was enough information to create a quote. The conversation itself was an interface — just one without buttons, fields, or a fixed sequence.

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 15% 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.

When the prototyping environment became a product constraint

Fellow initially started in Lovable.

It was useful for getting ideas into functional form quickly, which was valuable during the earliest stages of exploration.
But as the product became more complex, we started reaching limitations in flexibility and implementation control.
The system was no longer a simple prototype.

It needed:
complex product logic;
sophisticated pricing;
integrations;
reusable components;
deeper customization;
continuous iteration based on pilot feedback.

The decision: We migrated the project from Lovable to Cursor.
This was an important technical turning point.

Danilo Trivelatto was fundamental to this decision and to making the migration successful.
His programming expertise helped move Fellow into an environment where we could gain much deeper control over implementation, evolve the architecture and support more ambitious product requirements.

That change allowed us to continue improving areas that would have become increasingly difficult to manage under the previous constraints.

What I learned from it
Tooling decisions are also product decisions. The fastest environment for the first prototype is not necessarily the right environment for a product that is becoming operationally complex.

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.