Hostelly

BACKGROUND

Hostel owners (and those that run them) have many tasks that they need
to accomplish each day and never enough time to do it. They would love something that helped them organise their day-to-day, leaving them with
more time to efficiently run their business, utilising less staff and effectively saving money.

Running a hostel is a full-time job and you need the right tools. It seems that these Hostel owners/managers would like a much more simplified way of inputting data and the language to be consistent and simple, with an on boarding experience to cut down on training time.

deliverables

Project Plan
Competitor Flows & Heuristic Analysis
User Survery & Interview Questions
User Scenarios and Personas
Competitor Userflows
Revised Site-map
Wireframes
Clickable Prototype
Usability Test Insights
Research Report
Presentation

MY ROLE

I served as the project manager, led the feature ideation and conceptualisation stages, wireframes and synthesised all of the research into a cohesive report. The competitive research, user interviews, usability tests, protyping and deliverables were a collaborative effort.

COMPETITOR research

We compared property management systems that compete with Hostelly, with typical user flows from Homescreen to Check-in of a guest. The main issue didn’t seem to be the amount of clicks it took to get to check-in, instead the issue seemed to be that users were abandoning the software, failing to input data, or struggling to find highlighted information. We needed to determine what was causing the problem and how to fix it.

RESEARCH

Unless it’s making my life easier, why bother?

Major take-aways from Interviews:

We began by approaching Hostel owners/receptionists in the NYC area, only to find most were reluctant to speak with us. After further investigation we discovered there’s an occupancy law that forbids hostels to have more than 3 unrelated people share a room for less than 30 days period.
This is probably why we received so much resistance when trying to speak to Hostels that were operating within the New York area (they were probably breaking the law) so we decided to take a different direction in order to get credible and viable research data, talking with Hostels in NYC, Bali and Australia.
When we did finally speak to the right people we talked to them about the day-to-day running of their respective Hostels and what kind of help they would need in order to make it run more efficiently.

Contextual Enquiry

We asked questions like:
Who is the intended user and what is their task?
Why will they use the system?
What is their experience and expertise?
What are the technical and environmental constraints? (What types of hardware will be used in what organisational, technical and physical environments?)
What do they need in order to do their job more efficiently?

AFFINITY MAPPING, FEATURE PRIORITISATION & THE MOSCOW METHOD

We wanted to develop a clear understanding of the HOSTELLY’S requirements and their priorities. From our interviews we distilled the data we received in the following ways:

Topic mapping - We placed the topic motivation in the center of the map and then connected related ideas using lines to help us visualise related themes or elements that have a cause-and-effect relationship. What was their motivation for wanting their business to run more efficiently?

Affinity mapping - We used this technique at the end of the contextual enquiry, because we had a large amount of information that we needed to synthesise.

Feature Prioritisation - was used to distill this information even further. Priorities were defined based on the needs of users and were determined based on factors like Easy - Hard to implement and nice to have - essential.

MOSCOW - Once there was a clear set of requirements, it was important to ensure they were ranked. This helped everyone understand the most important and in what order to develop them and those that won’t be delivered if there is pressure on resources.
• Calendar - Occupancy at a glance
• Always be one click away from any other page
• Prominent Check-In/Check Out
• Plain English on boarding
• Auto emails (not hidden)
• Easy add new reservation
• List of people who checked in
• 3rd Party Sync seamlessly
• Activity Log (History)
• Get out of window easily
• Saving confirmation

DEVELOPING PERSONAS

We found that users fell into three categories that became our Hostelly personas.
• The Hostel owner/receptionist who ran the Hostel manually.
• The airbnb host that ran more than one property looking for more efficient ways of doing the daily tasks.
• The small hotel receptionist.

DESIGN STUDIO & SKETCHING

Although starting a prototype on a computer is sometimes easier, it’s not the best way to visually problem-solve. Sketching was a much more efficient use of time. It kept you from getting caught up in the technology, and instead focused on the best possible solution. We were free to take risks that we might not otherwise take.

These are just a few of the sketches that were integral in working out the flow for our digital prototype.
Once we had worked out what needed to be on the Calendar page (which was basically the entire app with tabbed pop-ups), working on the check-in/out pop-ups became clearer.

PROTOTYPE ITERATIONS - CALENDAR PAGE

A. Users wanted to know why only Check-in and Check-out had icons, what about the rest of the tabs?
B. Users were confused by the order of the tabs.
C. A Calendar tab was added so each week’s reservations are able to be viewed at a glance.
D. Room names and number headings were added as users had no idea what the Greek names and numbers were.
F. Today was added in front of the date so users knew they weren’t looking at an arbitrary date.  
G. Icons were considered and designed for each tab for consistency purposes.
H. A profile name and small avatar was added so that the user would know who was logged in at any given time.

PROTOTYPE ITERATIONS - RESERVATIONS PAGE

WHAT I LEARNT

There was a lot to consider when undertaking this project. It’s interesting because the brief spoke about having an onboarding experience so that there was less training of Hostel staff. As we delved deeper we realised that beta testers had actually given up using the software because it hadn’t been well thought through, planned or considered. By taking a step back and listening to the user we were able to come up with a very effective single page application that would be a one-stop-shop for all of their needs.

NEXT STEPS

• Engage a content copywriter to write Onboarding content and build it out.
• Consider the flow for the 3rd party bookings that appear in the calendar automatically.
• Build out flow from Check-in to Check-out.
• What is the most important information useful to the Hostel that they could view at a glance in Reports?
• Include a way to integrate internal messages as well as external emails in Notifications.
• Create small 2 minute training videos for main tasks.
• Add content for Help topics, What’s new and Technical Support.
• Redesign Profile Page.   
• How would users Add a Room or Add a bed?
• How will Keycafe integrate with the software?
• What information will appear in user History?
• Consider a Tool Tip approach for the labelling of in-put fields.
• Reconsider the placement and design of the Settings and Notifications tabs so that they sit next to the profile pic. Consider how the page is laid out when these are active.         
• More testing, more iteration… repeat.