# Wingman

By Munawar Khel / Independent Practice / Freelance UI/UX Designer / 2026–PRESENT / 10 min read

Published at https://munawarkhel.com/work/independent-practice/wingman/

Designed and built a working mobile-first PWA that serves as the control and visibility layer for a WhatsApp-based AI agent, taking a client's idea and brand guideline through to a deployed, installable, versioned product

- Company: Independent Practice
- My role: Freelance UI/UX Designer
- Timeline: June 2026 to Present
- Platform: Mobile-first PWA, installable, with a separate versioned marketing site
- Category: AI Agent / Personal Productivity
- Status: New design, delivered
- Tools: Claude Code, React 18, TypeScript, Vite, CSS custom properties, Figma, Hugeicons Pro, Resend, Vercel, Linear
- Team: Solo design and build, working directly with the client

## Context

A proactive AI assistant has an awkward problem: if it works properly, it lives where you already are rather than in an app you remember to open. Wingman is a chief of staff that operates inside WhatsApp, briefing you in the morning, triaging email, watching bills and deliveries and travel, and remembering the commitments you made to people. The conversation is the product.

That leaves a question the conversation cannot answer on its own. If an agent is going to act on your behalf, you need somewhere to see what it knows, decide how much it may do without asking, and check what it has already done. A chat thread is a poor place to audit a system, and a poor place to change its settings.

The client came to me with the idea and a small brand guideline. Everything after that was mine: the product knowledge structure, the information architecture, the design system, the interaction model, and the built application. The result is a mobile-first PWA that acts as the control and visibility layer for an agent whose real home is a messaging thread.

## The problem

The design problem is that the app is deliberately not where the work happens. Almost every pattern available for a productivity product assumes the app is the destination: dashboards to live in, inboxes to clear, streaks to maintain. Wingman inverts that. If a user is in the app for long, something has gone wrong in the channel that matters. So the app had to be genuinely useful and quick to leave, which rules out most engagement conventions and offers few precedents to borrow.

Underneath that sits a trust problem, and it is the harder one. An assistant that only reports is safe and close to useless. An assistant that acts is useful and frightening. The gap between those is not closed by a settings page with a few toggles, because the real questions a user has are specific and situational: what does it know about me, where did that come from, what is it about to do, what has it already done in my name, and how do I stop it. Each of those needs a surface, and none of them is a preference.

There was a third constraint that shaped the build more than it looks. There is no backend. The product had to be demonstrable end to end, to a client and to prospective users, as a front end running on seeded data. Everything a real system would return had to be modelled convincingly enough to hold up under a walkthrough, without pretending to a persistence it did not have.

Finally, the audience is not English-only. The product targets markets where Arabic and Urdu are first languages, so right-to-left was a structural requirement from early on rather than a late localisation pass.

## What I did

The app is organised as five tabs over a detail layer. Home, Calendar, Email, Tasks and More are siblings; everything else, the module screens for bills, deliveries, travel, people, health, business and news, plus notifications, profile and all settings, slides in over a tab and carries its own back bar. That split keeps the everyday surface shallow and lets the depth exist without cluttering it.

The answer to the trust problem is a single object, the approval card, and the decision that it is the only surface in the product that acts. Every action anywhere in the app, an email reply, a bill renewal, a travel change, a follow-up with a person, resolves to the same card. One object means one mental model: the user learns once what it means for Wingman to ask permission, and that knowledge holds everywhere. Approvals are logged, waiting items first and decided items after, so a decision is auditable after the fact rather than vanishing into a thread.

Around that sit the trust screens. A memory screen shows what the agent knows about you, grouped by the part of life it belongs to, each note traceable to where it came from and removable. A business brain screen does the same for connected commerce data. Agent behaviour is shaped by three controls rather than a wall of switches: proactivity, which sets how much it may do unprompted, skills, which sets what domains it works in at all, and personality, which sets tone and detail. The dial framing matters more than the switches: it lets a user start cautious and grant more as confidence builds.

Home is a widget canvas the user owns rather than a fixed dashboard. An earlier version led with a productivity score, and it was removed deliberately, because a chief of staff that grades you is a different and worse product than one that helps you. Widgets come in three sizes that form an information ladder rather than a zoom: the smallest is one number and the whole card is the target, the largest is a working list with per-row actions. Every widget answers its own empty state with the action that fixes it, so an unset module is an invitation rather than a grey placeholder.

The whole surface runs on a closed design system: two token scales for spacing and radii that nothing may step outside, one button in two sizes with tones as modifiers, one chip scale in four rungs, and one motion scale where a transition is chosen by what the motion does rather than by the nearest convenient number.

## Outcomes

