Published on | Prototyping: From UX to Front End — Medium Jonathan Lutz

My clients came to our initial meeting with an idea to create an iOS app to connect potential customers with adventure guides. The app would would have everything from creating, booking and paying for trips, to leaving reviews.

This case study will touch on some of the parts of the process I found to be interesting.

Clear Need

Before I get into the research let me dive a bit more into what this app is all about. Guides in this case are the men or women you pay to take you on a fishing or hunting trip. This could be anything from a morning fly fishing trip to a six day open ocean fishing trip, or dove hunting all the way to a bear hunting expedition.

Currently there is not a unified marketplace to search through adventure guides. A user must either find personal websites created by the guides themselves or search through guide outfitters that typically host a handful of guides in a specific location. This can be very time consuming.

We knew it could be better.

Must haves before we even start the research

Search by location and date
Book and pay for trips
Create trips
Share trips via fb, email, text
Review trips/guides

Research & Empathize

Because our users are pretty niche interviewing tons of people was going to be a must. Not everyone has used a guide before and, most certainly, not everyone is a guide themselves. I would need to find both groups of users if I wanted solid feedback. This proved somewhat more difficult then imagined. I spent a fair amount of time on the phone with guides. Most guides are busy people and a 20minute phone interview was not something they were willing to do for zero income. I received approval to offer six months of free usage on the app as an incentive to the guides I interviewed.

30 survey responses were collected between clients and guides. With those responses these two personas were created.

Persona for Clients and Guides

After creating the personas it was clear what features would be required to satisfy our users needs.

Analysis

70% of the clients interviewed complained about response time from guides. Messages were almost always by email with the typical subject matter being about availability. By the end of the interview process it was clear an in app messaging system and availability calendar would be necessary.

Another feature that was prominent in discovery was a way for guides to upload tips, links, or even videos so a client could come prepared. Some of the clients said the first hour or so of a one day trip would be consumed with instructions and practicing the sport, whether casting a fly-rod or sighting through a rifle on a range. If a guide uploaded tips prior it could leave more of the day for the actual trip, which will result in better success in the field.

Discovery revealed many complaints from guides about unruly clients. This spawned the idea of a guide-to-guide rating system of clients. Uber does this with passengers. But, when I asked an Uber driver about this feature she said she always left 5 stars, regardless. So, I decided to make the feature a rating and comment system. This would be inside knowledge for guides. Does the client tip well? Do they drink way too much on the boat? Were they rude or unsafe? All extremely valuable information for a guide. Remember most trips involve some type of risk. Wether it be using firearms, on a boat in the open ocean, or wading through a river. The more knowledge you have on the company you keep in these situations the safer it will be.

SWOT Analysis

Brainstorming Time

I was starting to get a good idea of what features would be needed. But, I always do a group brain storming session with a few colleagues. I typically bring in the clients and development team and give a quick presentation that outlines the creative brief, personas and the main goal for the app. I then hand everyone a stack of post-its and a pen. I tell everyone to think of any idea or feature that the app could use. I make sure everyone knows that there are “zero bad ideas, and every idea is a good idea.” I honestly believe this. Every idea generates iterations that can evolve into great features.

Back to the post-its. This portion of the session is 10 minutes and everyone is expected to keep silent and write down as many ideas as they can on post-it notes. One idea per note. Most people write down about 15–20. The next step is presenting and discussing each idea. To demonstrate the process I go first, placing one of my post-its on the wall and explain that idea in detail. Everyone is instructed to be silent during presentations and to absorb what is being said. The time for discussing ideas is after everyone has presented. Then we go through the notes and get rid of redundancies and create one master row. From the mater multiple iterations of every idea are made.

An evolution of ideas hatched from this session include:

Let Guides create packages or discount prices for multiple days

Prompt guides to discount approaching open days

Create a “FMG” search option using an algorithm that parses price, reviews, and location

Let guides offer add-ons to purchase with trips, which might range from gear rentals to additional supplies, or even transportation

Let clients leave video and picture reviews that can be hosted on the guide’s profile page

The Flow

Flow for a client booking a trip is fairly easy.

Launch app -> Create account -> Search trips by location, date, or category (or any combination) -> View results -> Select trip -> Check availability -> Select date -> Checkout -> Go on trip!

Client Side

It was now that I had to deal with a way to manage the two distinct users (guides and clients). I came up with three ways to handle them. Each with their own pros and cons.

