top of page
Screenshot 2021-08-24 at 18.54.42.png

Project Description & Brief: 

​

Yeeb was a client and brief with admirable ambitions, goals and resources. They had set out to take over the UAE with the aspiration of becoming the newest delivery unicorn competing with brands like Gojek, Grab and WeChat. The end goal was to become the UAEs new super app within a 5-year timeframe.

​

We were approached to design the platforms required to power their business from start to finish. Our SOW only included the designs and branding for all platforms. The development had been arranged with a separate agency with a larger capacity. The timeline for the product designs was initially three months but finally extended to five. 

 

The design brief included a large budget and time for discovery - predominately focused on market and competitor research to ensure we took the right approach. But also how we could utilise features from each of these super apps and apply them to our solution. We needed to be wary of and ensure we captured in our research how the UAE market differs from the Indonesian/ Asian market, which had given birth to the initial super apps. Would the same things work in the UAE? How could we ensure and validate that this was the case? Also, how could we test this against users to understand the value, requirements and needs that were location specific to the UAE?

​

Platforms and scope

This project's scope was very likely one of the biggest ones I will ever work on during such a short timeframe. We were requested to have a sizeable technical understanding of the feature and design decisions throughout the process. The platform designs required in our SOW was: 

  • Marketing website

  • Customer platform

  • Driver platform

  • Merchant platform

  • Admin platform

​

- The platforms are described in further detail below.

​

Their unfair advantage

The key stakeholders of Ursila had worked across a lot of emerging market startups and shaped the architecture for some of the leading brands on the market such as Uber and Kareem. They had a broad understanding of the industry itself and the intricacies of the rules, regulations and constraints that applied to Dubai (the first city they would launch in). The client also had a broad range of connections in the area. This in combination with owning their driver fleet, independent merchants and a promise to be the first brand in this location to prescribe medication online and send it out for delivery.

Yeeb

My role/s:

​

Working in a small creative agency often means that you need to wear multiple hats. During this project, I believe I was wearing my whole skillset of hats and monitoring and designing the whole experience from start to finish.

​

Product management

Due to the size of the project, we needed two Product managers to ensure we were covering all areas of the product. How we divided the project and product between the two of us:

​

PM1 (not me) - Was in charge of communicating and coordinating with the development agency to ensure the product architecture we designed was in line with the project scope and timeline. Lead the research on the driver platform, analyse competitors and architecture.

​

PM2 (me) - I would lead the entire project's design process and communicate and align with our brand agency to ensure that digital/ print could be utilised across platforms. Ensure that all features and functionality were aligned with the client's needs, constraints, and expectations.

​​

Account management

I was in charge of keeping our client involved in our weekly progress and hosted weekly meetings where we discussed progress, tasks from both parties, deliverables and timelines for each phase of the project.

I also provided them with assets for their weekly board reviews. The assets required would include:

  • Google slides on competitor research/ market advantages in Indonesia that could be utilised in a new market (UAE)

  • Weekly check-ins to align on progress/blockers and tasks from various project parties for the week ahead.

  • Feedback and design review meetings, ensuring all discussions and action points were documented and shared across stakeholders.​

​

Design lead 

Due to the lack of design resources during this project and the very tight timeline, we contracted a small team of designers. The designers were allocated to design different parts of the platform according to their experience and strengths. We wanted to have one designer create all of the wireframes to ensure that all aspects and functionality were covered and linked together correctly. We had two designers creating the initial design system that would inform all of the high fidelity designs. My primary responsibilities whilst leading and assisting on the cross-platform designs were:

​

  • Managing our partner agency Beach - in charge of creating the branding.

  • Notion - ensuring all tasks and decisions were documented and tagged accordingly.

  • Managing design delivery timelines and communicating this to the external development agency.

  • Frequent check-ins with the developers to ensure we had the same understanding and approach on how certain features should look and perform.

​

Discovery & research