- Designed and built a working mobile-first PWA that serves as the control and visibility layer for a WhatsApp-based AI agent, taking a client's idea and brand guideline through to a deployed, installable, versioned product
- Established a single approval object as the only acting surface in the product, giving an agent that takes real actions one predictable permission model and one auditable decision log instead of per-screen confirmation patterns
- Made agent trust designable rather than assumed, through an autonomy dial across proactivity, skills and personality, plus memory screens that show what the assistant knows, where it learned it, and let the user delete any of it
- Built a closed design system spanning Figma and code, two token scales for spacing and radii, one button in two sizes with tones as modifiers, a four-rung chip scale, and a single motion scale, with 69 documented components and 26 mapped Figma screen frames
- Shipped right-to-left support as a structural property across Arabic, Urdu and Hindi, including language-linked currency conversion and glyph-outline rendering for curved labels that text on a path could not handle
- Delivered a fully demonstrable product with no backend, seeded at realistic data volume so client walkthroughs exercise real layouts, with the seed and its loading layer isolated as the single thing a real backend replaces
- Maintained a written design decision record of 37 logged decisions covering what changed, why, and what it constrained, which is what allowed direction reversals such as removing the productivity meter to be made cleanly rather than accreted around
- Built the surrounding product surfaces as well as the app: a versioned marketing site with a permanent public URL and one-line version promotion, a waitlist backed by transactional email, and a design kit request flow with an email approval step

## Decisions

### The app is a control layer, not a destination

What: Defined the application as the place to meet, shape and check on an agent that lives in WhatsApp, and designed for short visits. Every "Ask Wingman" control deep-links out to WhatsApp rather than opening an in-app chat thread.

Alternatives: Building an in-app conversational surface, which would have made the app self-sufficient and demo better in isolation.

Why: Two chat surfaces for one agent splits the history and forces a user to wonder which one the assistant actually heard. Committing to the channel the product had already chosen kept a single thread of record, and made the app's job narrower and clearer.

### One approval card, and it is the only thing that acts

What: Made every action in the product, across email, bills, travel, people and business, resolve to a single approval object presented as a sheet, with a log of waiting and decided items behind it.

Alternatives: Contextual confirmation patterns per surface, each tuned to its own screen.

Why: Trust in an agent is built by predictability. If permission looks different in every module, the user relearns the stakes each time and hesitates. One object means the lesson is learned once and holds everywhere, and it gives the product a single audit trail instead of a decision history scattered across screens.

### Autonomy as a dial, with the agent's knowledge made inspectable

What: Reduced agent configuration to proactivity, skills and personality, and added trust screens that show what the agent remembers, grouped by area of life, traceable to source and individually removable.

Alternatives: A conventional permissions matrix, or leaving memory implicit as most assistants do.

Why: The blocking question is not which features are enabled, it is how much authority the thing has and what it thinks it knows about you. A dial lets a cautious user start low and grant more as confidence builds, and inspectable memory turns the scariest property of a personal agent into something the user can audit and correct.

### Home is a canvas the user owns, and the score goes

What: Replaced a fixed hero with a productivity meter and metric pills with a two-column widget grid the user arranges, in three sizes that form an information ladder, each widget owning its own empty state.

Alternatives: Keeping the snapshot hero and allowing reordering underneath it, which was the previous design.

Why: A chief of staff that grades your day is a different product from one that helps with it, and the meter set the wrong relationship on the first screen. Ownership of the canvas also solves the personalisation problem honestly: different users care about different modules, and the design does not have to guess which.

### Right-to-left as structure, not translation

What: Treated Arabic, Urdu and Hindi as first-class from early in the build: logical properties throughout, currency that converts with the language, the header and tab bar deliberately held left-to-right, and curved ring labels generated as glyph outlines where text on a path failed.

Alternatives: Shipping English and adding a localisation pass later, which is the common sequence.

Why: Right-to-left is not a translation problem, it is a layout problem, and retrofitting it means revisiting every screen. Doing it while the component set was still small made it a property of the design system rather than a project. The carve-outs matter too: mirroring the app header and tab bar would have fought the phone's own chrome rather than matching it.

## What I learned

Designing the control surface for an agent is a different discipline from designing an app, and most of the available patterns actively mislead. The instinct to make a product sticky is wrong when the product's success means the user is somewhere else. Naming that inversion at the start, and writing it into the design direction as a stance rather than leaving it as an intuition, is what kept it from being eroded one reasonable-seeming addition at a time.

Trust turned out to be an information architecture problem rather than a copy problem. It was tempting to think reassurance comes from tone, from explaining carefully what the agent will and will not do. It does not. It comes from structure: one predictable object that asks permission, a log that survives the decision, memory the user can read and delete, and a dial rather than a switch. Every one of those is a surface someone has to design, and none of them is solved by wording.

The decision record earned its keep in a way I did not anticipate. Writing down what changed and what it consequently constrained meant that reversing a direction later was a clean operation rather than an archaeology exercise, and it caught two places where the product was quietly lying to the user, reporting an action as done when nothing had happened and offering help only for meetings that had been scheduled in advance. Both were found by re-reading decisions against the built product, not by using it.

The honest open items are the ones a demo hides. There is no general application state layer yet, so some settings and read states reset; the product is still front end only, which means every behaviour is modelled rather than real; and the client's plan to move from PWA to a native app with a web interface alongside will revisit assumptions the current shell makes about being installable from a browser.

Tags: Information Architecture, Design Systems, Design Tokens, AI Product Design, Claude Code, Full-Stack