Shuttlers

Overview

Designing for mobility in a market like Nigeria comes with a unique set of challenges. Transportation is an essential part of people's daily routines, and users depend on the product to make decisions that directly affect their time, productivity, and ability to get where they need to be.

During my 4.5 years at Shuttlers, I contributed to the evolution of its core customer application, working across booking experiences, route discovery, subscriptions, referrals, safety features, and several usability improvements.

Two projects stood out in particular: redesigning how riders understood their trips and preparing the application for international expansion.

While different in scope, both reinforced a principle that guided much of my work at Shuttlers: designing for clarity, accessibility, and the realities of the people using the product.

The Problem

Building a reliable mobility product requires more than making it easy to book a ride.

Users need to understand where their journey begins, when to expect their vehicle, and what happens throughout the trip. Every uncertainty introduces friction into an experience already influenced by traffic, schedules, and real-world operational constraints.

At the same time, Shuttlers was preparing to expand beyond Nigeria into markets with different languages, reading patterns, and cultural expectations.

This introduced two distinct challenges.

Making everyday journeys more predictable

The existing route experience did not communicate enough information about the different stages of a trip.

For riders, this made it difficult to understand when their vehicle was expected to arrive and how their journey would progress.

The resulting uncertainty contributed to customer support enquiries and created avoidable friction in the booking experience.

Preparing a Nigeria-first product for international markets

The application had originally been designed around English-speaking users in Nigeria.

As the business explored expansion into Côte d'Ivoire, Egypt, and other markets, the existing interface needed to accommodate different languages, text lengths, typography, and layout directions.

The challenge extended beyond translating interface content. The product needed a flexible design foundation that could support new markets without requiring an entirely different experience for each.

My focus was to improve the reliability of the existing customer experience while helping establish the foundations for the product's next stage of growth.

The Solution

Across both initiatives, I approached the work with a shared design objective: reduce uncertainty and make important information easier to understand.

For the route experience, this meant rethinking how trip information was organized and introducing a more complete view of the journey.

For internationalization, it meant adapting the product's design patterns to support different linguistic structures while maintaining a consistent experience across markets.

The work was guided by three principles:

• Clarity: Give users the information they need to understand their journeys and make informed decisions.
• Accessibility: Ensure the interface remains readable, usable, and approachable across different user groups and languages.
• Scalability: Make design decisions that can support evolving product requirements without introducing unnecessary inconsistencies.

Design Process

01. Route Card Redesign — Making Every Journey More Predictable

One of the challenges I encountered early in my time at Shuttlers was how the application communicated trip information.

Although the route card occupied a relatively small part of the interface, it played an important role in how riders understood their bookings.

The existing experience offered limited visibility into the different stages of a journey.

Users often struggled to determine when their vehicle was expected to arrive at their pickup location, creating uncertainty around a fundamental part of the service.

This was particularly important because transportation decisions are time-sensitive.

A rider who doesn't understand when to expect their vehicle may arrive too early, miss important trip information, or contact customer support for clarification.

The opportunity was to make the route card more than a summary of a booking. It needed to become a reliable source of information throughout the journey.

Exploring the Information Hierarchy

I worked through multiple iterations of the route card, exploring how we could communicate more useful trip information without overwhelming users.

The challenge wasn't simply adding more details to the interface.

It was understanding which information mattered most, when it mattered, and how the different stages of a trip could be represented clearly.

I focused on improving the visibility of route information and introducing a more complete timeline that helped riders understand the progression of their journey.

This required balancing information density with scannability, ensuring users could understand their trip at a glance without navigating through unnecessary details.

Designing the Journey Timeline

The redesigned experience presented a clearer view of the trip, making it easier for riders to understand the relationship between their pickup point, the journey's progression, and their destination.

Rather than relying on a limited representation of the route, the updated design gave users more context about what to expect.

Several iterations were explored and refined as we evaluated how the information could be presented more effectively.

