Some data from the research, analysis, development or tests may be omitted due to NDA with Client Company. For additional details or discussion, feel free to contact me here.
The purpose of the research was to gain actionable insight and learn lessons relevant for solving the problems presented. I am neither proving nor disproving the existence of these problems or the correct solutions, as the proof would require thorough, strict, scientific method and possibility to replicate the test outcome in controlled environment.
Although, solutions to specific problems are founded in data gained from research or tests, they are still subjective and based on my critical thinking, creativity and experience. It is possible that there are numerous solutions, many of which could be potentially more successful in particular product and for particular users.

About Mountain Rescue Service

Mountain Rescue Service of Serbia is a voluntary, non-profit organization founded in 1952. Currently it has around 250 active members experienced in free climbing, speleology, skiing, CPR and other skills. MRS participates in rescue actions in mountain and urban conditions, on skiing tracks, caves and exposed mountain areas.

Existing app

Existing Mountain Rescue Service app was outdated and lacked usability. Members of MRS would visit the app when they needed to enter action plan into the system or view details of the existing plan and they were not spending much time in it. Most of them didn’t even use app because every notification was sent to the email list or communicated directly via phone call or SMS. This system worked successfully for almost a decade, but it had serious downsides regarding overview of the action plans, management of equipment and lack of additional options.

existing app

The goal

The idea was to create highly usable app by discovering what functions are necessary to MRS through research and data analysis. Functionality was priority and form was secondary as it could provide distractions. We agreed that task completion time needs to be as low as possible and task completion rate should be 100 percent. Even a single user not being able to complete the task in app might create problem for the whole organization.

My role

My responsibilities as UX designer were to organize research, analyze data, develop concepts, create interactions and user interface, and define tests to validate the usability of the app.
I knew almost nothing about the procedures and workflow of MRS, so I also organized guerilla tests whenever I created an important functionality, interaction or UI pattern. The app requests were clear from the start, but after data analysis, I added few options, which turned out to be very useful. The final product of my work were pixel perfect mockups and animations of transitions delivered to the development team.

The research

I started out by analyzing existing information architecture, organizing options into appropriate pages and considering additional options to enhance usability. I created detailed sitemap and concentrated on research leaving my presumptions regarding IA until after data analysis.
Since this was a closed app and number of users was limited, my first idea was to talk to all of them. I quickly discarded this idea as impractical and time consuming, and instead created a short survey with Google Forms and questions related to the use of current app, use of devices and everyday workflow. Survey, members’ files and app analytics provided a general image of users and their interaction with the app.

Survey results

Next step was to discover “why”, so I organized qualitative research in the form of interviews. Interviews were informal, friendly chats and we did them at the local coffee shops. MRS members didn’t mind the music in the background, they were relaxed, open to questioning and generally eager to help, so the quality of answers was satisfying. Some of the comments were that old app needs a serious update and that functionality of the app is limited. I realized members had their vocabulary related to MRS and workflow, so taxonomy and labeling the options was straightforward. A clear pattern emerged regarding the requirements of the app as all users cited action plans, equipment and resources page as the most important aspects of the app.

Notebook

Survey and interviews were qualitative and quantitative methods, but both attitudinal. In order to confirm my assumptions and probe deeper for implied and overlooked aspects of the behavior I asked two members of MRS to participate in contextual inquiry. I observed what apps they use, how they use them, what was the context, experience and other details relevant to workflow. Each session lasted few hours for, produced a lot of data, but it gave me few ideas for additional functions of the app, not considered earlier.
After I collected all replies and information, it was time to filter and analyze data. Some of discoveries were that members rarely accessed MRS app from devices and action plans are created before action, but completed with comments after the action is finished. I also realized most members are familiar with Google products and use them on daily basis.
With new finding and ideas I got back to my sitemap from the beginning of research and edited some of the options.

sitemap

I had a good grasp of the requirements of the app, so I performed competitive audit and analyzed Google products and few shopping sites to get a grasp of indexing possibilities and other options. Based on these solutions I created guidelines regarding browsing, filtering items and displaying action plans on calendar, which later helped me in generating concepts.
The whole research with survey, interviews, contextual inquiry, IA, data analysis and competitive audit took about a week to perform.

Deliverables

