<aside> 👋
In the design side of this sprint, most of the blogs relate to my general process. Obviously, there’s loads of small decisions in those that would be impossible to fully document. Also, some of these decisions will have taken form through users flows → sketching → wireframing, so would be hard to document throughout.
I’ve chosen to document some key design focussed decisions here instead of throughout, as I find it makes my write easier to follow.
</aside>
<aside> ➡️
During the branding process I had leaned more into darker neutrals and dark modes. This wasn’t plainly an aesthetic choice, as prioritising dark mode would have functional benefits too.
Primarily, dark mode uses less energy than light mode, which is particularly useful with transportation apps. Transport apps will already be relying on location services, will causes significant battery drain, so it’s important to find any other efficiencies to decrease battery usage, like dark mode.
Additionally, between day and night, or the interior lighting of transport vehicles, it’ll be hard to predict what sort of environment the user will be in, and dark mode tends to be easier to view in more lighting scenarios.
</aside>
<aside> ➡️
One of the challenges I had identified early was ticketing, due to the amount of variations and complexity. When interviewing users, there was a feeling that a lot of users would prefer to just “tap on” when boarding, similar to the system TFL uses in London. This works great in London as you do this before even reaching the platform, so once you’re through the tap gates you can just board.
Traditionally, bus services allow passengers to buy on board from the driver, or more modern services have ticket vending at stops. In both scenarios users can also buy their tickets through the networks ticketing app too. This can allow for better ticket management as well as easier pass and discount usage. However, this can be frustrating due to poor UX.
Although the push for mobile ticketing can be frustrating due to poor digital structure, it does have real benefits to service speed. If drivers didn’t have to ticket every passenger boarding buses could spend less time at stops, and even open both sets of doors to allow for faster boarding. This is actually a main campaign point of Zoran Mamdani (Mayor of New York), who ran with the policy of making buses free to speed up services.
I think mobile ticketing could work really well if done more intelligently that just getting a user to find and buy their ticket. I think I could use situational guidance and notifications, as well as habitual learning to vastly speed up users being able to buy tickets, and in doing so, make services run faster.
Making the case for bus e-ticketing in the age of contactless
Explainer: Understanding the costs (and benefits) of making public transportation free
</aside>
<aside> ➡️
Just a small one, but for question screens, such as during the on-boarding, I’ll be following GOV.UK’s, one question per page design pattern. I’ve found this to work incredibly well and make for a faster and more focussed flow.
</aside>
<aside> ➡️
Something I’ve found from placement is power of design systeming from the start. Although this can slow wireframing a bit, it’s worth it in the long run as it makes adding styling a far faster process. It also saves time when I come back to prototype the product.
</aside>
<aside> ➡️
Something I was struggling with when wireframing was when to end my onboarding. Originally, it went:
Welcome → Account → Habits → Permissions → Find Networks → Billing
I was finding asking a user to enter their card details for faster purchasing to kill the flow, and might be seen as a bit predatory.
Moving that out of onboarding and instead being a home screen alert left me with:
Welcome → Account → Habits → Permissions → Find Networks
I felt this was a more natural place to end, as it could include nice animation to really feel like they’ve reached the end and are ready to use the app.
</aside>
<aside> ➡️
Something I’m quite conscious about is adapting to how network currently are, not how I’d like them to be. This is especially important within ticketing, as different networks use different systems, such as gate activation, inspections, or even timed tickets. It’s an interesting challenge as it restricts how certain flows can function, but something I feel is important to incorporate. The wireframing stage has been really useful to let me weed out any complex issues like this.
</aside>
<aside> ➡️
A key differentiator for my product is for it to work intelligently for the user. By this, I mean I want it to react to the users situation and offer different flows that fit for that user. For example, if a users goes to the same bus stop every morning to commute to work, they probably don’t need directions, so using the “go now” button wouldn’t make sense. Going further, they likely buy the same ticket everyday, so the app could automatically serve them the ticket when they open the app, with them just needing to hit pay.
It’s small efficiencies like this I want to include throughout, as while they don’t look like much, they would make the users life a lot easier everyday.
</aside>
<aside> ➡️
Similar to the previous blog, I’m also trying to hide as much complexity as possible, for example when a user is buying a ticket, they’ll be asked straight away if it’s just for them or they need to buy for someone else. If they select themselves, they won’t ever see a screen asking to add other passengers as we’ve established they don’t need it. Although this adds another screen, it makes for more contextual and understandable question, rather than just showing them a screen to add others.
This is just one of many examples of showing a user a simple question to hide an otherwise complex screen that they don’t need to see and would potentially slow them down.
</aside>
<aside> ➡️
</aside>