Rehlati

About Rehlati

This is a story about the first time we used Design Sprint back in 2019. We’ll share with you how we set a goal to increase data accuracy and how a Design Sprint helped us achieve this goal. This results in the development of a prototyped, user-friendly app that received positive reviews.

The purpose of Rehlati app is to automate passenger movement, monitor fleet utilization, and provide usage visibility. The web and mobile-based application for corporate commuting services provide passenger booking and verification, bus management and monitoring, as well as monitoring of fleet utilization and reporting.

Also, Rehalati allows charging mechanism for all the commuters, tracking and reporting of journey and booking, creating various reports, which provide complete visibility of transportation service such as the utilization of busses on daily basis and per route, no. of passengers per company, no. of passengers per contract, etc.

Wait, but what is a Design Sprint?

Everyone is probably familiar with Design Thinking, a methodology that starts first and foremost from the customer perspective. Design Sprint 1.0 is a five-day process (developed at Google Ventures) for answering critical business questions through design, prototyping, and testing ideas with target users.

Working together in a sprint, team members can shortcut the endless debate cycle and compress months of time into a single week or more if necessary. It would normally take four to five days to complete this sprint in an actual work situation, but as we’re working with PDO and Al Sumri transportation employees, we’ve squeezed it into four days to allow the employees to focus on their work. Learn more about Design Sprint here.

‍

‍

‍

‍

Preparation

You can write here as much as you want, this text will always look nice, whether you write longer paragraphs or just a few words. Click here and try it out.

‍

The Design Sprint Process

• Pre-Sprint: Researched similar transportation apps in Oman and globally to understand potential features, watch AJ&Smart YouTube videos, and review Sprint book by Jake Knapp to know all the tips and tricks of each exercise.
• Day 1 (Map): The first day is about making a plan and getting focused. This day’s activities help define critical questions, our long-term goal, hear from experts and pick an area that we want to focus on.
• Day 2/1 (Sketch): Once completed, everyone gets to look for potential solutions online and flex their hand by sketching solutions individually.
• Day 2/2 (Decide): During the third day, our team looked at the potential solutions and started a series of voting to decide what features to be embedded in the app.
• Day 3 (Prototype): The designer creates a high-fidelity prototype based on our voting exercise so we something tangible and visual for the users.
• Day 4 (Testing): During the final day, we tested our prototype with five different users in one-on-one interviews to gather feedback and take a look at what we have achieved and our possible direction.

Objectives

• Review and validate functional requirements
• Prioritize delivery of requirements
• Align all stakeholders

Team

We worked on Rehlati along with e-mushrif to deliver the app and web application. PhazeRo supplied e-mushrif with product designers to understand customers' need and align it with business goals. Also, the product designer took the overall responsibility for the visual design.

‍

‍

Now that we’ve outlined the basics of a Design Sprint let’s go a little deeper on how we actually did it.

‍

Day 1 — Define the Challenge

We spent the first day studying the product by using similar mobile apps and looking through user reviews on Apple’s AppStore and Google’s Playstore. This step gave us an idea of what users are actually looking for when using a bus booking app.

‍

Expert interviews and How-Might-We questions

“Ask the Experts” is a learning activity where a team member gets to interview experts from their chosen subject. As our facilitator, Awadh asked each of the team members to describe the product with questions like:

• What is the product?
• What is the problem that the product is trying to solve?
• Who is using it? / who do you like to use it?
• If there were no problems, what would the product look like in two years’ time? What would be the ideal situation?

While the experts talked, the rest of the team recorded the “How Might We…” questions using the insights and problems that they have heard.

‍

After having a voting session, we narrowed the HMW questions down to the three most important “How Might We…” questions. Among them were:

• How might we allow users to book their trips easily?
• How might we make the bus trackable?
• How might we Separate employees' and contractors' bookings?

Prioritize features

 Importance/Difficulty Matrix is a quad chart for plotting items by relative importance and difficulty. It lies in Understand phase and took around an hour to complete.

