Search
  • zotusme

Reachabl - UX Case study

Overview

Reachabl was founded by a couple of acquaintances of mine in the heist of the corona crisis. The service had one goal as a starting point - to offer tour-guides the possibility to conduct their “city walking tours” in a 360 immersive online format.



Problem Statement

One of the co-founders is a tour-guide herself and she along with all of her colleagues were experiencing a massive drop in their activities (like all tourism businesses) because of travel restrictions.

Seeing the entire world switch to remote-work mode provided a landscape for the question she was asking herself, as she told us: How would an online version of my service (walking-tour-guide) look like? The idea of getting back to work was enough to spark a chain reaction of applications such a service like this could provide - from E-learning to E-commerce to sports, etc.


Users and Audiences

The primary target group is tour-guides.

According to TripAdvisor, one could estimate that in London itself, there are <1600 day-tour activities listed.

Same goes for Berlin, Barcelona, Paris, London, and the list goes on. We also know that most tour guides we talked to didn’t bother about being listed on TripAdvisor, so the numbers are in fact much higher.

Anyway, They all experienced this sudden drop in activity and income, and they could all potentially benefit from such a service.


Based on some talks with tour guides and some portfolios of tour guides on platforms such as Walking-Guru and Trip-Advisor I came up with the following personas:







The secondary group is anyone who might enjoy such an online activity - That is the tour-guide’s audience, but we’ll worry about those later.


Roles and responsibilities:

In this setting I was responsible for the UX, UI and interaction design, as well as for a few other design related objectives.

I mainly collaborated with the development team, but also with the lead tour guide, who was a co-founder and the one in charge of representing the walking-tour community, as she had a years-long experience in guiding tours in Berlin.


Scope and Constraints

One main factor is the super tight budget, as this was an MVP project and fast shipping for demo purposes was crucial.

In short, the product team had a huge backlog of amazing and absolutely necessary features, the development team promised they can do everything in record time, and the CEO only wanted low-hanging fruits in zero time and investment.

But what was absolutely crucial? What was less crucial? What were really the business needs to ship an MVP that could score a funding? What was that MVP really?

That question was unfortunately never fully answered, as we were severely lacking a product-manager and we had to find our own way in that space. This surely made things hard and each team member tried to fill this gap with his/her own understanding. In retrospective, it would have been better to align on business goals from this perspective and many disagreements could have been avoided.


Process

Our process here was a little messy. However, I did start with sketches and low-fidelity mockups, while having conversations with the co-founder and her peers who were tour guides in parallel.




Paper sketches paved the way for low-fidelity mocks


In the meantime I looked online to see which kinds of services around that topic already existed - competitor analysis if you wish.



In the bottom line, none had the combination of live moderation with 3D space panning on a pre-recorded 360 video. That was a good sign.


Anyway, all guides experienced the situation and their input about how they could conduct their tours in an online manner was crucial.

As we progressed, more pieces of the puzzle became apparent, and it was clear we were going to need so many more components just to have an MVP. But what was the MVP? We all had different views but the CEO had a very clear idea that the MVP should be able to generate profit.

That meant that every aspect of the Reachabl suite should be functional de facto.

Anyway, the low-fidelity quickly became the actual designs, as there were no branding rules and UI guidelines.


A large chunk of Reachabl’s modus operandi is very similar to many e-commerce cases. There’s a seller with a shop, he sells his products on our platform, he needs ways to promote those items, checkout, user settings, etc.

This framework made it somehow easier for me as it dictated many of the artifacts I needed to deliver.

I presented those to the dev team, which based on the basic design system and basic guidelines for implementation I gave them, had a significant advantage should they have had to create everything from scratch.


We approached the testing phase after the dev team completed their part - which is just before a proper QA session was needed. But we did manage to run a few test tours with about 8 tour guides who participated in a moderated session. All in all we had terrific feedback, but we learned that there will be some effort that we will need to make in the "how-to" section, to enable the guides to have proper guidelines about how to film their tour "the right way". This was to take place in the upcoming stages. For example, I pointed out that a guide should not pause the recording for the parts of his speech. Viewing a still frame of a fountain in Berlin for more than a couple of seconds was very boring.



Outcome and results

Reachabl is rusting on some server today, waiting to be picked up some day by someone and taken it to it’s next phase.

Maybe the most important thing I learned in that process is how important it is to be open about my plans and decisions. Although this project reached a halt for many different reasons, I’m pretty certain that had I been more open and communicative, things would go better. One example in particular, is to 1. Be more aware of the design process and communicate it better with the team, and 2. To actually know better about each and every stage of it. For example,


To be fair, I was presenting way too many final designs as opposed to spending more time with low-fi mocks. I think that would have showed more openness for discussion and less “facts” in regards to the function and design.

0 views0 comments