case study
Building a functional mobile transport app with Cursor
Intro
This was a personal project unrelated to InvestorFlow.
The bus transport company only had a website for booking and tracking journeys, but it wasn't tailored for mobile. The goal was to create a mobile app, with the main focus of refining and enhancing existing features instead of introducing too many features.
Task
To design and build a functional mobile app, showing the searching, booking and tracking a journeys.
Results
In less than two days I designed and built my first mobile app with Cursor, using real end-points to show live data of bus route availability, delays and departure statuses.
Role
Sole designer and engineer
01
Setting out initial goals
With a short timeframe, I focussed on:
Reducing cognitive load by refining copy and improving hierarchy
Making perks, e.g. free large luggage hold, and pricing, e.g. free concession and young child tickets, more transparent
Improving accessibility with text size/contrast, applying minimum touch targets and creating visually disabled button states
02
Enhancing the search process
As a user, when searching for stops I want to quickly see previous searches and scan relevant search results to find what I'm looking for.
The existing screens made it unclear if the ‘recent stops’ were ones I previously booked or simply searched for, and stops were difficult to scan as prominent locations were repeatedly listed alongside each stop name.
I focussed on improving the hierarchy of results by grouping stops by prominent locations, limiting icon usage to recently search stops and prominent locations, and highlighting matching characters.
Existing search
Proposed search
The 'passengers' modal was cramped, inaccessible and it wasn't obvious when I'd exceeded the limit for selections. Using the word 'extras' to describe a wheelchair also felt like an afterthought for something that is essential for some passengers.
I changed group names, improved descriptions to communicate perks and pricing. I also added another field for additional luggage as this was something that was already a perk, but hidden in the website FAQs.
To improve accessibility, I added disabled states for buttons when limits were reached, and increased the button sizes to comply with minimum touch targets.
Existing passenger selection
Proposed ticket selection
03
Adding value to the timetable view
One of the limitations of the existing timetable view was the lack of visibility of my search in relation to the tickets I could purchase. Poor hierarchy meant that tickets were difficult to scan and compare, too.
Bringing the search information into the page reduced confusion about the route that was being searched for, and simplifying tickets meant that tickets were easy to scan, with important information such as delays or limited availability having more prominence. I also added any easy way to switch journey direction for the first leg with one click.
Existing timetable
Proposed timetable
04
Simplifying the booking confirmation
While the booking confirmation was clear, it took up a large proportion of the screen. If I booked a journey that wasn't immediate, the map for live tracking wasn't useful as this only showed live data when the bus due to arrive within 60 minutes. Any functionality for changing the booking was also hidden and didn't comply with minimum touch target requirements for mobile.
I made the ticket details more obvious and exciting, removed unnecessary noise and made actions more prominent and accessible. A button to view live information meant that I could view the journey details if my ticket was purchased for a journey in the next 60 minutes.
Existing confirmation
Proposed confirmation
05
Tracking a live journey
The existing live tracking looked exactly the same as the booking confirmation page.
I separate these two flows and put more focus on the bus' live location, the journey time, the bus numberplate and the stops that it was visiting on the journey.
Proposed live tracking
06
What did I learn?
Before I cover the lessons in this journey, pun intended, I want to say how impressed I was with the output in the short time frame. This was my first time using live end-points, and my first GitHub repo using AI to build an app. A lot of things were new to me for this task and I'm pleased with the end result.
Now, lessons:
Firstly, I needed to let go of strict process to be able to achieve so much in the short timeframe. This meant ideas were rough before I started mocking up designs to push to code.
Secondly, because I was focussed on execution, I skipped steps that would have saved me some time tinkering at the smaller details later on. Things like confirming text styles and standardising icons immediately which I had to fix at later stages.
I underestimated how long it would take me to get set up (creating accounts, learning the most efficient ways to prompt and plan - doing this again, I'd know where to begin.
Using plan mode saved me hours, and highlighted areas of weakness or certain paths that I'd not provided designs for.
Designing screens in Figma and uploading pngs/links to the frame meant that the first pass screens were generally decent, and changes were relatively easy to implement. Building purely from prompts would have produced a much lower output.
There are some improvements that I would polish if I gave myself more time, but I'm happy that I managed to get all flows fully functional in the timeframe!