Although the route card was a relatively small component within the wider application, improving it addressed a recurring point of uncertainty for riders.

Impact

The route card improvements contributed to a significant reduction in customer support enquiries related to trip visibility.

More importantly, the work demonstrated how a focused improvement to an everyday interaction could positively influence the broader customer experience.

It reinforced that impactful product design isn't always about building new features. Sometimes, it's about making an existing interaction communicate the right information at the right time.

02. Internationalization — Designing Beyond a Single Market

As Shuttlers prepared to expand into new countries, the customer application faced a different kind of challenge.

The product had been designed primarily for Nigeria, with interface patterns and content structures built around English.

While this worked for the original market, it introduced limitations as the business explored French-speaking and Arabic-speaking regions.

I worked on adapting the product experience for internationalization, with particular attention to French for Côte d'Ivoire and Arabic for potential expansion into Egypt.

This was my first experience working on a product that needed to accommodate fundamentally different language and reading systems.

It challenged several assumptions I had previously made about designing interfaces.

Researching Language and Cultural Differences

I began by researching internationalization and localization practices, studying how established digital products adapt their interfaces for different markets.

My research included design publications, technical resources, and industry discussions covering multilingual interfaces, typography, and right-to-left design.

One of the most important lessons was understanding that translation and localization are not the same thing.

Changing the language of an interface doesn't automatically make it usable for people in another market.

Language affects how information is structured, how components behave, and how users navigate an experience.

This realization influenced how I approached the design work.

Adapting the Experience for French

French introduced challenges around text expansion.

Labels and interface content that occupied relatively little space in English could become significantly longer when translated.

This affected button widths, navigation elements, content containers, and other components that had originally been designed around shorter strings.

I explored adjustments to typography, spacing, and layout behavior to accommodate longer translations while preserving readability and visual consistency.

The objective was to ensure the French experience felt native to the product rather than like translated content forced into an English interface.

Designing for Arabic and Right-to-Left Interfaces

Arabic presented a more substantial design challenge because it required reconsidering the direction and structure of the interface.

Unlike English and French, Arabic is read from right to left.

Supporting this meant exploring how navigation, content alignment, directional elements, and interface hierarchy needed to adapt.

However, simply mirroring an existing layout wasn't enough.

I also examined the typographic characteristics of Arabic, including how font families, weights, and sizes influence readability.

We evaluated Arabic-compatible typography and how it could work within Shuttlers' existing visual identity.

A key consideration was maintaining consistency across markets without forcing users into layouts or typographic conventions that felt unnatural for their language.

The experience needed to feel intentional, not like an English application that had been reversed.

Building for Future Markets

One of the most important considerations was avoiding a solution that worked only for French or Arabic.

Shuttlers was exploring opportunities across several international markets, which meant the design approach needed to account for future language requirements.

I worked within the existing design system, identifying where components needed more flexibility to accommodate different text lengths, reading directions, and typographic requirements.

The goal was to preserve a recognizable product experience while making the interface adaptable to different markets.

This created a more scalable foundation for localization, reducing the need to redesign core experiences whenever a new language was introduced.

Impact

The French localization work supported Shuttlers' launch in Côte d'Ivoire, helping make the customer application accessible to a new market.

Beyond the initial expansion, the project established important design considerations for supporting additional languages and regional experiences.

For me, the impact went beyond introducing new translations.

It changed how I approached product design, encouraging me to think more critically about assumptions that might work in one market but become limitations in another.

Outcome & Reflection

Working on the Shuttlers Customer App gave me the opportunity to design for a product that people depended on as part of their everyday lives.

Over four and a half years, I contributed to improvements across the customer journey, from booking and route visibility to subscriptions, referrals, safety, and internationalization.

The route card redesign demonstrated the value of improving small but high-impact interactions, contributing to clearer trip visibility and fewer customer support enquiries.

The internationalization initiative expanded my understanding of inclusive design, helping prepare the product for new markets while preserving a consistent experience across languages.