I lead the initial competitor research for all platforms. Based on the insights we gathered, me and the other PM collaboratively started summarising the required features for all platforms. We also informed the priority of each feature and mapped out the absolute essentials versus the nice to have. This led to a very long scope discussion lasting for weeks between the development agency and client (this is one for the books). I also did an extensive development of 24 different user personas. Why so many, you might ask? We had so many unknowns in regards to our user base. The users in Dubai also hosted an incredibly diverse range of inhabitants. First, we needed to ensure that they were all represented and who our main users would be and how we would provide them value.

Yeeb user personas

Marketing website​

​

Out of all of the platforms, designs required, this was the most straightforward one. The marketing website would act as the face of the product containing all of the essential vital elements, such as getting in contact, support, FAQs and applying for jobs - but predominately communicating the mission and vision of the product itself. Initially, we were planning to focus and build the marketing website as the first release. It would act as a "holding page, e.g. we are new on the market, but we have exciting things coming your way, sign up for our newsletter".

​

After further iteration and thought, it was prioritised to be built as the last part of the project. This due to the fact that we quickly understood that it'd be difficult to communicate the key components of a product without determining exactly what it was. We also wanted to ensure that the overall product brand was solid before giving it that magical marketing touch. ​​​

​​Process

​

Sitemap
We had a working session with the client where we aligned on the key features the website needed to include. This also being assessed side by side with what competitor brands were doing successfully. What functionality do we need on the website, and how do we communicate our brand?
​
Wireframe designs
To inform the copy and content, we needed to populate the site and align with our branding agency we created a semi high fidelity wireframe structure. - This is because our understanding and past collaborations understanding the importance of providing a more enticing and inspirational structure for guiding the next steps ahead. This was then sent into review with our client to align on the website's capabilities and ensure that we were capturing all the elements needed to communicate the product and brand.
​
High fidelity designs
We created all of the assets and copy needed in collaboration with our brand agency to deliver the message and brand approach for Yeeb. We also went through a couple of iterations, ensuring we were doing something unique, e.g. deviating from Uber, Grab and Gojek and ensuring a clear identity and tone of voice. Sometimes using competitor brands as a direct source of inspiration can be a successful approach. In this scenario, considering the project's ambition and scope, a unique brand identity was definitely required.

Customer platform​

​

Designing the customer platform was the most fun out of all of the platforms considering this would act as the face of the entire brand and where we'd predominately measure if we've achieved success. Mentioning the above also added an immense pressure of "getting it right" - had we understood our user's expectations and needs regarding how the product should act and perform?

​

Whilst designing the customer platform, we ran into multiple obstacles. One is probably the most common when everything isn't being developed and designed within the same organisation and company: aligning all stakeholder expectations and motivations. Us - as designers trying to design a platform that will provide the users with maximum value. Client - what will drive high conversion from the get-go? Engineers - do the designs align with our development timeline and budget? Navigating all of the mentioned expectations was extremely difficult and ended up blocking the design process immensely. After many difficult conversations regarding scope, it actually ended up with the client dropping the development agency to create and design their ideal solution.

 

This gave us the freedom to think big and disregard tradeoffs. The brief still clearly stated MVP, but it definitely wasn't an MVP in our eyes. To give you an overview of the "tradeoff" we were making to call it an MVP, we decided not to include a wallet functionality that could be used across platforms. Not only that but also that the wallet would work as a "charging point", e.g. you could use cash and card across platforms, and they would act as a token within the platform. As you might understand, this raised a bunch of concerns regarding legal issues, compliance, and the fear of turning into a money-laundering platform. We weren't trying to become the new bitcoin essentially. But, that was the ideal future motivation and would pave the way for the next phase of the product.

​

Challenges:

