01
VendifAI
AI product discovery and conversational commerce — AI search, review summarisation, a hands-free voice journey and session management.
Open to senior product design roles
Karachi, Pakistan
Remote · UTC+5
Remote · UTC+5
Product design that survives implementation.
Mustafeez Ahmed — Senior Product Designer and UX Engineer. Around ten years across user journeys, interface systems and the front-end code they become.
- Product design
- UX engineering
- Design systems
- AI experiences
- Accessibility
0 yrsDesign and development
FigmaTo React and Angular
WCAG2.1 AA as standard
AIProduct experiences
Selected case studies
Three products, three different problems.
AI commerce on a live catalogue, a two-sided mobile marketplace, and a physical members club moving onto software.
-
-
02
ScrapPick
A scrap-collection marketplace for customers and vendors — sketched on paper, designed in Figma, handed off screen by screen.
-
03
Sniffinity
A UK members club moved onto product — member app and staff front-desk portal, mapped as user journeys before any screen existed.
Each case study covers the problem, my role, the decisions and the artefacts.Scroll to stack · Select a card to open
About
Ten years spent moving from building interfaces to deciding what they should be.
I'm a product designer and UX engineer with around ten years of experience designing and building digital products. I started as a UI developer, moved into UI/UX, and for the past couple of years have worked where product design, UX thinking and interface engineering meet.
That background means I think past static screens. Interaction, responsiveness, accessibility and how something will actually be built are part of the design from the first day, not a handover problem. I work well where requirements are incomplete and workflows are still moving — mapping the experience first is usually how the missing pieces surface, and it gives everyone else something concrete to correct.
I work with product owners, developers, designers and clients directly, and I'm equally comfortable presenting a user journey to a stakeholder and reviewing a component implementation with an engineer in the same afternoon.
- ACCP Pro — Aptech Karachi2016
- Google UX Design Professional CertificateCoursera
- Awwwards certificate — front endCertified
- Figma, FigJam, MiroDaily
- Photoshop, Illustrator, Adobe XDProficient
- After Effects, Premiere ProMotion and video
- Based in Karachi, working remotelyUTC+5
- LanguagesEnglish, Urdu
Design and build, one artefact
Each wireframe is derived from the real screen — sampled on an 8px grid, classified by luminance and density, then redrawn as structure. Same geometry on both layers, so nothing shifts as you drag.
DRAG
WireframeDesigned — VendifAI review summary
Left is structure. Right is the designed screen from the project file.
Arrow keys move the handle · Home and End jump
Capability
What I am hired for, and what I actually do day to day.
Product and UX +
Flows and journeys before screens, information architecture, and edge-case mapping — empty, error, loading, permission, offline, interrupted. Advanced prototypes for anything where timing or sequence carries the meaning, and A/B testing with real users where a question is worth settling with evidence rather than opinion.
- User flows and journey diagrams
- Information architecture
- Low-fi to high-fi
- Advanced prototyping
- A/B testing with users
- UX research and framing
Interface and systems +
High-fidelity UI built on tokens and components rather than one-off screens, because the second screen is where a system pays for itself. Visual hierarchy, interaction states, responsive behaviour across mobile and desktop, and the discipline to work inside someone else's system — Material 3, for instance — rather than inventing a parallel one.
- Design systems
- Tokens and components
- Interaction states
- Responsive UX
- SaaS and product dashboards
- Material 3
Front-end engineering +
Production implementation, not mockups. Component architecture, cross-browser behaviour, and motion that survives real data. Knowing how it will be built changes what gets specified — awkward states get resolved in design rather than negotiated at handover.
- HTML, CSS, JavaScript
- React components
- TypeScript
- Angular
- Material UI, PrimeNG, Tailwind
- GSAP, canvas, WebGL
Accessibility +
WCAG 2.1 AA as a working standard rather than an audit at the end. Semantic structure, keyboard navigation and focus order, contrast and colour independence, screen reader behaviour, and reduced-motion support — including on this site, which passes what it claims.
- WCAG 2.1 AA
- Semantic structure
- Keyboard and focus order
- Contrast and colour independence
- Screen readers
- Reduced motion
Tools and craft +
Figma and FigJam daily, Miro for collaborative mapping, and the Adobe suite where it earns its place. Motion and video produced manually in After Effects and Premiere Pro — not only through AI.
- Figma, FigJam, Miro
- Photoshop, Illustrator, Adobe XD
- After Effects, Premiere Pro
How the work actually goes
Requirements are rarely finished when the design work starts.
- 01Understand the problem
Read the brief, then work out what is actually being asked. Requirements usually describe a symptom.
- 02Map the experience
Flows and journeys before screens, in two lanes where there is a back office. This is where missing scenarios surface.
- 03Find the edges
Empty, error, loading, permission, offline, interrupted. Edge cases decide whether a product survives real use.
- 04Design the system
Low fidelity to high fidelity, on tokens and components rather than one-off screens.
- 05Prototype
Advanced prototypes wherever timing or sequence carries the meaning. Coded when it needs to be real.
- 06Build with engineering
Sit with the implementation, resolve what the design did not answer, keep the system honest as it ships.
- 07Refine
Test where testing is possible, fix what the interface got wrong, write down what would be validated next.
Career to date
UI Developer → UI/UX Designer → Product Designer and UX Engineer.
2024 — now
Product Designer / UX EngineerVendifAI, Sniffinity, ScrapPick and client product work
Product design, UX thinking, UI engineering and interaction design combined in one role. AI product experiences, conversational and voice interfaces, complex membership and onboarding workflows, and mobile product design through to handoff.
2021 — 2024
UI/UX Designer → Product DesignerEnterprise SaaS and product dashboards
Moved from executing interfaces to defining them — user flows, information architecture, design systems and onboarding for enterprise products, working inside established systems rather than around them.
2018 — 2021
UI Developer → UI/UX DesignerResponsive web applications
Built responsive, cross-browser interfaces in HTML, CSS, JavaScript and Angular while taking on design responsibility — the period that made implementation constraints part of how I design rather than something handed over.
2016 — 2018
UI DeveloperACCP Pro — Aptech Karachi
Front-end foundations: markup, styling, component thinking, and the habit of checking a design against the browser rather than the canvas.
Also worked on
Shorter engagements and prototypes across automotive, technology, wellbeing and healthcare.
RR Autos
Automotive service prototype — booking and service presentation for a workshop audience.
PrototypeVerveteck
Technology brand and product prototype, built out as an interactive Figma flow.
PrototypeINNERHABBIT
Habit and wellbeing concept — mobile-first interaction design and prototyping.
PrototypeMedixin
Online medical app with a community layer — patient-facing flows and interface design.
Product designLet's build something meaningful.
mmustafeez.ahmed@gmail.com +92 312 225 8596Open to Senior Product Designer, Product Designer, Senior UI/UX Designer and UX Engineer roles — full time or contract, remote.
All case studies
Case study 01
Making AI shopping feel safe enough to try.
AI product discovery and conversational commerce over a live retail catalogue.
The challenge
VendifAI is an AI layer that sits on top of a retailer's existing store. Instead of typing keywords and filtering a grid, a shopper describes what they need and the assistant works against the live catalogue.
The design problem was not building a chatbot. It was introducing an unfamiliar interaction without breaking the store around it — so every feature was designed as a state of the retailer's own page rather than a separate product.
My role
Product design and interaction design across AI search, review summarisation, the voice journey and session management — from user journeys and low-fidelity flows through high-fidelity UI, prototypes for timing-dependent interactions, and front-end implementation of interactive components.
- User journeys and session-management flow
- High-fidelity UI, desktop and mobile
- Voice states: permission, listening, speaking, error
- Prototyping and A/B test variants
AI search, inside the existing search bar
An AI Mode toggle in the store's own search field, so the entry point sits where shoppers already look. Results, a Why this rich tooltip and the review summary were designed as one journey — with later ideas explicitly parked as Future release rather than left ambiguous.
Voice, with the chat hidden
Hands-free mode removes the conversation so products stay visible. The orb and equalizer carry listening, thinking and speaking; permission states are designed rather than left to the browser; and the shopper can say Stop to interrupt the agent.
Ending a session without losing anything
Closing the assistant only asks a question when there is something to lose. End Chat is never styled red or grouped with destructive actions — ending a good conversation is not a delete.
The voice interaction, running live.
This is the real component, rendered in WebGL with a custom fragment shader using the product's orb gradient. Press a prompt to run the sequence, or turn on the microphone and drive it with your own voice.
- DecisionProducts stay visible for the whole session — the voice layer never takes the full screen. On mobile the container ends above the footer text so products are never overlapped.
- DecisionThe orb carries state through form and motion, not colour alone.
- DecisionSuggested prompts appear on entry — an open microphone with no prompt is the voice equivalent of an empty search field.
Ready
Responses are generated by AI and may occasionally be inaccurate. Always confirm important product information with the retailer before purchasing.
The close rule, runnable.
From the End Session board: the close icon shows a Leaving? prompt only when the agent has asked a follow-up question or has shown products. With nothing in play, close keeps its normal job and minimises the chat.
Set the conversation state, then press close. The dialog traps focus, closes on Escape and returns focus to the button that opened it.
- ValidationVariants of the design were A/B tested with real users on mobile, and the interaction was refined on what came back. The result belongs to the client and is not published here.
Conversation state
Hello! I just selected some interesting products with big discounts for you! What will you mostly use it for?
No follow-up and no products — closing will simply minimise.
Leaving?
‘Clear conversation’ will remove chat history and close this session.
Chat minimized
All case studies
Case study 02
One scrap pickup, designed from both sides.
A scrap-collection marketplace for customers and vendors, taken from paper sketches to developer handoff.
The challenge
ScrapPick connects people who have scrap to sell with vendors who collect it. A customer raises a pickup request; a vendor accepts or rejects it, travels to the address, confirms the weight and pays.
That makes it two apps sharing one order. Every status a customer sees — requested, rejected, on the way, paid — is an action someone on the vendor side took, so the two sides had to be designed against the same sequence rather than as separate products.
My role
End-to-end mobile design: paper sketches for each screen, the customer and vendor apps in Figma, authentication for both user types, and a handoff file organised the way it would be built.
- Paper sketches per screen
- Customer app and vendor app
- Order states, annotated
- Developer handoff file
The pickup request started as a paper sketch — name, mobile, address, a calendar and an item picker. In the designed flow, address becomes a map step on its own, and photos, weight and description are added so a vendor can judge the job before accepting it.
The vendor side of the same order.
A vendor opens the ad, sees the photos, weight and seller comments, and accepts or rejects. Rejecting asks for a reason from a list, so the customer is told why rather than just rejected. Once accepted, the order moves to On the way, and the item weight is confirmed before payment.
- StatesAd detail, reject with reason, on the way and paid are separate annotated frames, so each state reaches development specified instead of implied.
- TrustA seller profile carries rating, feedback and posted ads — the only thing a stranger has to go on before agreeing a pickup.
- AccessCustomers and vendors have separate sign-up paths, with phone number and OTP verification alongside email.
What I took from it.
Sketching each screen on paper before opening Figma kept the first decisions about content, not styling. The sketch for the profile is already about trust — rating, feedback, completion — and the designed screen keeps exactly that order.
The handoff file is organised the way it will be built: home, customer app, vendor app and authentication as separate areas, with discarded frames visibly set aside rather than deleted.
All case studies
Case study 03
Mapping a members club before designing a screen.
A UK small-dog members club moving onto a member app and a staff front-desk portal.
The challenge
Sniffinity is a small-dog community centre and members club in the UK with a physical venue and a shop. The operation ran on people and paper, and was moving onto a member app plus a staff portal for subscriptions, bookings, queries and settings.
The brief arrived as a feature list. What it did not contain was the shape of the service: when money changes hands, what happens if a dog fails its behavioural assessment, and who can act on whose behalf. Designing screens against that brief would have produced a plausible app that broke on contact with the real venue.
My role
UX design and service mapping first — user journeys in two lanes, member and staff, built before any screen existed and reviewed with the client — then the staff front-desk portal UI.
- User journeys in FigJam, two lanes
- Edge-case and scenario mapping
- Stakeholder walkthroughs
- Staff portal UI
What the journeys surfaced.
- ConfirmedMembers pay before the behavioural assessment, so membership sits in a pending state the interface must represent honestly.
- GapSix membership types — Sniff & Go, Sniff & Stay, Off Peak, Peak, Work From Sniffinity and Anytime — with booking rights never written down in one place.
- ConflictA household invite can collide with an account that already exists. The invite became a claim the invited person confirms, not a record the owner writes.
- OwnershipHuman and pet household members needed separate flows.
The invitation problem.
An owner types in a relative's name and email to add them to the household. If that person already has an account, the typed details now contradict their real ones, and whichever record wins is wrong for somebody.
Resolving it meant treating the invite as a claim rather than a record — the owner proposes, the invited person confirms and owns their own details. That decision came out of a flow diagram, not a screen.
What I took from it.
The most valuable thing produced on this project was not an interface. Mapping the experience first turned an incomplete brief into an agreed one, and the client understood their own service better at the end of it.
The flows stayed deliberately plain — boxes and arrows, arrows ending cleanly on box edges, each board distinctly named — so non-designers could read them and correct them in the room.
