EISBACHTIME APP
Eisbachtime is an app that enables surfers to get access to information on how many surfers are currently at the Eisbach surf spots and therefore creates a solution to the growing crowds and unexpected waiting lines at the spots. Through this project I conducted deep research regarding factors, which create a good surf experience at the Eisbach, went to several user testing rounds with different clickable prototypes and developed a High-Fidelity Prototype in the end with a style guide, logo design, animations and a component library.
Projecttype: UX/UI Case Study
Client: free work
Date: 2020 (3 months)
Role: Research, Concept, Design & Testing
Background and problem
River Surfing in Munich has become a popular sport in the city and attracts an increasing number of surfers. Currently it’s one of the main attractions for tourists and locals. The most popular surf spots are the E1 (the most famous one) and the little more hidden E2 at the Eisbach in the Englischer Garten.
With the growing attraction of the sport more and more surfers begin standing in line to surf with the result, that you have to wait 20 minutes to surf a few seconds during summer peak times. This really makes the whole surf experience worse.
Based on my personal experience of surfing at the E2, I experienced that a lot of surfers complain about the long waiting lines. Therefore I had the idea that a “timing app”, which shows surfers how many surfers are already at the wave, might be a solution for this problem.
Process
Explore the whole process step by step or navigate directly to the section you’re interested in.
Research
Ideation &
Lo-Fi Design
Usability Testing 1
Ideation &
Hi-Fi Design
Usability Testing 2
Ideation &
Final Design
Interviews and surveys
Synthesis
Based on the taken notes from primary research a detailed Research Synthesis was conducted. The notes were grouped by topics to see which are the main pain points and what might be opportunities for my app.
Besides the need for getting information about the number of surfers at the Eisbach there were more topics for developing additional features like: tracking options to record training progress, an „advice book“ for new surfers on how to avoid dangers at the Eisbach and how to learn river surfing easier, a feature to connect with other surfers, an option to share photos and much more.
Findings
The following findings only represent the most important key findings of the research, a detailed analysis with additional quotes and insights can be found in the research report below.
Key Finding 01:
A good surf experience is based on the number and the kind of surfers at the wave.
5 out 6 participants mentioned that during their best surf session, there were less than 10 surfers at the Eisbach.
Factors such as the quality of the wave, temperature etc. are not as important as having lots of wavetime.
Less surfers and the right kind of surfers who are at the wave could create a motivating environment.
Key Finding 02:
The surf experience is getting worse if there are lots of surfers or no surfers at the wave.
– 100% of the participants said, that they do not only dislike a huge crowd of surfers
– but also when there are no surfers at all at the wave. (risk of getting injured without anyone notice it)
Key Finding 03:
Eisbach Surfers plan their surf sessions only on assumptions how crowded the wave might be.
Because no one really knows when the wave will be crowded, crowds can exists at various times without any user pattern.
A time which was awesome last week, could be super bad the next week.
Planning according to previous experiences is therefore also tricky.
Emotion bar
Based on the research results, I’ve created an emotion bar, which shows how the number of surfers at the wave influences the emotions and therefore the whole surf experience of the surfers.
Building empathy
To get a deeper understanding and better insights in the personalities of the users, three personas were developed.The personas were later also used to classify users during usability testings.
Ideas for features based on personas
Based on the specific needs of the three personas three feature options were developed. The feature for “New – Surfers” is the most questionable one, because “New Surfers” stay new for a very short time and then transform into one of the other two personas. So the feature for the “New – Surfer” would only bring value for a really short time to the user.
Performance – Surfer
live-rating of the current wave conditions
Social – Surfer
function to connect with other surfers
New – Surfer
surf etiquette or
tips and tricks for surfing
Value vs. complexity validation
Because I cannot establish all of these features in one app, a feature prioritization based on a complexity-value matrix was conducted. The following features has then been tested in a low fidelity prototype:
– Connecting with friends to get notification when they are going surfing
– Set surf alert based on your personal preferences about the preferred number of surfers at the wave
– Providing advices and information about surf etiquette
Wireframing, Prototyping & UX Testing
After all the Research I began with the actual design. First I used plain paper and pencils to sketch some ideas and develop a Low Fidelity Prototype. I’ve decided to do two user testing rounds – the first one with the Lo-Fi Prototype and later again with the Hi-Fi Prototype.
Paper sketches
During the sketching, my overall goal was to reduce the screens to a minimum, so that the user only has to click three to five times to plan a surf session and share the status. The reason for this was that I think if the app would be even a little more complicated, users would not use the app for their daily planning.
I’ve also decided to only establish a menu bar with three icons, to make navigation as simple as possible.
After creating a couple of Ultra-Lo-Fi sketches of the app, I set up a comprehensive Low Fidelity clickable prototype on figma. This prototype was then tested with different users.I deliberately decided to do user testings in a really early development state to see which navigation and user flow work, before working on the actual visual design.
Clickable low-fidelity prototype
Explore the low fidelity prototype below:
Usability testing
For the usability testing of the Low Fidelity Prototype 5 participants were recruited. The only requirement for participants was, that the person has been surfing at the Eisbach (E1 or E2) for at least 3 months.
According to the elaborated personas the 5 participants can be grouped as following:
2 “Social – Surfers”
2 “Performance – Surfer”
1 “New – Surfer”
All sessions were remote sessions and held over Zoom.
An average session took about 30 minutes.
Design iteration
After the first usability testing, I’ve revised my wireframes accordingly. The most crucial points were the instruction screen, which a lot of users skipped instead of reading it and the menu bar which was way to big. I’ve also decided to show the sign-up screen first, because it’s a mobile only application and all the users were confused about the differences between Log in and Sign in. In addition I’ve also shortened the account setting flow and reduced clicks from seven to five clicks. Based on the restrained reactions of the users the feature for New-Surfers (tips and surf etiquette) was also cancelled.
Visual design
To match the minimalistic functional approach of the app, I’ve created a simple but sill unique UI Design. First I though that fresh and vibrant colors paired with beautiful and detailed illustrations would create a unique user experience. The image below shows the development from a very detailed visual design to the final elegant and minimalistic approach. Reasons against the first draft were, that there were just too many elements, too many colors and in general the design was way to feminine for a mostly masculine user group.
So I’ve decided to reduce everything to a minimum of elements and let specific pieces stand out – for example by coloring it in aquamarine. Besides a light black gradient as a background, the app uses a shiny blue gradient for CTAs and all clickable elements. The Blue Color stands for the water (the Eisbach) and the surf sport. In addition there won’t be any photographs in the app only illustrations, which are also only colored in White. Especially the illustrations should create emotions and add playful elements to the otherwise really reduced visual design.
Styleguide
UI component library
Iteration for accessibility
Because I don’t often design with a black background, I’ve decided to check all the colors regarding their accessibility with the online service accessible-colors.com. Especially the UI colors used for success and error notifications failed the color check and had to be altered. I also recognized that even though gradients are a major trend in UI Design right now, there are not very suitable regarding Accessibility, because there is always a color section, which has not enough contrast to the text. All in all I’ve always tried to combine colors with forms and elements to reduce difficulties for persons with visual impairments.
Remote usability testing
Based on the developed visual design guidelines, I’ve created a clickable High-Fidelity Prototype and conducted a second Usability Testing round. The second Usability Testing was a remote testing session with 10 participants over lookback.
I gave them instructions for four tasks, which basically covered all the functions of the app.In general the users had far less problems to navigate and understand the app structure than compared to the Low-Fidelity prototype and all tasks were successfully done.
All in all users really liked to UI Design and especially the illustrations and the Logo. I really appreciated the way users tend to say “Wow” when they saw the first Splash Screen.
Clickable high-fidelity prototype
Explore the high-fidelity prototype below:
Design iteration based on UX testing
Based on the insights of the Remote Usability Testing I made some minor changes like optimizing texts in buttons, replacing some icons with actual text, redesigning search bar, adding some more information in the statistics screen e.g. But besides these minor adjustments, the two main problems were that the users still skipped the instruction screen and therefore didn’† understand how the app mechanism works, and that users had problems with the flow of selecting their status. It can easily be seen that users are already used to a lot of common flows like setting an alert, adding friends, looking at statistics, but that it’s really tough to implement a new element like the status flow and explain automatic changes, which are not known from other apps or services.
Therefore I’ve included additional common elements, like arrows to define the flow, specific colors for a specific statuses and even animated the instructions screen to make the whole process clearer. In addition I’ve included some really visual verifications after selecting the status and added a little notification icon in the navigation bar, so that users clearly see that their selection was successful.
Micro-interactions and animation
One of the last things I did was to explore how motion design and animated UI interactions could improve the User Experience and functionality on a deeper level.
Final design
After all the research, testings, iterations and animations, I’ve created a final clickable prototype based on the last designs. The following video shows a short demo version of the app and below you’ll find a link to the final clickable prototype.
Final high-fidelity userflow
Conclusion and challenges
Even though I got awesome feedback from a great number of surfers about the app idea, the biggest challenge is that whole app would only work if the major amount of surfers would use the app and share their status with the community. Otherwise the app would give users wrong numbers, which would lead to frustrations and over time users would stop using the app. It’s kind of a classic chicken-egg situation. The app would definitely improve the planning process and would enhance the whole surf experience but first hit had to be used by almost everyone at the waves. To remotely solve this problem, a really good marketing campaign before launching the app must be conducted, so that the app draws attention and a huge number of surfers will sign up and use the app.
Furthermore the statuses are mostly based on the time settings, which can vary from day to day. One day you surf for an hour sometimes for three, sometimes you leave after 30 minutes. Even though the status could be changed manually, I don’t expect surfers to keep in mind to change status every time, if for example their surf session was shorter than the time frame they typed in in the settings. Some kind of automatic geo-tagging would be a great solution for the time variations, but would also be a bigger interference in people’s private lives.
Key learnings
Learning 01: Let ideas go
I recognized later that I really held on to the initially idea with the three buttons to select status, even though there were already signs during the first usability testing round that it might not be working. For future projects I will try to be more open to test results and user behavior to adapt even designs I am really convinced of.
Learning 02: Less is more
Especially during the development of the visual design, I realized that you can often create a bigger impact and an outstanding design by reducing elements to the main items and only highlighting a few of them.
Learning 03: Calculating Scope better
Because this was my first project that I developed from start to finish, I really misjudged the scope of the project. My ambition was to create a pixel perfect endproduct with all features totally elaborated. But during the design process I realized that it’s far more important to first concentrate on the MVP and do several testings to have a solid and qualitative product and later iterate feature options in detail again.
Next steps
To make to product ready for launch the next steps would be to test the final product again and pay more attention to micro navigation. If the testing would be successful the app has to be developed with the help of an IT engineer. In addition the scope of the project with all the different animations has to be calculated together with the IT and maybe some animations must be cancelled (my ideal vision would also include animated illustrations but I guess the app would never launch in a acceptable time then).