​

  • Loyalty points - I created a 20 - page presentation on how we could/ would approach this. There were a lot of conversations and compromises needed to come up with the end solution. This was predominately having to be navigated differently due to the conversation regarding the wallet functionality within the platform. If this was far on the future horizon or in the near future, we wanted to ensure we could create an interim solution that would easily adapt to the project's next stage. What we ended up creating was a token system. So fictional tokens that at some point could be turned into a real currency. The tokens wouldn't act as actual currency but as benefits, e.g. free delivery etc. These tokens were designed to work across platforms, Driver & Customer, initially but then transfer into the merchant platform. 

  • Subscriptions - Similar to how Amazon Prime works, having a subscription with Yeeb would provide you benefits such as free delivery. Essentially, it would own the same qualities as the loyalty points, but without assessing your liquidity as being a subscriber would provide you unlimited benefits. 

  • Referrals - Being a new product on the market, this is one of the easiest, most cost-efficient and impactful ways of getting your product into the hands of users quickly. In the same way, we'd be using tokens for loyalty points; we would also utilise the points coming from friend/ user referrals.

​

Process

​

Research

We did extensive competitor research where we broke down the features of each platform, why we liked them, how they were performing from a revenue point of view, and how or if we should incorporate them into our end solution. We also did a couple of interviews with users representing their target audience to ensure that we were taking the right approach and covering all product areas. 

​

Feature prioritisation

The platform we used to navigate all content, decisions and tasks throughout was Notion. - Notion....what a glorious product! To align on expectations whilst still being completely transparent in the way we prioritised different features, we used Notion similar to a Jira setup to define Epics, Task and Stories. I don't think it's rare to hear about the awkward conversation with a client stating the unattractive word realistic. Yes, this sounds amazing - but - is it realistic? And, is the right time to consider this now?

​

We created two integrated Notion boards to manage expectations and be completely transparent in our prioritisation. 

  1. MVP board - Separating all of the platforms and adding the key functionality that would be needed for all of these. The additional must-haves, a couple of nice to haves and parked the ideal solution ones into the board below:

  2. Ideas board - Features we had seen on other platforms that we considered a great add-on to the project but less of a priority. The ideas board also acted as a "reminder" - I think we all know how often in discovery processes we come up with great ideas that are poorly documented, and when you try to bring them back to life, half of the context is gone. This was something we were very keen to avoid. All ideas had value and thought behind them. If they'd be archived or never implemented, that was okay, but as a starting point, they all deserved the same attention and respect as any other.

​

Wireframe designs 

We were requested to not only design the wireframes for the product but also the architecture of how the customer would feed into various parts of the overall system and management platforms. We initially mapped out all of the key features for the MVP and defined the different touchpoints where we'd need to link it to other systems. Once this was done we started designing the wireframes for the MVP including additional ideas and features we identified as we mapped out the other parts of the product. 

​

High fidelity designs 

We created all of the assets and copy needed in collaboration with our brand agency to deliver the message and brand approach for Yeeb. We also went through a couple of iterations, ensuring we were doing something unique, e.g. deviating from Uber, Grab and Gojek and ensuring a distinguished our unique identity. 

Driver platform​

​

The client owned their own fleet of drivers. This was predominately due to avoiding a lot of constraints that would occur due to the number of legal restrictions for on-demand drivers in the UAE. Within the UAE, they have very strict regulations on contracted jobs. Specifically within this vertical of work. All employees were required to be full-time employees and not contract or commission-based. Due to the client owning their own fleet of drivers, we had very large freedom to create the ideal solution that would encompass and address both the customer and merchant needs and potential friction points. 

​

Challenges

