top of page

SURF HUNTER

ALWAYS KNOW THE SURF CONDITIONS

OVERVIEW

PROBLEM

​

Surfers don't know what the weather conditions are for surfing, and need real time surfing data to decide whether to go surfing or not

HYPOTHESIS
 

Develop an app that provides real-time weather and surf data for various locations based on personal preferences.

THE PLAN

1
8
7
6
5
4
3
2
1

Competitor

Analysis

User

Research

User

Personas

User Journeys & Flows

Information Architecture

Wireframing & Prototyping

Usability Testing

Refining the Design

TAKEAWAYS: During this process I discovered I could differentiate myself from competitors by offering users:
 

  • A customizable home screen - so users could find exactly what they're looking for more quickly

  • A cleaner user interface - so users could see conditions at a glance or drill down to get more detailed forecast info

  • Multiple ways to view data - because different users read and understand data differently

  • Personalized alerts - so users could find the ideal conditions for their personal activities

  • The biggest threat was apps that offered users more opportunities for engagement and entertainment, like a blog and news feed.

1
COMPETITOR ANALYSIS
​
​GOAL: Determine if there is a market for a hybrid weather and surf app, and to identify the issues and opportunities that exist in the weather and surf app space.
​
COMPETITOR PROFILES
Researching competitors with apps similar to the one I was looking to design, helped me identify both the issues and solutions that existed in the surfing/weather app space. I first created a profile for each to compare their core messages, overall business strategies, and market advantages.
 
MARKETING PROFILE
To gather more information about my competitor’s users, I researched their existing clients and looked at the current marketing strategies each competitor employed to make itself known to its users (social media, blogs, ads etc).

 

SWOT PROFILE
I created a SWOT profile to outline the biggest strengths, weaknesses, opportunities, and threats of each competitor. By assessing these elements, I could see what features worked well, what features could be improved, and where there were opportunities for innovation.

​

UX ANALYSIS & HEURISTIC EVALUATION
I downloaded each competitor app and took notes on its usability, layout, navigation structure, compatibility, and calls to action. From this, I could create actionable points on how to position my app in the market and how to outperform competitors. 

1

TAKEAWAYS: After conducting user research I found the three major requirements I needed for my MVP were:

​

  • Real-time, localized reports with data about wind direction and speed, swell height and frequency, and tides - which is the most important info surfers need when deciding whether to go or not

  • Webcams that allow users to visually see wave conditions since surf reports are often incorrect

  • Automatic alerts that pop up when a user’s criteria is met - since surfers don't always remember to check surf conditions

2
USER RESEARCH


GOAL: Identify the needs and demographics of potential users.

 

USER GOALS 

​Before conducting any interviews, I had to figure out what I wanted to learn from the interviews. I developed research goals which helped me identify what I needed to know about my users, and what types of insights were most relevant to helping me find solutions to my problem statement. I set out to:
 

  • Determine the factors surfers use to decide whether to go surfing or not.

  • Identify the needs, behaviors, and thought processes of surfers.

  • Identify the pain points and the features surfers liked or disliked from surfing tools they used

​

USER INTERVIEWS
I created a script and a list of open-ended questions that focused on uncovering the motivation behind the user's actual behavior. To better understand the needs and behaviors of surfers, I recruited:
 

  • Five male surfers that I personally knew 

  • Who were living in California, Maine, and Ireland

  • Aged 26, 32, 35, 38, and 43 years old
     

After collecting this data I realized I hadn't been specific enough in my problem statement which created open questions and ambiguities. I realized I needed to eliminate sailors and divers as potential users for my MVP given the scope and timeline of the project. Removing vagueness from the problem statement allowed me to narrow the scope of the problem and make it solvable. I then used affinity mapping to see the relationships between the patterns in my interview data.  

2

Before

After

TAKEAWAYS: After creating personas I had a clearer sense about the demographic of my potential users and their similarities:

​

  • Why Surf: Because it helps surfers disconnect and stop thinking about everything else, it’s peaceful, provides exercise, and is a way to socialize and spend time with friends

  • Why Go: If there’s time available, if the surf is good, if a friend is going, if the general weather forecast is good, if the wind direction/speed, swell height/frequency, and tide are good

  • Cons: Incorrect wave forecasts, not surfing well or getting tired from large waves, if surfers steal waves or beginners don’t follow etiquette, not making it past the break, busy beaches

  • Pros: Hanging out and joking with friends, beautiful weather, offshore wind, clean waves, warm water, no overcrowding, and sleeper days when the forecast is wrong but in your favor

  • Favorite Tools? Apps like Surfline and Magic Seaweed, NOAA buoys, local webcams, or just go look at local spots in-person

3
USER PERSONAS
 