Together, these projects reinforced two important lessons.

First, usability is not simply about how quickly users can complete an action. It's also about how confidently they can understand what's happening and what to expect.

Second, building products for scale requires thinking beyond the needs and assumptions of the market you're designing for today.

The best product experiences aren't just easy to use. They're reliable enough to earn users' trust and flexible enough to serve people beyond the environment in which they were first created.

Admin SystemConfiguration, coordination & operational controls

• Vehicle PartnerFleet & earnings
• PilotTrips & boarding
• SquadPassenger coordination

Customer ExperienceReliable bookings, boarding & completed rides

Overview

While the customer application provides a seamless way to discover routes and book rides, delivering that experience requires a much more complex operational system working behind the scenes.

From vehicle partners managing their fleets to pilots operating trips, marshals coordinating passengers, and internal teams overseeing daily operations, every part of the ecosystem plays a role in ensuring rides run smoothly.

During my 4.5 years at Shuttlers, I contributed to the design and evolution of these interconnected operational products. I led the initial design of the Vehicle Partner App and worked extensively across the Pilot App, Squad App, and internal administrative tools.

The challenge was to make complex transportation operations feel simple for the people responsible for keeping thousands of journeys moving.

The Problem

A successful ride involves significantly more than a customer booking a seat.

Behind every trip are several operational activities: assigning vehicles and pilots, managing routes, coordinating passengers, monitoring trip activity, and ensuring vehicle partners have visibility into their earnings and operations.

These responsibilities are distributed across different user groups, each with distinct needs.

Vehicle partners need to understand how their assets are performing. Pilots need to manage trips while staying focused on driving. Marshals need to coordinate passengers efficiently, while internal operations teams need the tools to manage the wider transportation network.

Building for these users introduced three major challenges:

• Different levels of digital familiarity: Particularly among vehicle partners, many of whom were older adults and needed interfaces that were easy to understand without extensive guidance.
• Time-sensitive operations: Check-ins, trip management, and passenger coordination needed to happen quickly, often in busy boarding environments.
• Interconnected workflows: Decisions made within internal administrative tools directly influenced what pilots, marshals, and vehicle partners could see and do.

A poorly designed interaction in any part of this ecosystem could introduce friction into the wider transportation experience.

The design challenge wasn't simply to make each application usable. It was to make the entire operational system more efficient, while ensuring each user had the tools and information relevant to their responsibilities.

The Solution

We approached the operational ecosystem as a collection of connected, purpose-built experiences rather than a single interface attempting to serve everyone.

Each product was designed around the decisions its users needed to make and the actions they performed most frequently.

The ecosystem consisted of four primary touchpoints:

• Vehicle Partner App: Fleet visibility, earnings management, daily operations, and bidding on available routes.
• Pilot App: Assigned routes, trip management, passenger information, and check-in activities.
• Squad App: Passenger manifests, boarding coordination, check-in and check-out, and incident reporting for marshals.
• Admin System: The operational control layer for configuring routes, managing clusters, coordinating fleet activities, and supporting internal business processes.

Across these products, the overarching design principle was consistent:

Make essential information visible, reduce unnecessary decisions, and help users complete critical tasks with as little friction as possible.

Design Process

01. Understanding the Operational Ecosystem

Designing for Shuttlers' operational teams required understanding how the business functioned beyond the customer application.

Unlike a typical consumer product, these interfaces were used by people performing specific responsibilities in real-world environments, often under time constraints.

The first consideration was identifying what information each user needed, what actions they performed repeatedly, and how their activities connected to other parts of the system.

While the products shared an operational foundation, their interaction requirements differed considerably.

A vehicle partner reviewing earnings needed clarity and visibility. A pilot managing boarding needed speed. A marshal coordinating passengers needed accurate manifests and immediate access to passenger actions.

This distinction shaped how I approached the architecture and priorities of each product.