​

  • Language - We needed to consider three languages for the driver platform. 

    • English - We needed to consider different levels of general English understanding due to the levels of overall language knowledge. We, therefore, needed to ensure we were using intuitive and generic language that would cater to both native speakers, ex-pats but predominately drivers with English as a second language.

    • Urdu - Most drivers within the client's driver fleet were initially from Bangladesh and therefore spoke Urdu. We would need to ensure that they had the language alternative in case of language difficulties.

    • Arabic - When translations to Arabic were needed it would also affect the complete UI of the product due to the language being read from right to left rather than the other way around.

  • Merchandise responsibility - In case things didn't go to plan - I.e. if a customer didn't receive all of the items or damaged on arrival, who would be responsible for this? The driver or the merchant? We created an offline solution to make sure we could encompass a policy for this that all user types were aware of to avoid potential issues.

  • Profile setup - We needed to create a function for Yeeb admins to approve the drivers' profile setup. E.g. ensuring they had chosen appropriate images and uploaded their personal details correctly.

  • Individual performance motivators - Since drivers wouldn't depend on individual performance reviews due to them being full-time employees and not contact/commission-based, we needed to come up with a new solution to motivate them to perform well - and be paid off for good performance. The way we decided to approach this was by incorporating a reward system similar to the customer platform. How we considered this to effectively work without having the client hand out bonuses for individual performances was by creating a cross-platform token system. E.g. if you performed well as a driver you could utilise your tokens in the customer-facing platform to buy merchandise for a free/discounted price. This would create an in product loyalty point/ token eco-system benefitting the drivers and motivating them to perform well without the organisation having to consider additional costs.

  • Location tracking - Many of the streets in Dubai does not have a clear specific location attached to them. E.g. if you enter an address, it doesn't mean that it's the exact location of the customer or merchant. We needed to ensure there was an easy and accessible way for the drivers to communicate with both of these touchpoints.

  • Account setup and permissions - We needed to consider how the drivers would interact with their personal accounts and what device and size they would predominately be using. We had a couple of discussions on whether an OTP would be a secure enough solution or need to request a secondary validation or a magic link sent to your email. We surprisingly noticed through user research that a large number of the drivers didn't have their email linked to their device and wasn't checked frequently. This would lead to the login and signup process becoming quite a tedious process for a large number of drivers. We, therefore, landed on using an OTP triggered by the native device on login to provide maximum ease and inclusion for all drivers. We also needed to create an integration with the driver fleets own platform so that we could seamlessly feed in the shifts allocated to the drivers within our platform.

  • Acceptance rates and waiting times - We needed to think of a system where it would be easy for the drivers to accept orders within their driver's zone and have an easy way of accepting new orders. We needed to think of a system that would allow multiple drivers to accept the same orders to ensure that the waiting time was minimal - and in this scenario, consider the frustration it might cause a driver if they aren't quick enough to accept new orders. What we did to cater to this friction point was that we would provide the user in the closest proximity a ten-second timeframe when it was only available to that driver. After the ten second timeframe, it would go to the next driver in the closest proximity until it reached 30 seconds. After this, the order would become available to all drivers within the right delivery zone. 

  • Help centre - In case of emergency or issues happening, we needed to create use case scenarios for two types of enquires we needed to consider:

    • One being anything driver or vehicle related - E.g. Account setup, ​payment details or vehicle failures/ malfunctions.

    • The second being all things delivery related. E.g. Not being able to find your destination or user type. Also, in case things were to go wrong during the journey affecting the delivery time.

​

Merchant platform​

​

The merchant platform would be the order and inventory management for all partners on the customer platform. We needed to design a management system that would cater to the different industries and their individual needs. For the MVP, we would design a general management system that would work across all of the industries but as a next step, optimise it depending on the partner vertical. For future additions, we would, for instance, explore how we could incorporate an online booking portal between customers and GPs similar to Babylon health. 

​

The three verticals we needed to consider for future iterations were:

  • Restaurants, accepting orders.

  • ​Pharmacies, accepting orders and requests for prescripted medicines.

  • Merchants, receiving orders for single products or multiple items.

​

Challenges

