izi.TRAVEL Onboarding Process
UX Design Web media Unit
In the UX Design unit for Web Media BA, we were playing around with an web application called .izi.TRAVEL. The purpose is to create audio walking tours for an attraction, museum or city.
Below is a video explaining an overview of the platform:
Front-End Evaluation
On-boarding Process
The video above, also acts as an on-boarding strategy for attaining new users. When on their website, users are welcomed with this animated video explaining the overview summary of their platform, it’s ideas as to why it exists and what it can do for organisations and end users (the public).
I feel that this on-boarding strategy is much more focused on obtaining customers to create their own guides, rather than the general public who will be following their guide.
The on-boarding strategy for obtaining customers to use the guides is very simple on their app. It’s a simple sign up process to download content, with the ability to browse without a login. Users are prompted by a museum for example through advertising banners at the entrance (supplied for free by izi.Travel) to attract customers.
Evaluating the language
Looking at the language used, I feel that it isn’t always very clear as to what is what. An example of this is in the CMS backend of the site. The type of touts titled, “Museums” and “Tours” isn’t very obvious. When playing around with the application before the lecture, I was under the impression you first needed to create a Museum, then create a tour to assign it to that museum. I once found out this wasn’t the case.
Having this unclear UX can often lead to people giving up using the software and if I wasn’t needing to use this, I would have probably tried to find an alternative competitors product to use.
Content Presentation
The content is managed and presented to the users via the mobile app in a very sleek and clean way. For the outside tours, it uses GPRS to track the users location and starts the tour. When inside, users can select their starting point and work from there. This strategy to meet any constraints works well and doesn’t feel like hassle for the end user which is important and a good use of UX design.
Tours are also based on your location so relevant tours are suggested. There is also a search function to find specific tours if you are in an area you haven’t visited or planning a visit and want to see tours available before you go. The team have also curated an editors choice list of their favourite tours around the world. This also acts an an on-boarding process as it shows the higher quality content to convince the users to sign up.
Improvements
I feel one improvement that could be done would be to make the on-boarding process of users visiting their website to view tours a lot more simple. I feel that the current site is far too focused on curators rather than viewers.
Another improvement would be the create a more cohesive design throughout both the iOS app and the Android app. Having downloaded on both platforms, features change and the apps feel very separated. An example of this in terms of UX is the passcode feature, allowing users to view locked tours using a passcode. This process has different steps for both iOS and Android making the process very complicated for curators to instruct people on how to find their tour.
Implementations
One implementation to the front-end for izi.Travel would be the option to have a questionnaire for users to fill out after their tour. This would be a great addition for a museum or attraction to gain user-feedback on their experiences to better the tour.
I feel that users are used to attractions asking for a few minutes of their time to answer some questions and it should be no exception. It could prove very beneficial to curators on the platform.
Back-End Evaluation
We had the opportunity to make our own tour based around our project. My group MyMaritime decided to ‘test the waters’ a little and build a tour based on going to the toilet at the museum. From this, we wanted to gain a basic understanding of using the audio features, adding images and directions and publishing our own guide.
Their academy feature on the site is a great way of learning how to use the platform and has lots of in-depth instructions and tutorials telling you exactly how to create the perfect guide for izi.Travel.
One thing that I felt that their back-end lacked was an intuitive design for their buttons. An example of this is that the cog icon, used conventionally as settings, was used as a way to get back to the dashboard in the back-end. This felt very un-natural and didn’t work very well for a user in my opinion.
One very obvious problem is that to delete a tour, it takes a click of one button of a trashcan and it is deleted forever. There is no way of recovery from both a user or admin point-of-view which seems very strange.
A feature that I feel would benefit the back-end of izi.Travel would be a more intuitive way of distinguishing between what a Museum tour and Tour is. The difference isn’t clear and is a real UX problem for the user, including myself from personal experience.