Rather than enforcing identical experiences across every application, I focused on creating interfaces suited to each user's operating context while maintaining consistency where it mattered.

02. Vehicle Partner App — Designing for Clarity and Accessibility

One of my earliest major responsibilities was leading the design of the Vehicle Partner App from its initial phase.

Vehicle partners are individuals and businesses that supply vehicles to the Shuttlers network. The application needed to provide visibility into their assets, operational activities, and financial performance without requiring constant assistance from internal teams.

The core experience revolved around three needs:

Understanding earnings and vehicle performance

Partners needed a straightforward way to track their earnings, review their vehicles, and understand the day-to-day activities associated with their fleet.

I prioritized clear information hierarchy, making important financial and operational details immediately accessible rather than burying them within secondary navigation.

Making route opportunities accessible

Beyond monitoring existing operations, partners could bid on newly available routes.

This introduced a different interaction requirement: helping partners discover relevant opportunities, understand the information presented, and submit bids without unnecessary complexity.

The focus was on creating a direct and predictable journey from reviewing an opportunity to taking action.

Designing for varying levels of digital familiarity

A particularly important consideration was the demographic of our vehicle partners.

Many were older adults, which meant the application needed to remain approachable for users with different levels of confidence using digital products.

This informed decisions around navigation, visual hierarchy, interaction patterns, and the number of steps required to complete essential tasks.

I paid particular attention to making actions recognizable, presenting information clearly, and reducing unnecessary navigation.

The goal wasn't to create a feature-heavy fleet management product. It was to give partners immediate access to the information and actions they needed to manage their relationship with Shuttlers confidently.

03. Pilot App — Optimizing for Speed of Execution

The Pilot App served a very different user group: drivers responsible for operating Shuttlers' vehicles and managing assigned trips.

Pilots needed access to routes assigned through the internal administrative system, trip information, and passenger-related actions.

However, their operating environment introduced an important constraint.

Unlike vehicle partners, who might review their information at their convenience, pilots often needed to perform actions within narrow operational windows.

Passenger boarding was a particularly important consideration.

The check-in experience needed to be fast, recognizable, and easy to execute without navigating through unnecessary screens.

My work focused on improving the visibility of assigned trips, simplifying passenger check-in interactions, and ensuring essential trip information could be accessed with minimal effort.

During my time at Shuttlers, the Pilot App also underwent a visual rebrand and experience improvements.

I contributed to this evolution, revisiting existing interaction patterns and participating in collaborative brainstorming sessions to identify opportunities for improvement.

The experience continued to evolve through subsequent iterations as operational needs became clearer.

The guiding principle was to design around the realities of a pilot's workflow, prioritizing speed and clarity over unnecessary interface complexity.

04. Squad App — Simplifying Passenger Coordination

Not every Shuttlers route operates with a driver managing passenger activities independently.

Some routes require marshals: operational personnel who accompany the vehicle and coordinate passenger-related activities, allowing pilots to focus on driving.

The Squad App was designed to support these responsibilities.

Its primary functions included:

• Viewing daily trip manifests and passenger information.
• Checking passengers in as they boarded.
• Checking passengers out at the appropriate stage of their journey.
• Raising complaints and reporting operational issues.

Similar to the Pilot App, the central design consideration was execution speed.

Marshals needed to move through passenger lists, identify riders, and complete boarding activities efficiently, particularly during periods when several customers might be boarding in quick succession.

I focused on keeping the most important information visible and reducing the effort required to move between passenger records and common actions.

The experience needed to remain straightforward enough for repetitive daily use while supporting the accuracy required for passenger coordination.

Although the Pilot and Squad apps supported overlapping trip activities, their workflows were designed around different operational responsibilities.

This distinction was important in ensuring that both products served their users effectively without introducing unnecessary functionality.

05. Admin System — Designing the Operational Control Layer

The customer-facing and field applications depended heavily on the internal administrative platform.

