“Travel makes one modest. You see what a tiny place you occupy in the world.”
– Gustave Flaubert
Travelling the world has always been a long-held passion of mine, and whenever I get the opportunity, I try and get away to somewhere new, to experience new cultures and see new sights. While I do enjoy being a part of the party nightlife from time to time, I absolutely prefer sightseeing and immersing myself in local history and culture, because I find that a more enriching and rewarding activity overall.
The way I like to do my sightseeing is through travel itineraries, and seeing a target destination to visit each day, while planning to stop by as many sights and sounds along the way to that destination. I normally travel with a guidebook of some description, and Lonely Planet’s guidebooks are generally the ones I prefer, as they’re nice and detailed, and often come with “walking tours”, which provide great examples of routes to take. I often follow these “walking tours” if they lead to interesting places, and more often than not, I’ll look to deviate off the beaten path at points to see if I can find anything interesting.
However, I realised that the biggest frustration with relying on this kind of activity planning routine was actually finding walking routes and tours similar to what Lonely Planet publish in their guidebooks. At the time, there weren’t many websites and apps geared towards travel planning, and it was cumbersome having to carry a 500-page thick guidebook on your holidays, increasing luggage bulk. So I felt that the best idea to run with is an app that does precisely that: allow the user to create a sightseeing route that can be carried around in your pocket, and shared with others.
During the second year of my Foundation Degree in Digital Media in January 2014, one of the main projects we were asked to undertake was to design an app for any kind of subject we were interested in. The project itself was set by a local design studio called Hedgehog Lab, who specialise in mobile design and development, so the project was essentially a live professional brief, therefore we had to give it our all.
Being that I had never designed a mobile app up to that point, I wanted to select a subject for the project that I had a great deal of passion for, as it would hold my interest more than a subject that was essentially throw-away. While I could have gravitated towards something common like videogaming, or food and drink, both of which I feel would have been taking the “easy way out”, I instead opted to look at creating an app for travel.
There were a couple of directions I had considered when I was planning the first version of Wanderlust, initially. The first idea was simply a schedule, similar to a daily planner, that would tell you all the information for a route, such as location, activity name, address, duration, opening times and so on. However, I felt that this wasn’t a particularly fun or interesting, and certainly not visual way to create a sightseeing route.
The second idea, and the idea I settled on, was a mapping application that allowed you to build routes by setting waypoints, and then pinning points of interest along that route. Points of interest could be flagged by the app itself using a general database, or by users in a social network style. Completed routes could then be saved and shared with others for use.
In order to develop our ideas, we were taught to develop our ideas using user-centered methodologies. To that end, we were taught a handful of UX methods, including:
Here I identified a range of possible users and their attributes, including age, gender, technical skill level, occupation and so on. The idea was to create a set of personas that would I could apply to any process that comes after, in order to ensure that decisions on design and functionality are focused on enriching the target user’s experience with the product.
This process attempts to sort out a large list of possible features into four categories that translate into: must have, should have, could have, and wouldn’t have. This is a way to create a definitive feature list and a scale of priority, as well as ensuring that there is no feature-creep by focusing developments on only the most critical of features.
User Stories are small sentences that describe a user, their requirements for a feature and the reason for needing that feature, in the form “I am a user who needs ___ because ___”. What this does is give us a list of possible actions within any given section, and the reasons why those features are needed, as well as providing us with an overview of interactive elements.
As this was my first exposure to User Experience, it was interesting changing my focus from making something attractive to making something user-focused, and I had to learn to design with patterns for improving usability.
Having to force myself to abandon my designer’s instincts of making something attractive first and instead focus on the user changed my mindset considerably, and from that point on I started to look at UX as an essential factor in my project development.
However, when learning something for the first time, the biggest challenge is learning the right way to apply your new-found knowledge, and it certainly felt that I needed to learn more about UX and how to apply it correctly to get the best out of it.
At the time, I was happy with the way the project turned out, but in terms of the design itself, I didn’t think I had created one of my best works. That, and I wasn’t as comfortable with UX methods, and I didn’t feel that I had applied them correctly. Even after achieving one of the highest grades in the class for the project, as well as securing a short-term intern position with Hedgehog Lab themselves as a result of the work created, I look back at the project in my portfolio now and feel that there is something missing from it.
If you're interested in seeing the original Wanderlust, you can find it in my Portfolio.
Fast-forward a few years to April 2016 and the start of my studies in UX with Springboard. I was looking to find a project that I could apply my UX learning to, but while I could have created a project from scratch, I wanted to focus on something I felt passionate about, and just as I did during college, I gravitated towards a travel-related project. However, I also wanted to revisit a project from the past and redo it, as I wanted to improve on them and use them for practice material. So the decision was made to redesign Wanderlust.
I felt that the decision to redesign Wanderlust was easy. It was a project that I felt could have been improved more on the design side with better visuals, the information architecture could be improved with better planning, and I wasn’t entirely happy with the interaction design.
While the original project focused on user-centric design, I felt that I hadn’t applied the methods I was taught correctly, or had taken them as far as I could, and as a result, I believed that the planning and development stages weren’t as detailed or complete. As I’m studying for a UX qualification, why not put what I’m learning into redesigning a project I enjoyed working on into something much better?
The first hurdle to clear would be to actually determine an initial direction for the project. In the original project, I wanted to create a route-planning application that could be used on the go, and I still wanted to create something similar to that as I feel that having a route and a schedule in your pocket can help a traveller stay organised.
However, I am also aware that there could be other unexplored avenues and directions for a project of this nature to take, and they would only reveal themselves with thorough research and development. I decided to take this chance to fully develop Wanderlust using dedicated research from the very beginning of the project, and it would be a good opportunity to apply new methods to the project as well.
The most important challenge to overcome, in my eyes, is to not remain too attached to the original idea or any ideas I want to explore but may not be suitable for this particular project. The biggest problem is lingering attachment to a preferred solution - for this to work, I should focus on being objective and using only ideas and solutions that are borne from research data. That way, I know that the solution that is developed is truly user-cantered.
The very first phase in the project would be to conduct a study of users via interviews and questionnaires. This study would be conducted to look at the habits of people who either travel frequently, or travel with a sightseeing and exploratory purpose, with the ultimate aim being to see if there is an interest in a service that can help simply the process of planning day-by-day itineraries while they’re on their travels, and to see what problems currently exist for travellers in that regard.
Ideally, the study should focus on users that either don’t plan at all for whatever reason, and those that do plan but either plan infrequently, or have problems finding resources that can help them do so. To do this, I identified a group of people in my social circle who would fit both ends of the spectrum - frequent planners, and spontaneous travellers - but share the common factor of travelling regularly for work and leisure. I also created a questionnaire that would be shared publicly to try and get more responses from a wider range of people. This I hoped would give me some insight into how both types of travellers approach planning their trips, their reasons for planning/not planning their trips, and issues they’ve encountered along the way.
While I am used to creating questionnaires as part of my research for work, this was the first time I had to prepare and conduct interviews - both face-to-face and remote - on my own, as in the past, those were handled by more senior members of my design and development team. Having to handle this phase on my own meant I needed to learn very quickly the right kinds of questions to ask, things I needed to observe while conducting the interviews, how to lead an interview, and most importantly, actually developing the confidence to approach people and asking them for their time to participate.
Sifting through the acquired data yielded some surprising facts and interesting suggestions. Most notable of those was the important many of my participants placed on word-of-mouth recommendations - suggestions given by people they trust are far more likely to be followed than suggestions from advertisements etc - along with the importance given to sharing and curation of ideas. I felt that this could be a great primary feature for the app, and one to possibly build a community around. It would at the very least give people a reason to continue using the app outside of the standard trip planning features.
Most of the participants agreed that both aggregation and organisation of the information being offered needed to improve, because it was often time-consuming having to filter through a lot of the available information. That should be an important consideration in developing the features of the product, as providing relevant information quickly and clearly should be paramount. This can also be a direction for content strategy, as user reviews may not be the right direction for the product, but curation of information could be, instead.
As a result of the initial user research, I decided that focusing the app around the features of information aggregation, idea discovery and idea sharing alongside itinerary building was a good direction to take, as this could be the basis of a full trip-planning workflow that starts with discovery and ends with full schedule planning. The next step would be to see if I can mould the user experience in that direction.
The next step is to create user personas that will help focus the rest of the development, as well as empathy maps that describe how these personas think, feel and interact with our product as well as what their goals and desires are. This makes it easier to ensure that the features we are building in will cater to our users’ needs, and solve their problems.
Creating the personas was simple, as I based much of the persona attributes on the participants who took part in the interviews phase, as well as filling in any gaps left with data taken from the questionnaire completed. This ensured that our personas were grounded with real data that could be referenced to at any point if we needed to explain any decisions in the future.
Creating empathy maps was entirely new to me, however, and it was an interesting experience diving deep into my persona’s minds to come up with many of the notes that were used to create the empathy map, such as interesting quotes and observed behaviours from interviews. Learning to study my acquired data and pull out important insights - insights such as “my users prefer to trust suggestions from reputable sources”, and “due to how busy some users are, they want to find the information they’re seeking as quickly and as painlessly as possible” - taught me that this was a critical and essential part of the early process that has a snowball effect throughout the rest of the project, and can lead to much better developed and applied UX as a result.
For the next phase, I looked at my current data and tried to identify a set of key features that, at the very minimum, constitute a usable product that will solve the primary goal of creating ideas for holidays and organising trip activities. This is the methodology for Minimum Viable Product in a nutshell, and like the MoSCoW Process, is essential to ensuring that a product is quick to develop and has only the most important features required.
Referring back to my past research, I identified five key features that would be perfect for the first iteration of the product, and that would solve the problems that my participants identified during the interviews. They are:
A few research participants had revealed that a checklist would be handy to have in order to quickly put together a list of things to bring, in order to make the general preparation for a holiday more streamlined. The participants also noted that being able to customise the list would allow for flexibility based on the trip to be taken.
This feature was suggested by one of the interview participants, who noted that he usually started with an idea for a place to travel to or a landmark to see, and built a holiday around that. This feature would be a good way to discover new places, as it could be further curated by setting preferences and interests, as well as showing only suggestions based on the preferences of people in your friends list.
Many interview and questionnaire participants mentioned that they do have a kind of schedule that would have varying levels of detail depending on how much they wanted to plan. This feature is likely to be the primary function along with the Ideas Browser, to enable users to plan out daily activities to their taste.
Most of the research participants agreed that offline storage of data - especially guide and maps data - is critical, as internet costs are astronomical overseas, and being able to access important information on the go is a big must. Having the information offline allows the traveller to pack less and travel lighter.
A few of the respondents to the initial research noted that they often follow word-of-mouth recommendations from people they trust. Having a feature that would facilitate sharing of recommendations to their social circle, along with some form of curation of recommendations and suggestions, would be a good idea to take advantage of this feeling of trust among friends.
These five features are the absolute minimum features required to solve the primary goal users have when planning a trip, and also conveniently feature app functionality that would be desirable by a large percentage of my participants. The first three features in the list can also be turned into a project workflow that starts with idea curation and leads into planning and pre-holiday preparation, which is perfect for developing a skeleton framework for our information architecture.
For the next phase of the UX development, I looked to create as many User Stories as possible. As noted previously, User Stories are small sentences that describe a user, their requirements for a feature and the reason for needing that feature, in the form “I am a user who needs ___ because ___”, and they are used to identify and validate features based on a user’s particular desire for them to fulfil tasks and goals.
To complete these stories, I referred to the work done for the Minimum Viable Product as my base, as the features described in the MVP will essentially be the primary sections available within the app itself. Most of the user stories are based on the standard actions of View, Create, Edit and Delete, with variations and changes where required. This would ensure that I had all of the bases covered when it comes to interactions users would have at each point, and ensure that I didn’t miss anything key.
At the end of this process, I came out with nearly 70 individual stories that would be used as development tasks during the project, and that was just for the five key features in the MVP. I would expect to see a lot more user stories if there were more features involved, but since we’re working with a Minimum Viable Product, I would be focusing just on these stories to ensure there is no feature-creep at any point in the project.
For this phase of the project, I conducted a card sorting exercise with a number of my interview participants. in order to define the project’s information architecture. In order to do this, I used the User Stories that were created previously to put together a skeleton site structure, along with a stack of 42 task cards based on requirements from the User Stories, and then asked my participants to group them together into categories that made sense to them from a user perspective. During this time, I observed their habits and recorded their comments using voice recording software, and looked to find patterns in how my participants put their groupings together.
One of the most interesting and important observations that resulted from this exercise was that all of my participants grouped the cards together based on a holiday planning workflow that they had in mind. Commonly, the workflow would start with pre-planning - the act of gathering ideas for possible holiday destinations - and would then work through more involved holiday destination research, scheduling activities to do on holiday,
managing pre-holiday activities such as packing checklists, then sharing the generated ideas and information with others in your social circle. This workflow was common enough to appear across all of my participants’ categories in some fashion, even if the wording for the categories differed.
That validated my thinking in that basing the information architecture around a workflow would be the best direction for the app, as a workflow has a logical start- and end-point and is easier to understand than a series of disconnected features. One thing that needs to be considered with this idea is that the user needs to be able to jump in and out of the workflow at any point. Making sure that the user’s work isn’t lost at any point and that it is easy to retrieve their work from anywhere is key.
As I had already developed a skeleton site map based on the work done for the Minimum Viable Product, and expanded to add logical sections such as entry forms, preferences and notifications, the main issue that needed solving was with labelling the sections, and that was what the Card Sorts would hopefully solve.
Interestingly, my participants in the card sort, through their compiled data, shared a view that there were at least three main parts to the workflow, which were ideas generation, local information guides and pre-holiday checklists. Standardising these names to Destinations, City Guides and Checklists, and adding Itineraries to the set, gave me a complete workflow which would serve as my top-level navigation and primary features of the app. Other sections such as Sharing, Notifications and Preferences would be floating sections that could be accessed from anywhere. That, and the work generated from the User Stories would give me enough information to build out the sub-sections based on the View, Create, Edit, Delete set of actions.
The final phase in the UX/IA development is User Flows, where the user’s journey through the app as they look to complete a specific and important task is mapped, so I can see what inputs, outputs and interactions occur at each stage. This takes the form of a flow diagram with any number of branches at each stage.
User Flows is the most straightforward process outside of actual visual and interaction design, as it’s essentially mapping out what goes on at each stage of the interaction. Things I have to pay attention to during this process are ensuring I have identified all of the possible inputs (such as forms and other interactive elements), outputs (such as information pulled from a database and loaded into a view), user decisions (which affect path branching), and any kinds of bottlenecks and dead-ends.
The last part is particularly important, as there should be no dead-ends in the user flow at all - any and all paths should return the user to a suitable start point on completion, or lead to related information or actions.
The main challenge with designing detailed user flows is ensuring that the path through the app is not excessively complicated, and that any decisions that create branching are correctly handled by the system. In order to do that, I put myself in the user’s shoes and mapped out the interactions based on what I would expect to see on each screen through their eyes. Ensuring that the paths through the app aren’t complicated means that forms should only ask for the bare minimum required, and that navigation should be as flat as possible, reducing the amount of tapping through the site map. Thankfully, a lot of the work done in previous processes helped to inform the direction for the User Flows greatly.
The wireframe and prototyping phase was relatively quick to complete in comparison to the research and planning phase, and this is like due in part to the amount of data gathered from research that could be relied on to inform decisions in the design phase. It certainly helped that I could always look back to acquired data to ensure that the structures I was producing adhered to the requirements of the project.
At the start of this phase, I enlisted one of my interview participants to help me with a form of rapid ideas generation and prototyping, using a form of methodology taught by Stanford University. Essentially, ideas are very quickly sketched out on paper, with as little detail as possible and no words, before being presented and iterated on. What this does is force you as a designer to work quickly to throw as many ideas down as possible, without being too caught up in the small details. It is a great way to facilitate discussion, as the lack of details and written notes forces your participants to ask questions about the sketches being produced, and you to articulate your ideas when pressed about them.
Sketching as the first part of the design phase is what I normally do, as well, as I find it far faster to use a pencil and paper to work with, as I am not limited or distracted by technology. I can also be as messy as I want, as the idea is to create ideas with little detail for speed.
Having a participant to ask questions about the ideas I was producing, and giving feedback and ideas of his own, helped to solidify my thinking about information should be laid out in each section, how sections should link together, and how best to incorporate interaction design that helped the user complete their tasks more efficiently. In a way, this type of brainstorming taught me that research never really stops once you get to the design phase, but continues alongside it, and helps to ensure that what you’re producing continues to be user-cantered.
The wireframes were then produced in Balsamiq based on the sketches and notes I had taken during the brainstorming, and then imported into Marvel to create basic interactivity. This is so that I could create a prototype with a native app feel - Marvel is particularly good at this as you can load the prototype onto the accompanying iOS app and run the prototype in context on an actual device, complete with the same gestures as you’d expect. I felt that this is the best way to create a prototype for this project as it is more hands on and more “believable” compared to true lo-fidelity prototyping using paper and post-it notes. It also gave my participants the ability to look at the prototype in their own time, and to leave comments and feedback directly on each screen, which I then incorporated into later iterations.
Once the wireframes and lo-fidelity prototyping phase was complete, and I was satisfied that all possible issues with interactions and information display were covered and fixed, I moved onto the full design phase. I prefer to use Bohemian Software’s Sketch for Mac OS for all of my designs, as it is vector-based, aimed at user interface designers, and features a large number of functional plugins such as Craft and Compo that help augment the UI design workflow greatly. You can even do prototyping directly in Sketch using Invision’s Craft Prototype plugin, however in this case, I opted to stick with exporting completed designs into Marvel as it is part of my usual workflow and more familiar to me than learning a new and upcoming plugin.
The design posed its own set of challenges where usability is concerned. The original design used a very monochromatic colour palette with only one or two blues used as highlight and branding colours - blue in this case is used to convey a sense of trust, safety, peace and loyalty, and is a common colour choice within the travel industry. However, the rest of the palette was meant to be in a range of greys, used for shading and visual depth, but there were some challenges that had to be overcome in terms with legibility and contrast, which were only resolved with the last few iterations of the design.
The navigation was also a problem to implement, at least in the prototype phase. The idea for the navigation was to have a set of breadcrumbs that could be changed to display the top-most navigation layer at any time - this is to reduce the amount of tapping and page refreshes (usually from tapping a “Back” button repeatedly) when a user wants to change to a different section of the workflow from deep within the site map. However, Marvel doesn’t allow for any advanced animation or interactivity, so it was really difficult to convey the intentions for the navigation with Marvel’s limited toolset. In the future, I will look to incorporate an advanced prototyping tool such as Principle to demonstrate elements like this that can’t be done with conventional prototyping tools alone.
I also had to make minor adjustments to the layouts as I went along, to try and improve usability. For example, the button to access Notifications was located in the bottom toolbar in the wireframes, as it is ergonomically closer to the thumb when a phone is held normally. But as the design rolled along, I realised that Notifications, along with the Search and Favourites buttons, would be better housed in the topmost navigation bar as they would be permanently displayed up there, and the bottom bar could be freed up for important section-based contextual actions instead.
I also realised that content also needed to be further fleshed out and organised during this design phase, as I didn’t do nearly enough work during the wireframes phase to fully detail all of the content that needed to be displayed in each section. I’m sure I didn’t do enough work during the site mapping section to detail all of the content required, either, so that’s a lesson learned for next time.
In terms of the design itself, I believe I achieved what I wanted with it: to create a design that took a back seat to the content, but was attractive in its own right. The design itself follows the basic iOS Design Guidelines with custom designs for a lot of elements, such as the cards, mini-calendar, itinerary system and checklists, and was done this way so that the design is grounded within a familiar system so that users would not have to learn too much of the UI to get started with the app. I would need to conduct a Design Evaluation session with my project participants to validate this line of thinking, however.
The final phase of the project was to evaluate everything from the design to the usability with a set of users. In this case, I looked to recruit a couple of the participants that helped with the interview and card sort phases of the project, as I feel that they already had an idea of what the project was looking to achieve, and thus did not require as much explanation about the project as someone new coming into the workflow for the first time. I looked to get users for both ends of the skill spectrum - namely, I wanted one user to have some comfort and skill with technology and software, and one who was less technical and only uses technology when required.
The tasks I asked my participants to complete were relatively simple but required navigating through the many screens to find the solution - this is so that I can ensure that the workflow is correct, and that the information and flow is organised correctly so that it is quick and painless to work with. The tasks were:
As the project was for a mobile app, I looked to see if my participants felt comfortable interacting with the prototype in the same way they would with an actual fully-developed native app, and it appeared neither of my participants had any problems while using it. Even using the Breadcrumbs navigation seemed to be intuitive, even when I had reservations that the navigation would work, at least in the prototype context as Marvel does not allow for advanced interactions.
There were some comments about the bottom bar not having enough visual impact to be noticeable, and as a result, they didn’t realise that there were action buttons available in each section. That can be fixed with a simple colour change, but it is a silly thing to miss, and something I have to remember to pay attention to for next time. There were some comments about increasing the contrast of iconography and text in places where interactivity is denoted, which can be worked into the next iteration.
Overall, I felt that the design evaluations with my two participants were really insightful as they both provided a lot of information from both sides of the user skill spectrum. The fact that they both picked up on different aspects of the design and functionality, while commenting that the design was easy on the eye, had good hierarchy and good usability even at the static prototype stage leads me to feel that the design of the app benefited from all of the past and present research, and the direction it took based on feedback from the interviews and the card sorts helped ensure that the workflow and interaction design was designed properly and with absolute usability in mind.
The process itself was enjoyable to do, as it was similar to the interviews phase where I as looking to not only note what was said but observe reactions as well. I can see this part of the process being rewarding in a variety of ways, both in seeing ideas validated, as well as getting valuable feedback to improve things in later iterations.
Looking back at all of the work done from the beginning of the project to the end, I feel that I’ve learned a lot about User Experience just from this project, a lot more than I would have learned just muddling through on my own.
When I was teaching myself UX originally through tutorials and books, I always had the feeling that maybe I was only learning one piece of the puzzle, and that I was missing the bigger picture. Actually having a proper curriculum to work from for this project, which detailed a correct order of execution for every UX process, taught me that there is an underlying process for UX that can be applied to every project. Knowing that UX starts at the very beginning with user research, and carries that throughout the project, also taught me that getting it right that first time helps the project greatly overall.
Actually knowing what to do and how to apply this knowledge will help greatly in future projects, but I also learned that you can be flexible with this process based on the type of project in question. the key is to know how much work is required, and how to understand the data, and I feel more confident about how to gather data and interpret it now.
I also gained a lot of confidence conducting research processes that involved interaction with users, such as interviews and the Design Evaluation. In the past, I never conducted interviews on my own for my research, and it forced me to step out of my comfort zone and learn to interact with my users. I started to really enjoy these phases of user interaction, as they gave me a chance to practice my public speaking and people observation, which are skills that help greatly in gathering usable research data.
As for the design itself, I’m a lot more confident that I’ve hit all of my personal targets with this project: designing the correct user experience, developing the right information architecture, and designing an interface that is usable and attractive at the same time. I don’t consider the project to be finished in the slightest, and will continue to iterate on it as time goes on, but compared to when Version 1 was completed and handed in, I feel a lot happier that Version 2 meets my own expectations, and that’s because I know it meets my user’s expectations at the same time. That gives me great satisfaction, and the feeling that the time invested in my studies with Springboard and the work put into developing Wanderlust 2.0 was worth it.
If you're interested in playing with an interactive prototype of Wanderlust 2.0, you can find it on Marvel.