Work

About

Contact

Resume

EmitaZap: No screen is the best screen

Anticipating every scenario has never mattered more — after all, the entire experience depends on how each word is written.

A flow with no interface doesn't forgive an ambiguous message. I was responsible for making sure every word exchanged with the user did the job that, in another product, an entire screen would do.

Timeline

Apr/2026 - Jun/2026

Role

Product Designer

Company

OpenMEI

Interface

WhatsApp

Context

Analyzing app usage through Mixpanel, I found something simple: 73% of everything micro-entrepreneurs did on the platform came down to two actions — issuing a service invoice and paying the DAS tax slip. At the same time, the tax services market had been migrating to WhatsApp, chasing a more direct, resolution-focused experience, without the friction of installing yet another app.

Those two signals together led to a simple question: what if our user no longer needed the app to do the one thing they actually used it for?

Responsibilities

This wasn't a request that came from the top. It was born from a conversation between me and the Product Manager, based on a pattern I spotted in the usage data. I was responsible for validating the hypothesis through research, designing the conversational flow, and writing every message the user receives, from the confirmation text to the error notice. I also supported the PM in the pricing conversation with stakeholders, even though the final call on the billing model wasn't ours.

Constraints

Since this was our own initiative and not a top-down requirement, the project ran in parallel with the other teams, without competing for priority — which, in practice, was an advantage: we didn't need to justify a hypothesis, just show a finished result.

Two real constraints came up along the way. The technical one: to speed up development, we chose to build the flow inside N8N instead of a proprietary system. The positioning one: since the product would be used by accountants from different brands, it couldn't carry OpenMEI's identity. That led me to name it something neutral, easy to remember, and "white label" by nature: EmitaZap (Emissão/Issuance + WhatsApp).

O time

One product manager, me as product designer, one senior backend dev, and one mid-level backend dev. No dedicated frontend — the entire product runs inside a WhatsApp conversation.

Problem

Half a dozen actions hidden behind an entire app

It wasn't really a problem — it was an underused opportunity. 73% of platform usage fit into two actions, but users still had to open, navigate, and learn an entire app to reach them. Talking to the users themselves, the reason came up quickly: it wasn't a lack of features, it was resistance to yet another app on their phone. One accountant put it better than any research could: he'd rather have the end client receive the tax slip and issue the invoice straight through WhatsApp, with no app needed at all.

In practice, we were looking for a way to "kill" our own app — replacing it, at least for these two tasks, with a more direct experience.

Process

It goes fast when the thesis is already right

Unlike other projects, the research phase here was short — not because it was shallow, but because the hypothesis was already born from a real usage pattern, and validation simply confirmed what the numbers already showed.

Validation research

I talked to 27 end clients and 12 accountants. The response was nearly unanimous: 92% of end clients preferred handling everything through WhatsApp, to the point of being willing to pay more for it. On the accountants' side, the preference wasn't for the channel itself, but for automation — 100% agreed that as long as the process was automatic, the channel didn't matter to them.

Conversation design

My biggest challenge here wasn't about flow, it was about language. A 100% text-based flow has no screen to hide ambiguity behind — every sentence needs to be unmistakable on first read, because there's no hover, tooltip, or icon to rescue a confusing message.

I drew on my previous experience in marketing and copywriting to write direct messages, free of double meaning and of the technical vocabulary developers tended to default to — vocabulary that also didn't make sense for the end-client ICP, mostly micro-entrepreneurs with no financial or technical background. One simple example illustrates the principle: when a user asks for their tax slip, the reply isn't a generic "Processing request," it's "Sure, generating your May DAS slip now!" — it confirms what was understood, names the right month, and uses a real conversational tone instead of a system-y one. That combination of UX and copy was what I brought to the team that no one else had.

Development

Working closely with the developers was essential in this phase — a lot of what seemed resolved on paper only revealed its blind spots once the flow actually ran inside N8N. It was constant back-and-forth: I reviewed the automation's real behavior, they pointed out technical limitations, and together we adjusted both the logic and the message, whenever a change in one required a change in the other.

Testing

Testing a product with no screen requires watching for things that would normally go unnoticed. The time between messages, for example, needed fine calibration: too fast felt robotic, too slow felt broken. One concrete adjustment came directly from user behavior — the wait time before automatically ending the conversation went from 20 seconds after the last message to 3 minutes, giving users real room to respond without the flow feeling stuck or losing service due to a delay.

Error cases needed extra attention: with no generic error screen to cover every scenario, each possible failure (slip not found, invalid CPF, system down) needed its own message, tested and adjusted based on how users actually reacted.

Challenge

The negotiation that came after the product was ready

The hardest part of the project was pricing it, not building it. We used competitors like Contabilizei as a reference, which charges around R$60 per user just to offer a similar feature. The original proposal was simpler than competitors': charge the accountant roughly R$100 extra for access to the feature, leaving it up to them to decide how much to pass on to the end client — a win-win model that benefited the accountant as much as, or more than, OpenMEI itself.

Stakeholders liked the product but didn't approve this billing model. EmitaZap launched as a free feature, not a paid add-on. It wasn't the decision we advocated for, but it was the decision that stuck.

Results

Results: A near-complete Win

Reduced flow abandonment

Before the redesign, 58% of users abandoned the flow before completing the action — they'd request the slip and disappear. After the copy and conversation-timing changes (including adjusting the closing time from 20s to 3min), that rate dropped to 31%. This is the most direct evidence that the language and calibration work wasn't just polish — it solved the problem that motivated the project.

Initial adoption among accountants

One month after launch, and without direct promotion to the entire user base, 22% of accountants had already adopted EmitaZap, measured against the platform's total accountant base.

Satisfaction among current users

The feature's CSAT sits at 85% — compared to a 62% average for the same feature offered through other channels (outside WhatsApp). That gap is the case's own argument: the channel and the conversational language weren't just a positioning bet, they measured out in real satisfaction.

Unconfirmed revenue projection

The initial estimate, assuming a base of 1,000 clients and a 40% adoption rate, projected around R$40k in MRR under the original billing model. Since that model wasn't approved, and the product launched as a free feature, that projection was never actually tested — today it's just a picture of the value the feature ended up not capturing directly, not an achieved result.

Learnings

Learning and Next Step

The biggest learning from this project wasn't about product, it was about process: building from a real user pain point, already proven in usage data even before research, made the whole validation faster and the conversation with stakeholders simpler — we didn't need to convince anyone of a hypothesis, just show a finished result.

The exception was pricing, which remains an open conversation. With adoption growing even without wide promotion, the next step is to revisit the billing model with real usage data in hand — no longer as a projection, but as a negotiation backed by numbers the product itself already generated.

Validating the thesis also opened the door to thinking bigger: if issuing a slip and paying the DAS no longer need an app, why would the rest of the micro-entrepreneur's journey? V2, already in design, is EmitaMEI — expanding the same principle to registering a business, issuing product invoices, and cancellations, all within WhatsApp.

Other projects to check out

Tax Service · WhatsApp · 2026