Throughout my time at Shuttlers, I worked on several administrative capabilities that supported the wider transportation network.

These included tools for:

Route and cluster management

Supporting how internal teams created, configured, and organized routes and route clusters across the network.

These workflows needed to accommodate operational complexity while keeping configuration tasks understandable and manageable.

Fleet and operational coordination

Designing administrative functionality supporting vehicle assignments, operational adjustments, and the activities that influence how trips are executed across the network.

Internal marketing and campaign management

I also worked on tools that allowed internal teams to manage marketing-related activities more independently.

A key objective was reducing reliance on engineering for routine administrative operations.

Rather than requiring developers to intervene each time a team needed to make certain changes, we explored ways to bring those capabilities into the administrative interface.

This enabled more self-service operational workflows and created a stronger foundation for internal teams to manage their activities.

The broader design objective was to translate recurring business processes into manageable product capabilities, reducing unnecessary manual coordination and technical dependencies.

06. Iteration & Cross-functional Collaboration

Across the operational ecosystem, design was an ongoing process rather than a one-time delivery.

As products evolved, new requirements emerged from day-to-day operations, stakeholder feedback, and the changing needs of the transportation network.

I worked with product managers, engineers, and internal stakeholders to explore improvements, refine workflows, and balance user experience goals with implementation considerations.

Several decisions required trade-offs between ideal interaction patterns and the practical realities of running a transportation business.

For me, the most important consideration was preserving the simplicity of the experience even as the underlying operational requirements became more sophisticated.

This meant continually questioning whether information needed to be visible, whether an interaction could be shortened, and whether recurring activities could be supported through clearer system behavior.

Over time, this approach influenced how I designed across connected products, moving beyond individual screens to consider how decisions in one system affected users elsewhere in the ecosystem.

Outcome & Reflection

My contributions helped shape the operational products supporting Shuttlers' daily transportation activities, from vehicle partner management and trip execution to passenger coordination and internal administration.

The work established and refined experiences around the different needs of partners, pilots, marshals, and operational teams, with a consistent focus on clarity, efficiency, and ease of use.

Leading the initial Vehicle Partner App and contributing to the evolution of the wider operational ecosystem strengthened my ability to work across complex, interconnected systems.

It also changed how I thought about product design.

Designing for operational users requires understanding more than what happens on a screen. It requires understanding the physical environment, the responsibilities people carry, and how individual actions contribute to a broader service.

My biggest takeaway was that the quality of a customer experience often depends on the systems customers never see.

Designing those systems well means giving the people behind the service the clarity, control, and efficiency they need to deliver it consistently.

Overview

As the platform evolved, I identified an opportunity to rethink its website, moving it beyond a traditional marketing touchpoint into a more functional extension of the Shuttlers product ecosystem.

I initiated the redesign proposal and led the project end-to-end, taking ownership of the design direction, project coordination, and cross-functional execution.

My role extended beyond designing interfaces. I coordinated designers, collaborated with product managers and developers, and worked directly with company leadership to align creative ambitions with business priorities and delivery requirements.

The Problem

Shuttlers had grown beyond what its existing website effectively communicated.

While the mobile app continued to evolve with new booking capabilities and product features, the website no longer adequately reflected the sophistication of the platform or the breadth of its mobility offerings.

The experience presented two key opportunities:

• A disconnect between the website and the product: The website wasn't effectively communicating the booking experience and key features already available within the mobile application.
• An opportunity to strengthen the business offering: Shuttlers needed a clearer way to showcase its vehicle services, explain its value to prospective customers, and guide different audiences toward relevant solutions.

Beyond improving its visual identity, the redesign needed to establish a stronger connection between product discovery, service understanding, and the actions users wanted to take.

The challenge was to transform the website from a primarily informational experience into a more engaging, product-led platform that could support both customer acquisition and business growth.

The Solution

I led the creation of a new website experience designed to function as an extension of the Shuttlers application while presenting the company's mobility services more clearly.

