Jetsam | UX Project Plan commentary
From the outset, our team recognised it should seek validation from prospective users regarding its business value. Therefore our Project Plan emphasises research activities to ensure our app could monetise realistically. So what have we put in place to drive our success?
In summary, the project team is creating the specification for a mobile app which connects travellers so they can hang out with other travellers in a foreign country.
Given that it’s a self-initiated project with no established user base, our team recognised it should seek validation from prospective users regarding the project’s desirability, and therefore its business value. Our Project Plan emphasises research activities because we want to be sure this app could realistically make money.
What follows is a commentary on the proposed timeline for our project.
Identify the opportunities
Before the project officially began, we conducted an activity to open up our team’s understanding of the problem space. We asked people who have travelled as backpackers about their experiences - the disasters they’ve encountered and the happy accidents that have made travel a life-changing experience.
This activity gave us reassurance that other travellers have recognised the desire for companionship when abroad.
Initial assumption: confirmed.
Planning this project has meant designing a sequence of UX activities which will always anchor our design decisions in empathy - listening to the desires and frustrations of travellers who are driven to create amazing, positive memories in foreign countries.
The framework of our Project Plan is rooted in Sara’s Design Thinking Toolkit, which she has used previously to educate business unit leaders within a major Australian corporation in design thinking techniques. She’s asked that the details of her framework be regarded as Commercial-in-confidence, so we won’t be publishing it here.
Without an existing user base, we are reliant on using an open survey to build a dataset to justify all subsequent design decisions. As a starting point, participants will be sought from our respective social networks, and encourage them to share the survey.
The survey’s data will give us an insight into travellers’ behaviour, expectations, and their conditions for hanging out with people they meet in foreign countries.
In parallel to the user research, we will conduct desk research into competitor products. At the start of the project, we identified 20 apps within Apple’s App Store which may answer the problem we seek to solve. We’ll be seeking insights into common features which seem to resonate with travellers and support our Primary and Secondary Goals.
It could be tempting to replicate the most common or (in our opinions) the most useful features found in competitor apps. Without an existing user base or workplace processes to define our app’s requirements, we must listen to prospective users.
We plan to interview four (plus one dry run) participants who are currently backpacking in Brisbane. They will complete the same survey as the online participants.
The first activity will be a workshop session where the participants propose features they would find useful for solving our project’s Primary Goal.
The second activity will be a group review of the three most relevant competitors to our project. We seek to empathise with travellers’ needs by listening to what they want and the features they value in a travel app.
Other research activities will focus on the needs of our users. We also need to examine the needs of our customers - tourist-friendly businesses and events in foreign countries, to ensure the user-focused app collects the ingredients necessary to deliver customer-focused knowledge.
Due to the project’s constraints, we will seek expert opinions from a limited number of English-speaking tourist-friendly business operators. We are aware this will not provide insight into implementing multi-language support.
At the start of the project, we have an intentionally vague definition of our target audience - travellers who typically travel alone or in very small groups for leisure. With our research data, we will refine our target audience based on the intersection of behaviours, desires, habits, and cohort size.
Our research data will be distilled into six provisional personas. (Despite being distilled from data, these remain provisional personas as they are derived from an open survey’s respondents, not live users.)
In situations where data on real users is unavailable, Dan likes to use an activity using six pie charts to distribute quantitative data’s attributes proportionately. For example, if the data presents 56 per cent female, then three of the six pie charts get labelled as female. If 82.9 per cent of the data presents as university educated, then five of the pie charts get labelled as such.
Once all data-based attributes have been distributed, we can then create more nuanced personas. We tend to match the attributes to our friends so we describe authentic and empathic personality traits.
At this point, we will also address the project’s Business Analyst objective. Ie, use the collected data to hypothesise the success scenarios for a fully-built version of the app, based on modelling of user and customer uptake.
Stakeholder accountability would be valuable here.
At the start of the project, we identified four Primary or Secondary Goals, with about a dozen features to support them. These are just the tasks we know about at the start. Research will undoubtedly highlight additional features to support our Goals.
Each feature will be implemented as clusters of tasks. Getting the tasks clustered in alignment with empathy for the users’ needs goes a long way toward delivering thoughtful Journey Maps.
Prospective users will again be involved at this stage. We want to confirm that our planning and connection tools match the needs of travellers.
The process for creating wireframes involves high-level to low-level recursions through the app’s key interactions. After each recursion, the key interactions bgin to operate as miniature prototypes and provide context for studying the level of satisfaction in completing a given task.
The completed set of wireframes will be presented to prospective users to again validate the app’s information architecture.
Finally, we will again present the app specification to an appropriate UX thought leader.
And that’s as far as we expect to take this particular project. The project team is passionate about UX. We love documenting our assumptions so we can either confirm or crush them with real data.
It’s always fun to provide a rationale for a Project Plan timeline at the outset. We don’t want to prove that we’re prescient (although that’s always cool) - we want to prove that we adapt when our assumptions are crushed.
Okay then - let’s crush some assumptions!