GOAL: Take user research data and give it a face and a narrative. 
​
EMPATHY MAPPING
The first time I sketched out my personas I didn’t create an empathy map beforehand, and as a result, I wasn’t able to effectively differentiate user needs versus wants. I went back and created an empathy map to validate that my personas made sense, but quickly realized the personas needed to be tweaked. Using the empathy map helped me better immerse myself in the user’s environment so that I could uncover their true needs and goals. 
 
USER PERSONA
After conducting and analyzing my user interviews I created hypothetical personas which humanized my users by giving them a face. This helped me develop more specific statements about their needs, motivations, frustrations, and demographic information. I also had to consider their geographic differences, and make sure the goals and motivations were in alignment with each character. Two of my personas didn't quite match up with their character traits at first, but after creating an empathy map I was able to better align the goals of each persona with their demographic and personality traits.
​
USER STORIES
I created user stories to help define what my users would want to accomplish. Translating a human need into a feature allowed me to pinpoint solutions and necessary functionality from a user’s perspective. At first I included too much explanation in my user stories which prevented me from effectively capturing key user requirements. I went back and pared down these stories until they clearly articulated the who/what/why of the user requirements in a format that stakeholders could easily understand.
​
Creating user personas, user stories, and empathy maps was one of my favorite parts of the design process because I got to use my imagination to bring my users to life. By putting myself in the shoes of my users, I could develop more specific statements about their needs and pinpoint necessary functionality from a user’s perspective. I also learned how important empathy maps are for validating personas, ensuring that the goals and motivations of a persona align with his/her character traits.

Before

After

4
USER JOURNEYS & FLOWS
​
GOAL: Determine what users are trying to accomplish, and better understand their behaviors and limitations.
 
USER JOURNEY MAPS
To better visualize and hone-in on the different processes a user goes through to accomplish a goal, I created journey maps. This narrative document outlined the journey of each persona as he moved through a real-world scenario to achieve a particular goal. I broke each journey into phases and added the persona's theoretical thoughts and emotions throughout the journey to breathe more life into the persona. My first user journey maps focused on the future functions of the app instead of illustrating the current tasks users undertake without the app. To solve this problem I went back to my empathy map to help me better understand the current state of each persona.
​
USER FLOWS
After determining what my personas wanted to accomplish in certain scenarios, and identifying what their most important tasks were, I could then write down the steps needed to complete each task. This process helped me find the the quickest and most effective way to get a user from first encountering the task to successfully completing a task. Once the task steps were listed out, I created user flows to illustrate the path a user would take to complete a particular task using the app. 

TAKEAWAYS: I found that user journey maps and user flows:
 

  • Made the task analysis more visual and easier to communicate to stakeholders

  • Made it easier to compare the personas at a glance and see where there were similar sets of experiences (like viewing a surf report) versus more unique experiences (like social media functionality)

  • Enabled me to better see and prioritize the different solutions I could offer users

5
5
4
INFORMATION ARCHITECTURE
​
GOAL: Organize content in a way that allows users to understand where they are and how to find what they're looking for in an app.
​
SITE MAP
After creating personas and identifying key tasks in my user journeys, I was able to begin sketching out the primary screens of the app using pencil and paper. I then used Omnigraffle to build out a more refined sitemap with a numbered hierarchy and a strict hierarchy pattern.
​
CARD SORTING
After developing a plan for organizing the information of the app, I needed a way to evaluate the plan to see if it was correct. Using the website Optimal Sort, I conducted a digital open card sorting test with 25 content/word cards and 10 participants. Users grouped words together that they thought were similar, and then labeled each category they created.

TAKEAWAYS: I found that open card-sorting tests: 

  • Helped me see the most user-friendly way to organize the app 

  • Helped me label categories for navigation, validate certain hypothesized category names, and generate new ideas for category names

  • Enabled me to see that participants were in agreement with the original structure of my site map

TAKEAWAYS: While prototyping I learned that I should: 
 

6
 WIREFRAMING & PROTOTYPING
​
GOAL: Effectively communicate the app's functionality and analyze how users navigate through user flow.
 
SKETCHES
I started out using pen and paper to create sketches of the key features of the app, as well as the onboarding, and login processes. This prototyping was quick, inexpensive, and allowed me to focus on high-level functionality. 
​
LOW/MID-FIDELITY PROTOTYPES
Once the basic functionality was established, I translated my designs from sketches into basic greyscale visuals using Balsamiq. These designs better illustrated the specifics and placement of UI elements, conveying form and function instead of only high-level aspects of the user experience.

​

HIGH-FIDELITY PROTOTYPES
After finalizing my design drafts, I used Sketch to create high-fidelity prototypes which showed how the polished app would look and function. These designs included more detail and provided a preview of how the real UI elements would look and be placed (making it easier to create a mockup).  After creating a static, visual representation of my app's interface, it was time to add interactivity between the different screens.
 
While prototyping, I learned how important it is to take your time when reviewing designs to ensure quality and consistency in the design. I didn’t realize until usability testing, that I had accidentally reversed the order of Yes/No buttons in prompts, and used different words for my Calls To Action throughout the app which created inconsistencies in the design. 
 
