top of page





Customers can't interpret modem and device speed test results, and need more context and education to troubleshoot internet speed issues.


Develop a speed test that provides customer education around internet speeds and easier troubleshooting steps for improving internet speeds.



Competitor Analysis



User Journeys & Flows

Information Architecture

Wireframing & Prototyping

Usability Testing

Refining the Design

Done in 1 Week


  • CLIENT: National Institutes of Health (National Institute of Diabetes, Digestive, and Kidney Diseases)

  • ROLE: I served as the Experience Designer on a 14 member team (alongside project managers, developers, Q&A, and a designer).

  • DURATION: 1 Week

  • SCOPE: NIDDK's website is the Institute's public face and arguably the single most important communication channel to the research community and the public. The migration required the redesign, content update, and technical reconfiguration of almost 900 web pages and touched more than 300 NIDDK employees.

​GOAL: Identify the issues and opportunities that exist in the weather and surf app space.
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.

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. 

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.


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


GOAL: Identify the needs and demographics of potential users.



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

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.  




GOAL: Determine what users are trying to accomplish, and better understand their behaviors and limitations.
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.
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

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.
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.
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: 

GOAL: Effectively communicate the app's functionality and analyze how users navigate through user flow.
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.

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.
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.

GOAL: Evaluate the ability of users to complete specific tasks while using the app.
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.
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.


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.


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

GOAL: Polish the design of the prototype so it can be released for further testing.
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.
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.

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.


bottom of page