Option 1

Create 2 apps. One for clients searching and booking trips. The other for guides to create and manage their listings.

Pros. Less confusion on what you can and cannot do in the app as there will be less options with each app serving a specific purpose.

Cons. 2 APPS!! Double the dev cost and upkeep. Making sure users download the correct app.

Option 2

Make users decide when signing up if they were going to be guides or clients. This will limit the functionality of the app based on the type of user.

Pros. One app….Sorta… Easy and upfront flow to users. Do you want to be a client or guide?

Cons. What if a user wants to do both? They will then have to create two accounts and login and out to use both features? How will guides look at their competitors to price their trip accordingly?

Option 3

Start everyone out as a client but have an option in their account were they can apply to become a guide. After they are approved they go to their account page and can switch between user types.

Pros. Truly one app. Switch user types easily and quickly. No need for two accounts.

Cons. Users might get confused as to what their user setting is. More on-boarding(coaching marks) needed to explain how to become a guide.

For this decision I scheduled a meeting with my clients and development team to discuss our options. Option one was scrapped almost immediately leaving us with option two and three. I was pushing for option three and the development team was slightly leaning towards option two as it sounded easier to code then option three. I explained the trouble with option two and how making users physical log in and out to switch user types is almost the same as the in app user switch. I drew some quick mockups on the white board and we settled on option three.

Design

There were 100’s of whiteboard iterations and sketches. Most were erased and never contemplated again. Knowing 80% or more of the clients time would be spent looking at the search/results view and the single item view. I sat down and came up with the sketches below.

The first hurdle was figuring out the best way to display search results. I came up with three different cards to display the trip results. Number one looked outdated and stale. Number two was mostly an image with title and reviews floating underneath. Number three was condensed version of two. I asked four people and the votes came back three votes for number two and one vote for number three. If I knew the app would be populated with 100’s of trips from the start I would of liked to have gone with number three. Seeing the app would be a fresh start, number two made sense for multiple reasons beyond just a quick survey. It gave more real-estate to the picture and took up double the space then number three which should correlate to a more populated looking app when we might not have many trips to start out with in the first few months, number two it was!

Search Fields

