Creating a Trip
Creating a trip only requires the information needed to make the journey work:
- Date
- Time
- Destination
- Trip name
Once created, Omawe generates a six-character alphanumeric code that can be shared with everyone joining the trip.
The idea for Omawe started with a simple observation: There are many location sharing apps that can tell you where someone is. But what if you only needed to know when everyone would arrive? I imagined a shared trip where every person is travelling towards the same destination. Once the trip begins, Omawe calculates each person's distance and ETA, then surfaces that information through a Live Activity. Instead of constantly opening a map, checking someone's location, or asking “How far away are you?”, the journey would simply become visible.
Once we had the concept, we needed to turn it into a journey that felt simple from the moment someone opened Omawe. We centred the experience around two actions: Create a trip or Join a trip. Rather than using a conventional tab bar, we designed a custom navigation interaction. Swiping the central circle left opens Create, while swiping right opens Join. Tapping either side works too, and once inside either flow, the circle becomes a home button. The interaction gave the two primary actions a clear spatial relationship while keeping the interface focused around the trip itself.
Creating a trip only requires the information needed to make the journey work:
Once created, Omawe generates a six-character alphanumeric code that can be shared with everyone joining the trip.
Joining is equally lightweight. A user enters the trip code, confirms that they want to join, and is added to the shared trip room. Before the journey begins, members can see who else is in the room, including their names and profile photos, but location sharing remains off. This distinction was important. Being part of a trip should not automatically mean sharing your location.
We also made an intentional decision around who could start a trip.
Anyone in the trip room can start it.
Limiting this action to the person who created the trip could create unnecessary friction. The creator might be further away from the destination, forget to start the trip, or simply not be the person who needs the journey to begin.
Once the trip starts, location sharing begins and the Live Activity becomes active.
From there, Omawe moves from setting up the journey to helping everyone keep up with it.
A Live Activity has to communicate while the user is doing something else. To understand how to achieve this, we looked at Uber, Uber Eats, Grab, and GrabFood, where information such as a driver's arrival time or an order's progress can be understood almost instantly. We noticed that these experiences consistently prioritise one immediate question rather than trying to expose everything at once.
For Omawe, that question became: “How far are we from our destination?” We made the destination and distance the primary visual information, supported by a simple directional cue to reinforce where the group was heading. Details such as the trip name, participant names, and other secondary information were deliberately kept within the main app rather than competing for attention in the Live Activity.
The result was less about making a smaller version of Omawe and more about deciding what the app needs to say when there is only a second to look.
From early concepts to the final interface, I contributed to shaping how Omawe looks, feels, and works. I explored user flows, designed key interactions, refined the visual hierarchy, and worked through the details that helped turn the concept into a cohesive product.
I took particular ownership of Omawe's visual language, from typography, spacing, iconography, and components to the interaction details across the app. I also helped extend this language into the Live Activity, Dynamic Island, onboarding, and other supporting experiences.
Alongside design, I contributed to building the product in SwiftUI, helping translate our designs into the frontend and refine the interface as it came together. This gave me the opportunity to work across both design and implementation, seeing how design decisions translate into a working product.
A cohesive product needed more than individual screens. I developed a shared visual system across typography, colour, spacing, iconography, components, and interaction states, giving Omawe a consistent visual language from the main app to the Live Activity and Dynamic Island.
Below is the full design document that guided the product from concept through to the final interface.
I explored LottieFiles to bring Omawe's onboarding to life, using animation to guide attention, create continuity between screens, and give the experience a little more personality.
Omawe started as a team concept and became a fully shipped product. After weeks of designing, building, testing, and refining, we released Omawe on the App Store, making the experience available beyond our Academy team. Seeing our work move from sketches and prototypes into something people can actually use was one of the most rewarding parts of the project.