INTERACTIVE PROTOTYPE
To effectively communicate the app's functionality I used InVision to make my high-fidelity designs interactive. I imported my designs from Sketch into InVision and added clickable elements on each screen.  When I was finished I had an interactive prototype that demonstrated the core functions and specific interactions of the app within a browser. Now I could put this MVP in front of users to get feedback on the usability of the app and its features.

TAKEAWAYS: From usability testing I found that users:
 

Didn't intuitively know what the ellipse menu was or did

  • Solution: Remove the ellipse menu from the beach tiles on the home screen, and add icons for Surf Report, Forecast, and Webcam on the tiles instead.

​

Didn’t know there were two ways to view a webcam or how the two pages were different

  • Solution: Remove the video player from the home screen, add a Webcam link on the beach tile instead, and replace the video player with a map of the beach.

​

Were confused by the onboarding swipe menu and messaging

  • Solution: Replace the four onboarding screens and swipe navigation with one screen listing the core benefits of the app and the option to tour the app or sign up for it.
     

Could not easily find the plus sign icon in the top nav to add a new beach

  • Solution: Remove “+” from top nav and put it next to the beach name.

​

Were frustrated by the bareness and lack of helpful information on the home screen.

  • Solution: Pre-populate the home screen with nearby beaches.
     

7
7
8
USABILITY TESTING
​
GOAL: Evaluate the ability of users to complete specific tasks while using the app.
 
TEST PLAN & SCRIPT
Since the ultimate goal of design research is to build something useful for real people, I needed to evaluate the usability and utility of my prototype. I created a usability test plan to outline the goals, scope, and logistics of my testing sessions, as well as a test script to ensure testing consistency. In my test script I laid out the core features I wanted to test, and created a list of scenario tasks in addition to the direct tasks to provide more context.
 
METHODOLOGY
After deciding on the features I wanted to test, I opted to use both moderated in-person tests and moderated remote tests because I was still in the early stages of prototyping. In-person interviews would allow me to provide guidance in case of missing functionality and permit me to observe body language and ask follow up questions so I could dig deeper into the "why" behind a participant's behavior. I recruited test participants through my personal network and met with participants either in-person or over Skype.
​

SESSIONS

During each test session I asked participants to complete tasks using my interactive prototype on their mobile phone. I also asked them questions about their experiences using the product. I observed, listened, and recorded the speed, efficiency, and ease, with which participants completed the tasks. Through this behavioral observation I was able to pinpoint usability problems and gain insight into participants' satisfaction with the prototype.

​

ANALYSIS & REPORTING

Before I could make any further design decisions I needed to interpret and sort the feedback I had received from my usability tests. I used a closed card sort affinity map to condense my observations into concise pieces of information so that I could group 

key insights together and identify patterns. Next, I used Tomer Sharon's "Rainbow Spreadsheet" to rank the errors and better present my results in a visually organized way. With this information I could then identify the top errors that I needed to fix in the next iteration of my prototype.

TAKEAWAYS: While refining my design I learned that it's important to:
 

  • Ensure design and interactions adhere to the iOS or Android guidelines when developing a native app

  • Apply accessibility guidelines early in the design process to save time, especially since resulting solutions can sometimes change key elements like the color palette which affects every screen 

  • Apply different sets of design patterns for different devices, because the methods for accessing features are not the same

8
REFINING THE DESIGN
​
GOAL: Polish the design of the prototype so it can be released for further testing.
 
STYLE GUIDE
I selected a vibrant color palette to represent the water, sky, and tropical flora of Hawaii because I wanted to pay homage to the sport's history and traditions. I created a style guide to outline where and how the different design elements should be used. I also created a design language system to provide context and ensure design consistency across multiple platforms and devices. I needed to make sure my design and interactions adhered to the iOS guidelines since I was developing a native app. This meant resizing elements like table rows and nav bar accents as well as changing the system typeface to San Francisco for accessibility purposes.
​
RESPONSIVE FRAMEWORKS
I opted to use a fluid grid system (320px wide with 5px gutters and 12 22px wide columns) to help structure the content because it offered flexibility when scaling  up the design. I chose to use several of Bootstrap's reusable components and glyphs since I'm not an expert coder, my design was simple, and I had a quick turnaround time.
​
ACCESSIBILITY

To ensure my app would be useful to those with disabilities I needed to apply accessibility guidelines to my design. I went back and thickened body text and tweaked colors to ensure a 4:5:1 contrast ratio between graphics, text, and background colors. In addition to using colors as a way to provide information, the app also uses labels to indicate what elements do. Action verbs were used to specify what a button or icon does, glyphs were used to indicate errors, and form labels were added above input fields for the visually impaired. All buttons in the app had touchable targets of 48dp to ensure usability for people with impaired mobility.

​

HAVE A QUESTION?

bottom of page