The items in the upper left quadrant are high-value because they yield great impact at a low price. The upper right quadrant items are considered strategic because they require large investments to get big results. The lower right quadrant contains luxurious items—costly endeavors with little return. And last but not least, The items that land in the lower left quadrant are characterized as targeted in the next phases. The goal o prioritize a list of items and understand their relevance to your project.

This involved proposed features by the client and us and the new features that came up after HMW’s and expert interviews.

‍

Golden path

Every application has multiple user paths through it. All these paths are valid. The Golden Path, or the Key Usey Journey as it is also called, is the key set of steps that a user takes to find a product’s real value. This path should be the ideal default and not focus on exceptions or errors.

As a team, we identified the golden path through the product thinking of stories, not the screens needed to accomplish the goal. Also, we highlighted the secondary paths, which are additional alternate path scenarios.

‍

Create maps

In order to visualize the user flow and see it in a bigger picture, we drew a map with several user groups and important steps: searching, deciding, booking, and traveling to the destination. Then, we listed the steps that fall under each main step as following:

‍

‍

We map out a user’s experience step by step through this activity as they encounter any problem space or interact with the product. Creating a map allowed the team to get into the mindset of the user and illuminates pain points, identifying opportunities to create new or improved user experiences.

We created maps for all personas:

• PDO employees
• Contractors
• PDO focal point
• Contractor focal point
• PDO admin
• Contractor admin
• Super admin

‍

Day 2 — Sketch

Crazy 8

After defining the questions that we were going to solve and collecting enough context about the problem, it's time to sketch the potential solution. Our goal is to brainstorm inspiring solutions as much as possible in a limited time. As a result, we run a ‘Crazy 8’ activity - a fast sketching exercise that engaged people to sketch at most eight ideas in eight minutes. Then, We hanged everyone's sketches up on a wall. Each participant had few minutes (<3 mins) to present their solution briefly. After reviewing HMW questions, each participant had unlimited votes to select the best idea or a specifically most inspiring part in the sketch.

‍

‍

Day 3 — Prototype

Paper prototype (Low-fidelity)

It is here! The goal of this day is to create a prototype that can validate our solution.

Before creating a digital prototype, the designer sketched it on paper, and it is definitely the easiest and simplest approach to test almost any interaction. While testing the paper prototype, we recorded a list of UI improvements and places where users were most likely to be confused and redesigned the screens.

‍

Digital prototype (High-fidelity)

The goal here is to make a digital prototype as real as possible so that the user testers would feel like they’re using a real product (or as close to one as possible). We used Sketch as the main designing tool and Marvel to generate prototypes. Of course, one day wasn’t enough to complete all screens, so we decided to focus on the main screens for the passengers.

‍

Day 4 — Testing

Once we are done with our prototype, we tested the screens with five different users. Why five, you may ask? Well, It’s proven that after three tests with a product, you’ll start seeing very similar answers.

‍

Questions to ask participants:

• What kind of work do you do?
• How do you book your trips currently?
• What do you like/dislike about the app?

Things to ensure them before they start:

• I am testing the prototype, not you. So just relax and do what you think you will do in real life.
• There are no right or wrong answers. You won’t hurt my feelings or flatter me. In fact, frank, candid feedback is the most helpful.
• As we go, please think aloud. Please tell me what you’re trying to do and how you think you can do it. If you get confused or don’t understand something, please tell me. If you see things you like, tell me that, too.
• Some buttons won’t work because I am testing only a few features, not the entire product.

Task scenario for them to be in the situation:

As a PDO employee, you have been selected to go to Qarn Al Alam for work. It’s not your first time, but what’s new is the app Rehlati that has been used recently to book trips to the interest areas. You downloaded the app and started searching for a bus.

User tasks:

1. Book a trip from Mawalih to Qarn Al Alam.
2. You’re at the bus stop now. Prepare yourself to catch the bus by opening your ticket.
3. Track the bus and see when you’ll arrive at Qarn Al Alam.
4. The journey was wonderful, rate the trip.

After testing the app:

• What did you like about this product?
• What did you dislike?
• If you had three magic wishes to improve this product, what would they be?

Results

‍

What do users think about the app?

‍