Amina Tayyub
Working on the spectrum between product design & product management to shape experiences grounded in real human needs.
view cv
Amina Tayyub
Working on the spectrum between product design & product management to shape experiences grounded in real human needs.
view cv
Amina Tayyub
Working on the spectrum between product design & product management to shape experiences grounded in real human needs.
view cv
SPEEDSPEAK
Structuring a three-sided booking workflows for interpreting services
Structuring a three-sided booking workflows for interpreting services
Problem
Problem
The business (SpeedSpeak) ran entirely on spreadsheets. As volume grew, this created a ceiling: no shared system for interpreters and clients, no structured booking flow, manual coordination overhead. To scale, the client needed a real product, not a bigger spreadsheet.
The business (SpeedSpeak) ran entirely on spreadsheets. As volume grew, this created a ceiling: no shared system for interpreters and clients, no structured booking flow, manual coordination overhead. To scale, the client needed a real product, not a bigger spreadsheet.
Business Impact
Business Impact
Manual coordination between admin, interpreters, and clients replaced with a structured system
Status and payment tracking centralized, reducing manual errors in payment calculation
A system that can handle more bookings than a spreadsheet could, supporting the client's original goal of scaling
Manual coordination between admin, interpreters, and clients replaced with a structured system
Status and payment tracking centralized, reducing manual errors in payment calculation
A system that can handle more bookings than a spreadsheet could, supporting the client's original goal of scaling
User Impact
User Impact
Interpreters: structured job discovery and claiming, instead of ad hoc outreach
Interpreters: clear timesheet submission tied directly to payment
Clients: upfront cost estimate before committing to a booking
Clients: ability to track and manage their own bookings instead of relying on the admin for updates
Interpreters: structured job discovery and claiming, instead of ad hoc outreach
Interpreters: clear timesheet submission tied directly to payment
Clients: upfront cost estimate before committing to a booking
Clients: ability to track and manage their own bookings instead of relying on the admin for updates
What I owned (as product design manager)
What I owned (as product design manager)
Full userflow and user journey design for all three roles in the system (admin, interpreter, client), built after a series of client meetings to translate an informal sheet-based process into a structured digital system.
Below shows part of the userflows.
Full userflow and user journey design for all three roles in the system (admin, interpreter, client), built after a series of client meetings to translate an informal sheet-based process into a structured digital system.
Below shows part of the userflows.
Constraints
Constraints
Limited budge
Existing brand identity to work within (SpeedSpeak logo, blue primary color, light panels, clean sans-serif)
Technical approach: admin dashboard built in React
Screens built with AI-assisted design tooling (Pencil), based on the userflows and interaction logic below
Limited budge
Existing brand identity to work within (SpeedSpeak logo, blue primary color, light panels, clean sans-serif)
Technical approach: admin dashboard built in React
Screens built with AI-assisted design tooling (Pencil), based on the userflows and interaction logic below
Key decisions
Key decisions
Asymmetric profile models.
Asymmetric profile models.
Client and interpreter profiles collect different data. Clients need contact info, language, and rate. Interpreters need CV, certificates, work permit, and contract, since they carry more compliance requirements than clients do.
Client and interpreter profiles collect different data. Clients need contact info, language, and rate. Interpreters need CV, certificates, work permit, and contract, since they carry more compliance requirements than clients do.
First-time interpreter login experience.
First-time interpreter login experience.
First-time client login experience.
First-time client login experience.
A rate negotiation step, not a fixed price field.
A rate negotiation step, not a fixed price field.
When a booking is approved, standard rates are set for most common languages while admin sets a rate for rare languages. There's an accept or reject branch: if the rate isn't acceptable, the admin enters a new one and resubmits before it reaches the client. Pricing became something the system walks through, not a single form field.
When a booking is approved, standard rates are set for most common languages while admin sets a rate for rare languages. There's an accept or reject branch: if the rate isn't acceptable, the admin enters a new one and resubmits before it reaches the client. Pricing became something the system walks through, not a single form field.
Cost estimation with a fallback.
Cost estimation with a fallback.
The system checks whether a client-specific rate exists. If not, it falls back to a standard rate. This covers clients who don't have a negotiated rate yet, without blocking a booking estimate.
The system checks whether a client-specific rate exists. If not, it falls back to a standard rate. This covers clients who don't have a negotiated rate yet, without blocking a booking estimate.
Standard rates as shown to different stakeholders.
Standard rates as shown to different stakeholders.
Role-specific booking statuses.
Role-specific booking statuses.
The same booking looks different depending on who's viewing it. An interpreter sees their own progression (claim job, job assigned, job completed, payment received), while admin and client see a different set (draft, interpreter requested, interpreter confirmed, payment due, job completed), and admin's booking list adds operational states the other roles never see (pending review, timesheet received, rejected). Rather than one generic status field, each role only sees the states relevant to their part of the process.
The same booking looks different depending on who's viewing it. An interpreter sees their own progression (claim job, job assigned, job completed, payment received), while admin and client see a different set (draft, interpreter requested, interpreter confirmed, payment due, job completed), and admin's booking list adds operational states the other roles never see (pending review, timesheet received, rejected). Rather than one generic status field, each role only sees the states relevant to their part of the process.
Statuses as shown for different roles; admin > interpreter > client.
Statuses as shown for different roles; admin > interpreter > client.
First-come job claiming, with backup logic.
First-come job claiming, with backup logic.
Interpreters see available jobs and claim them. If two try to claim the same job, admin can decide who gets it while the other is offered as backup and are on standby. The system doesn't double-book or simply reject the second person.
Interpreters see available jobs and claim them. If two try to claim the same job, admin can decide who gets it while the other is offered as backup and are on standby. The system doesn't double-book or simply reject the second person.
Interpreters' view of Job Board.
Admin's view of assigning interpreter to a job.
Interpreters' view of Job Board.
Admin's view of assigning interpreter to a job.
Process & Outcome
Process & Outcome
Worked directly from client meetings, mapping the business's actual sheet-based process first, then redesigning it as role-based flows (admin, interpreter, client) with clear decision points at every branch where the old sheet process relied on someone's judgment call: is the rate acceptable, was the job already claimed, does a rate exist for this client. Each flow was built to turn one of those judgment calls into a clear system rule.
Worked directly from client meetings, mapping the business's actual sheet-based process first, then redesigning it as role-based flows (admin, interpreter, client) with clear decision points at every branch where the old sheet process relied on someone's judgment call: is the rate acceptable, was the job already claimed, does a rate exist for this client. Each flow was built to turn one of those judgment calls into a clear system rule.
Outcome
Outcome
Several manual, sheet-based processes in the business are now handled by the product:
Interpreter assignment to jobs, including the claim and backup logic above
Status and payment record-keeping, replacing manual tracking in sheets
Communication with interpreters and clients
Interpreter job applications, now a structured flow instead of ad hoc outreach
Timesheet calculations and the resulting payments owed to both client and interpreter
Several manual, sheet-based processes in the business are now handled by the product:
Interpreter assignment to jobs, including the claim and backup logic above
Status and payment record-keeping, replacing manual tracking in sheets
Communication with interpreters and clients
Interpreter job applications, now a structured flow instead of ad hoc outreach
Timesheet calculations and the resulting payments owed to both client and interpreter
Finances and other tracking systems digitised and automated.
Finances and other tracking systems digitised and automated.
Timesheet submitted by interpreter and viewed by the admin.
Timesheet submitted by interpreter and viewed by the admin.
© 2025 Amina Tayyub
© 2025 Amina Tayyub
© 2025 Amina Tayyub