01 / Define
The problem to explore
A hypothetical city mobility app wants to offer one ticket across metro and buses. Commuters currently juggle cards, cash and multiple apps. Explore planning, paying and validating a multi-modal journey, including delays and transfers.
This is an original UXCharan practice scenario, not a commissioned client project or a validated research finding. Treat the problem as a hypothesis. Adapt it when your research points elsewhere.
Who to learn from
Daily commuters who combine metro, bus and auto rides in a large Indian city. Recruit consenting adults with relevant experience where possible; document recruitment limits and avoid claiming your sample represents everyone.
02 / Discover
Research before choosing a solution
Questions to investigate
- How do commuters decide between routes today?
- What causes stress at transfers?
Start with a small set of interviews or contextual walkthroughs that fits your access and consent arrangements. Compare two existing approaches to the same task. Separate direct observations, participant statements and your own assumptions. If primary research is not possible, clearly label desk research and list what remains untested.
Map the experience
Trace the task from its trigger through completion and follow-up. Identify where information, responsibility or confidence is missing. Choose one opportunity you can justify with evidence.
03 / Design
A manageable project scope
- Plan a multi-modal route
- buy one ticket
- validate at each transfer
Choose one primary device and a realistic context of use. Explore at least two approaches before refining a flow. Build only the screens and states needed to demonstrate the selected task; a complete production system is outside this brief.
Include the difficult moments
- Bus cancelled mid-journey
- phone battery low at the gate
- fare changes after a route change
Document loading, empty, error and success states where relevant. Consider keyboard order, text enlargement, contrast, meaningful labels and alternatives to colour-only status. Use synthetic data and a fictional brand; do not collect real medical records, credentials or payment information.
Project-specific artefact
A journey view that works offline at ticket gates.
04 / Test & improve
What would make the design work?
Can commuters complete a two-transfer journey without confusion about where and how to validate?
Turn this question into realistic prototype tasks. Record whether participants complete each task, where they hesitate, what they misunderstand and how much help they need. Choose success criteria before testing; report observed counts with sample size, rather than claiming statistically proven improvements.
Prioritise findings by impact on the task. Revise the flow and retest the most consequential change where possible. If you cannot retest, explain that limitation.
05 / Tell the story
Your submission checklist
- Problem framing, intended users, scope and your role.
- Research approach, anonymised evidence and assumptions that changed.
- Journey or flow, alternatives explored and reasons for your decisions.
- A journey view that works offline at ticket gates.
- Viewable Figma prototype or a shareable document, including key edge cases.
- Usability findings, before-and-after revisions and remaining limitations.
- A concise portfolio narrative that labels this as a self-initiated concept.
Show what you learned and changed. Do not invent testimonials, interview quotes, launch metrics, employment relationships or business outcomes. Disclose material AI assistance and verify generated content.
Share CS-55 for feedback →Useful methods for this project
- Research planning ↗ (opens in a new tab)
- Research consent ↗ (opens in a new tab)
- Design exploration ↗ (opens in a new tab)
- Usability testing ↗ (opens in a new tab)
- Accessible forms ↗ (opens in a new tab)
- Portfolio storytelling ↗ (opens in a new tab)
These sources inform the learning process; they do not validate the fictional scenario or endorse UXCharan. Explore more tools in the resource library.