​

  • Stock - The way small independent merchants managed their inventory offline through various spreadsheets and receipts, we needed to digitally onboard them. This was going to be a huge process but an essential one to ensure all product inventory was up to date. We also needed a hybrid solution for troubleshooting when orders contain items out of stock for the MVP. This would all be handled through an offline solution where we provided the merchants with the option to contact their customers directly to arrange refunds or substitute products within the same price range. 

  • Platform inventory - One of the biggest challenges when building one of these platforms from scratch is populating the overall customer facing inventory.  

    • Merchant inventory - ​This would act as the merchants' private inventory "collection". It would only show products that they had in their store and sold on the Yeeb platform. They would have the opportunity to browse for products they had recently added to their online store through the global product inventory. They would also be able to request additions to the global product inventory. They would do this by submitting products for review to ensure that the details were correct and that we didn't duplicate the same product within the global inventory. 

    • Global inventory - This would act as the product database containing all items sold across all merchants. The global product list would be managed through the admin platform. The individual merchants would submit requests for products that weren't featured in the global inventory for the admins to review and either approve, decline or request changes. 

  • Imagery - We needed to develop guidelines for how merchants would use their featured imagery for their shops and location to ensure consistency throughout the platform. Initially, we would hire a contracted photographer to take storefront photos to provide high-quality imagery for users who couldn't produce or have access to this. We also needed to consider product imagery but would tackle this once we defined the need for uploading that weren't featured in the global inventory system.

  • Language - merchants not being proficient in English (translations to Arabic needed - would also affect the designs due to the language being read from right to left rather than the other way around.)

  • Location - many of the streets in Dubai does not have a clear 

  • Merchant scale - We would feature merchants at different scales within the platform. We would have independent merchants who only owned single stores. We would also feature merchant franchises alongside larger scale merchants such as Wholefoods. We needed to ensure the merchant platform would work and encompass all of their needs and requirements. 

  • Merchandise responsibility - In case things didn't go to plan - I.e., if a customer didn't receive all of the items or if they were damaged on arrival, who would be responsible for this? The driver or the merchant? We created an offline solution to make sure we could encompass a policy that all user types were aware of to avoid potential issues.

  • Merchant private driver fleets - Merchants within larger organisations would sometimes have their own driver fleet. We needed to consider how to utilise them equally as our driver fleet to provide our users with their orders within the shortest timeframe. Initially, we were researching how we could create a hybrid solution for this. In the end, due to the complexity of feeding in all individual merchants driver fleets into our platform, we decided only to have our driver fleet collect items from the merchants. 

Admin platform​

​

The admin platform would serve as the mothership of all platforms. It would manage all aspects of the product. To delegate platform responsibilities and ensure all product areas were covered, we needed to define sub-admins and what their roles and permissions would fall under each category. 

​

Challenges

​

  • Permissions

    • Admins/ agents - ​Access to all accounts details and permission to change, approve and update everything across the platform. Internally we called this a "super admin". 

    • Sub admins -

      • Organisation admins - These admins would be responsible for all internal communication and organisation between departments ensuring everything was working correctly and that customer/merchant/driver enquires were followed up on and actioned where needed.

      • Merchant admins - These admins would be connecting the dots between verticals and customers. They would be responsible for independent merchants and chains, ensuring everything was working between internal and external inventory management systems. They'd also be in charge of QA and follow up on individual merchant performance and reviews. 

      • Driver operator admins - Admins from Yeeb managing the interaction between the driver fleet and Yeeb. These admins would ensure that deliveries were on time and that individual driver performance and targets were being met. Their responsibilities would also include following up on ratings and customer feedback to communicate back to the driver operators. The driver operator admins would also collaborate with the driver operator when arranging shifts in specific zones and hours based on the demand throughout the day/week/year.

​

​

The outcome​

​

We ended our collaboration with the client in February 2021.

This was due to the lack of additional resources on their part. Before ending our collaboration, we handed over an extensive report of all of the research made and how that had informed our decisions. We provided them with a summarised overview of how the platforms would interact and where the key touchpoints were to inform the architecture and build. We also handed over the designs for all platforms, including branding and bespoke imagery. 

​

Since we parted ways, the client has let us know that they are working together with the engineering agency to bring our designs to life - so who knows, maybe Yeeb will be out in the world and the hands of the public within the imminent future?

​

​

Admin platform
Driver platform
Merchant platform
Customer platform
Marketing website
bottom of page