This might of had the most iterations out of everything. We had Location, Date, Guest numbers, Price, and Categories (at this time my clients were still not sure if we were going to limit the categories to fishing and hunting or if we include rafting, hiking, sailing, or any type of adventure that requires a guide. Initially I decide to go with location, date and category. With categories being a drop down selection. This later changed to Location, Date, Guests, and Categories. With categories becoming buttons. The idea of hiding information as important as the categories being offered made absolutely zero sense. They were now four large buttons with the option to select multiple categories in your search.

Single Item View

Please forgive my handwriting 😉

I had a good idea on the information needed to be displayed at this point. It came down to categorizing it correctly. I found a few volunteers and did a card sort with them. Each card had a piece of information on it. Title, guide info, price, and so on . Now, this is a mild spin off of a normal card sort where we would categorize information based off topics. Seeing my volunteers had never even heard of a card sort before it didn’t much matter. I explained a bit about the app and the view we were working on and that I wanted them to put what they thought the most important information to be at the top and less relevant information towards the bottom. I also said they could put information side by side if they felt it was of equal value. Here is one of the card sorts. This one was the closest to being the final display results.

First iteration of the single item view

Title
Sub-title, short description
Price/reviews
Guide picture with link to personal page
Trip details
Amenties
Location
Guide info that can be read on same view
Full reviews
Informational links
Related trips

Create a trip.

After having a rough idea for the search view and single item view it was time to tackle how a guide creates a trip and how a client can book a trip. During the sketching for the single item view I took notes on what would be uploaded by the guide vs what is stock information provided for them. I actually love doing complicated admin flows. You can iterate quickly in the begining as you are just trying to get the flow to lets say “flow correctly.” In my opinion the need for fancy animations or amazing shapes in a admin setting/flow is not needed. I always try to focus on getting the input fields in a consistent and smooth layout. If in doubt I refer to material design.

During the creating a trip design process I came up with some really awesome ideas on how a guide can customize a trip. But the main focus was to make creating a trip simple, effective, and quick.

Quick(very) Hand Sketch, Lo-Fi Wireframe, Hi-Fi prototype

Creating trips

Create a listing from scratch or use a existing listing as a template?

Being able to create a listing from a template will save guides a huge amount of time. Most guides offer 5–6 trips at any given time. The changes are typically time of day/length and location. With most the other information staying the same.

What type of trip are you offering?

This will a be a selection from the four categories FMG will offer in the initial release. Freshwater fishing, Saltwater fishing, Small game hunting, and Large game hunting.

Trip title

Pretty self explanatory

Trip short description

A bit of coaching was needed on this as some guides began to put unnecessary information in this text field. I am thinking about making it the first few words of the trip description to speed up the process.

What species are you targeting?

This idea showed up pretty late in development. It was actually the result of design review with my clients. Instead of hoping the guide puts species information in the title or in the trip description we are now forcing the input early. We want to be sure clients get all the information they want without having to dig through a long descriptions. It will also be filter option in a later release.

What days are you offering?

I knew this would be a tough feature to do correctly. Almost all guides run on seasons and offer multiple trips. Some of the requirements needed to be addressed based off my research are start and end date for the trip, blackout days and option to connect all their calendars so they never have double bookings.

What time of day is the trip?

A simple time of day picker.

What are the details for the trip?

All that was needed for this was a little bit of coaching to make sure the guide gives a detailed description of the trip and what is included.

Add Photos

We are requiring a minimum of 6–12 pictures, with a maximum of 24. Coaching for this is “They say a picture speaks a thousand words. We find that 12–20 thousand words is optimum.”

How many guests and required age ?

There were more options here then one would think. Are all the guests included in the price of the trip? Is there a charge for extra guests after the first X number of guests? Is the trip price per guest? What is the age requirement for guests? Are children allowed with adult supervision? It would be very easy to make this extremely confusing for guides to create and clients to understand when booking. At this point I felt we had to leave the options wide open as anything I did at this point would be a complete assumption on my part. Heavy user testing would need to occur before a development handoff.

Cost for extra guests

This idea was up in the air as was the entire idea of extra guests. For now it was a simple data picker.

What amenities do you offer?

Most this information will most likely get covered in the trip details. I wanted to make sure I had another area in the listing that would clearly list all the amenities offered in the trip. This again empathizes with our client and their goals when choosing a trip.

Add ons that cost the client money.

This was another idea that came late to the game during a design review. The idea is to have equipment or upgrades a client can purchase for their trip. This could be anything from a packed lunch to $300 fly fishing rod. This idea was a bit ambitious for a first release and was pushed back to a later release. The reasons were how to regulate what can be added and what cannot. Seeing the input method would be open text input fields it just leaves to much room for human error.

Required tags and or licenses

Another idea that was late and not in the card sort. Most sporting requires some sort of license or animal tag to legally participate. The worst thing that could happen to a client would be paying, and getting to the location for the trip to be turned away because they didn’t have the correct license or tags. It will also display in the confirm trip for clients when booking. We want to make sure they have what they need.

Trip rules

This will a be text input field were the guide can layout the trips rules. Examples are, no drinking on the boat, or maybe they say bring extra beer for me. You never know. We just want the clients to be on the same page as the guide before embarking on a trip together.

Location.

People need to know were to go. We will let the guide either use a exact location or a drop a pin on a map. We will hide the exact location from the client until the trips is booked and paid for.

What do you want to charge?

At first we had this as step 2–4 in the flow. After some testing, there were some problems with add ons, extras, and extra guest costs that made guides go back and change the price on multiple occasions. By first making the guide describe the trip, the extra costs associated with the trip or customer add-ons, they were able to more accurately price the trip at the end versus earlier on in the flow.

With paper sketches done it was time to put some wire frame flows together and iterate. The main focus is to find a smooth flow during this stage. Design elements will come later on. While I do spend some time thinking about what to implement on design, I am much more concerned about copywriting, usability, understanding, and flow during the initial wire-framing process.

WIRE-FRAMES

Lo-Fi Wireframes for checking out and creating a trip.

First Prototype

After putting together a lo-fi prototype it become very clear what screens I missed or needed to add. Going over them before a design review is very important. Otherwise I find it somewhat hard to test wireframes on non developers and designers. Most people not associated with software development instantly say “I think you should ad some color” and thats after I explain what a wire-frame prototype is. With a ton of coaching you can get good feedback on a Lo-Fi prototype. At this point I was a bit behind and I knew I had to be quick. I tested it on 3 people. 1 Designer and 2 Developers. The advice was minimal but still appreciated. I obtained much more insight from the design review with fellow UX Designers.

Lets talk color for a bit

Actually lets look at colors first.

I played around with a fair amount of colors, too many if I am being honest. I tried the new trendy super brights with gradients, pastels, blacks, odd combinations and the tried and true combinations. I ended up going with the color scheme based off a typical map. The green is that of the forest areas with the call to action the orange typically used for roads. It was simple to view and really captured the attitude of the app. The call to action was always clear and easy to identify as well.

High Fidelity Screens

The Big 3A few screens for booking a tripA few screens for creating a listingMessaging systemWithdraw stepsCalendar management for guides

Testing Guides and Clients

Guides

For guides, I focused on a few tests; creating a listing, managing multiple listings, and withdrawing funds.

The guide would receive an InVision prototype and we would perform a screen share, recording the session for later analysis. I would ask the guide to complete a series of tasks making sure they verbalize what they are doing, why they are doing it and what they are thinking, while using the app.

Clients

For clients I was able to do this locally on my own device. The same approach was taken with the focus being on signing up, searching for a trip, and booking a trip.

Feedback & Fixes

Most guides thought the add ons was a bit of overkill, but all thought it wasn’t a problem as you could just skip that step when creating a listing. It also confused clients checking out. As it turned out it was the example that was the problem. I used the example hot lunch and cold lunch. That was a bad choice on my part. I am sure if I had a bit more of an explanation on what “add ons” are and more options for add ons such as extra lures, ammo, sleeping equipment it would of tested better.

The user feedback on copywriting was of the most value. By the 3rd round of user testing everyone was picking up on the flow immediately. So much so we decided to skip the in-depth on-boarding videos. This really won some praises from the development team and my clients after the realized cutting the on-boarding would save them a fair amount of time and money.

Other quicks changes included replacing the word Calendar with Availability on the single item view toaster. I also moved the share and favorite icons on the single item view from the top right of the main picture to right below the main picture on the right side. This cleared up the image and gave more emphasis to those buttons.

Another change was adding a subtitle in the single item view that clearly identifies the species targeted. In the testing phase the only place you could find that information was in trip details. This then brought up the question of listing the targeted species in the search results. We had talked about filtering trips by species, but this would be very problematic as there are literally 100’s of species. I had to dig deeper to see if it was a viable option. Upon further research the location almost always correlates with the target species. Now, there are a few areas that hold multiple species, tho this is rare. A species filter option will most likely be added in a later release. For now we agreed filtering by species was not prudent to the MVP. It was put on the backlog. However the title listing the targeted species will be making the MVP cut.

Guides noticed at the bottom of a listing there were related trips by other guides. They were not exceptionally excited about the idea of listing competitors trips on their own trip listings. I understand their frustration with that and I decided to adjust that and will now list more trips by that guide and only list trips by other guides if the guide does not currently have any more listing.

I also tested a few different data pickers. The least liked were the stock iOS scroll pickers. All but one user preferred the material design data pickers. I explained to my client that iOS data pickers are cheaper to implement in the development phase but that the material pickers tested much better. I left this decision up to him as I know he has a budget.

I was pleasantly surprised at how well the app tested overall. The lack of raised eyebrows, miss taps, deep sighs, and puffs is what every designer hopes for during a test when you are this far along. I obtained most my knowledge in the debriefing, I really enjoy asking what could make the app better or what would you do differently if you had the power to change something within the app. I believe we all have some sort of creativeness within us, it just comes down to communicating it to others.

Dev Handoff

This was done remotely. Seeing I kept the developer in the loop during the design phase it went quickly and smoothly . The meeting was more for the client and educating him on the development process. We went over some basics on scrum meetings and sprints. I did a complete rundown of the app, answered a few questions and it was over.

Conclusion

Signing over the design to a client is extremely rewarding but also slightly depressing. You put so much time and effort into a project and in the end you send it on its way. I also believe we all know just because a project was signed off on doesn’t necessarily mean its over. Being completely honest I actually made a few changes during the write up of this case study. During this writing the project is in its second month of development.

All in all I am extremely happy with outcome of Find My Guide. There were some moments of complete frustration and moments of amazing satisfaction. The clients were more then happy to sign off on the design and take delivery.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Find My Guide was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Find My Guide

Cool stuff, every week

More Articles