With useful data and good insight on users, I just sketched and wrote down some ideas in a messy mind map, than I created a priority matrix of all the app options. I also implemented ideas for additional options, which were notifications page, auto save action plan as draft and filtering actions plans.
Usually, I would create personas to help me keep empathy and user needs in focus, but I decided not to create them for this project. This project was specific because number of users was limited. I developed empathy and understanding of the user needs during interviews and contextual inquiry and I didn’t want personas to distort these impressions. I did create half a dozen user scenarios, which were reminders of the motivations for a specific member.

user scenarios

User scenarios were base for creating user flows. Most of user flows contained some interaction with creation, editing or browsing action plans. I confirmed with the members that the first page after login should be Actions page, not Notifications as I originally planned. Other flows had a goal to check equipment availability or contact members. Since every user scenario began with signing in, I considered different options to automate this process, but I realized third party password management apps are best solution.

User flow

Now I could work on user interface. I started sketching Actions page with pen and paper. This allowed me to create many sketches and work quickly on iterations. The main navigation was at the top, but there were many additional controls and filters, especially for Actions and Members page. I tried moving these controls around, but eventually stuck them to the left side, as it was simple and well-known solution. From research I knew that actions should be filtered by location, date, participants and type and members page had even more filters, location, rank, actions, skills, experience and company.
I wasn’t sure how to present actions overview and how users should interact with this option, so I made couple of storyboards. First solution was a full-page calendar. I discarded it for combination of Gantt chart and slider. I created a wireframe in Balsamiq and quickly tested it with members. Gantt chart slider had great results. This solution left a lot of free space below, so I could display a table with basic action details. One of the “cool” solutions was to use cards to display actions instead of the table, but the comments were mostly negative.

Gantt chart slider
Gantt chart slider

Other important function was creation of new action plan. Action plan creation was specific because there were many fields to fill out, and users should be able to edit details or add comments after completion of the action. The solution was to divide many segments into 2 steps. The first step related to the preparation of action and second step with fields for post action comments. If user needed to add comments or other details after the finish of the action, he would be automatically taken to step 2. Most of the fields were text, calendar or radio buttons, but adding members as participants in action and adding necessary equipment was solved with modal window. Rest of the pages with equipment, members and resources were straightforward to create, as they didn’t have any special interactions.

I was satisfied with sketches and started creating UI patterns and mockups in Adobe Illustrator. Since app was intended for use on desktop and laptop computers, the UI was fluid but it had minimum width of 768px. I involved members of MRS in preference tests and quick guerilla tests whenever I finished a significant part of the page, important UI element or interaction. By pointing details related to their procedures I was unaware of, we were able to optimize and adjust interactions. I finished layout of the pages, but didn’t work too much on esthetics, as MRS still needed to define their branding identity. Planning, creation of deliverables and mini tests took one more week to finish.

Testing

During the creation of deliverables I constantly collaborated with MRS members, performing many guerilla tests or preference tests followed by Single Ease Question and gap analysis, or analyzing task completion rate and task completion time. Some of these tests were in person, but most of them were remote, via Skype or email. I wouldn’t usually perform tests via email, but in this project I had really good connection with MRS members and the goal was clear: simplify their workflow and provide all necessary options to ensure good usability. This is why I could count on good quality of answers.

Testing notes

Every time I would finish a storyboard or mockup, I would send it to my test subjects and quickly receive back feedback. If concept or interaction received negative comments, I could immediately pivot to different solution, so tests were like mini, remote brainstorming sessions.
After finishing high fidelity mockups, I created prototype with InVision and half a dozen members tested it, just to be sure there weren’t any bumps in usability and inconsistencies in user flow. High fidelity mockups, transitions and prototype took about 3 days to create.

Conclusion

I seldom had an opportunity to create a product for a limited and very specific group of users. There were no concerns about the scalability of product, integration with other systems or pivot points. Possibility to meet and talk to every user of the app was amazing and even though this approach is not applicable in the development of most products, it was a nice exercise for empathy, interviews, contextual inquiry, pattern recognition and preference testing. Visually, I created very simple UI inspired by Material Design guidelines, which can be easily rebranded later. However, the most important thing is that MRS members appreciated the new app and useful functions for streamlining their workflow.

Did you like this article?

Please subscribe if you wish to receive new post updates once in a blue moon

or share with your friends