The redesign focused on three priorities:

Bringing the product experience closer to the web

We explored how the website could reflect the core booking experience, allowing visitors to better understand how Shuttlers works and creating a more direct connection between discovering the platform and using its services.

Making the business offering more visible

We introduced dedicated experiences to communicate Shuttlers' vehicle services, helping prospective customers understand the available solutions and their value.

Creating a stronger brand and product narrative

The homepage was restructured around the platform's most important features and offerings, supported by a refreshed visual direction, more purposeful content hierarchy, and motion-driven storytelling.

The objective was to create an experience that felt distinctly Shuttlers: functional, contemporary, and closely connected to the product itself.

Design Process

01. Identifying the Opportunity & Building Alignment

Unlike projects that began with an established product requirement, the website redesign was an initiative I brought forward after identifying a gap between Shuttlers' evolving product experience and its digital presence.

I proposed the redesign as an opportunity to improve how the business presented its services, communicated product value, and engaged potential customers.

Once the initiative gained alignment, I took responsibility for shaping the project's direction and coordinating its execution.

Working closely with company leadership, including a co-founder, I helped translate the broader business ambition into a practical design and delivery approach.

This required balancing the creative possibilities of a full website revamp with available resources, stakeholder expectations, and implementation considerations.

02. Defining the Experience & Creative Direction

The central design decision was to treat the website as an extension of the product rather than a separate marketing property.

I established the experience direction around connecting three important parts of the Shuttlers ecosystem: its booking experience, core product capabilities, and commercial mobility services.

This influenced how the homepage was structured, how features were presented, and how supporting pages communicated the company's offerings.

The goal was to ensure visitors could quickly understand what Shuttlers does, why its services matter, and how to take the next step.

Alongside the experience architecture, I led the visual direction, ensuring the redesign reflected a more mature and cohesive brand identity.

03. Leading a Cross-functional Team

My responsibility extended beyond individual design deliverables into coordinating the people and processes required to bring the project to life.

As Design Lead and Project Lead, I worked across multiple functions:

• Design: Led and coordinated contributing designers, aligning their work with the overarching experience and visual direction.
• Engineering: Collaborated with developers to translate designs into functional experiences, address implementation considerations, and maintain consistency between design and production.
• Product: Worked with product managers to align scope, requirements, dependencies, and delivery priorities.
• Leadership: Engaged directly with company stakeholders, including a co-founder, to review progress, align on decisions, and secure support for the project's creative and technical needs.
• External collaborators: Coordinated with leadership to bring in specialized animation talent where additional expertise was required to achieve the intended experience.

This required maintaining visibility across design, development, stakeholder feedback, and external contributions while keeping the team aligned on a shared outcome.

My focus was to preserve the integrity of the original product vision while ensuring the team could execute it effectively.

04. Design Execution & Delivery

With the direction established, I led the translation of the experience into high-fidelity designs and worked closely with the team to bring the website toward implementation.

The redesign emphasized clearer navigation, more effective product storytelling, and stronger visual consistency across the website.

Motion and animation were considered as part of the broader storytelling experience, helping communicate product capabilities and create more engaging interactions.

Throughout execution, I reviewed design decisions, coordinated feedback, and worked with developers and other contributors to resolve constraints as they emerged.

The project required thinking beyond isolated screens, ensuring that content, interactions, brand expression, and technical execution came together as one cohesive experience.

Outcome & Reflection

The website initiative brought together product experience, brand communication, and commercial storytelling under a unified design direction.

Beyond the redesign itself, the project represented a shift in the scope of my responsibilities at Shuttlers.

I moved from contributing to product experiences to independently identifying a business opportunity, proposing a solution, securing stakeholder alignment, and leading a multidisciplinary team through execution.

It reinforced an important lesson in how I approach design leadership:

Great product experiences don't begin and end in design tools. They require the ability to recognize opportunities, establish a clear direction, bring people together, and turn an idea into something the business can deliver.