SafeSki is a mobile application providing access to ski patrol anywhere on a mountain by the click of a button. The concept was derived from the need to be able to call Ski Patrol at your finger tips and cut down the wait time rather than sending someone to go get help. On the click of a button, Ski Patrol is on the way for a rescue.

Information Architecture

Each step of the planning process was derived from the initial user research and responses in order to provide the users with the best final product.


Each sticky note represents a page in the system on both sides–the ski patrol website and the skier/snowboarder mobile application side.

Thinking Out Loud

This is the time of the planning where no idea is a bad one. Each page can be placed on the wall but nothing is permanent. All in all there are a current total of 15 pages between the application and the website.

Thinking on Paper

Below are the original sketches of SafeSki when it was just a thought. Notice at the time it was called, “SkiSafe.“ On the left are the original application sketches and on the right are the original website sketches.

What's The Difference Here?

The difference is that these sketches below occured after user research was complete. Although they do look relatively similar, these sketches incorporate new information and resources from user and technology research.


Personas are a way to get into the mind of users. Users always come first so what better way to put them first by giving them individual personalities and needs. Below are three personas dedicated to the types of users. You will see two for ski patrol and the various roles that they hold. Additionally, there is one skier to represent both skiers and snowboarders.


Visual Design and Mock Ups

The Adobe XD mock ups serve as a starting point for the finial product design and appearance. Although neither are set and stone, they serve as rules for the remaining product design. Just remember... good design breaks rules with intent and purpose.

User Testing

I completed user testing throughout. Below is an example of a user testing session which I completed with numerous individuals.

Entry Script: Thank you for participating in my user testing. I will be sharing my screen and reading a scenario to you and then I will have you tell me what you would click to make it through SafeSki. At any point along the way ask questions and feel free to address any concerns that you may have.
Scenario: You are stuck on a mountain and injured your leg. You are not in any severe pain, but you definitely need help. Use the SafeSki app to call ski patrol and work through the steps as needed. Feel Free to stop and ask me questions along the way.
Results Each of the users got through the application in under 3 minutes. They were able to figure out the beginning steps from sign in, log in, to send location. It was verily clearly understood when ski patrol was on the way. One request was at the bottom of the form it would be valuable for the user to be able to write a note with their request. Come the “Hang tight page,” users would prefer to see hospitals in order to see next steps at the top, then ski patrol, and then breathing exercises. An additional concern is there is no clear mark button back to the home page other than the cancel buttons which also need to be added later on. These are small changes to be made, like making sure I have cancel buttons, back buttons, and reorder things to make the most sense. Additionally, with the need for a notes section on the forms page, I will likely move some of the forms to a second page to reduce the initial load on users. Overall, this was successful user testing and proved my work thus far to be effective. Each of my users were excited for the final product and also discussed how useful SafeSki would be in a situation.

The Final Results

The final results are created from all of the research, testing, planning, and design thinking done above. Each and every element in the final design was coded wiht HTML, CSS, Bootstrap, Javascript, Jquery, and Google Firebase.

Final Thoughts

SafeSki was intellectually challenging for me from start to finish as I expected it to me. At the very beginning stages of ideation, I knew I was being relatively ambitious with some of the features and technology that I intended to use. I learned a multitude of new information about how various technologies and systems work together and how my own personal skillsets align with them. SafeSki challenged me to add more structure to my designs than I usually allow time for. Specifically, I had to plan far in advance and ensure that I allowed time for preparation, learning and development time, design time, user testing, and additional time to debug the application.

Toward the beginning of SafeSki, my intention was to have a mobile “app” or PWA(Progressive Web App) that would be fully built out which I knew was a job for a team of more than one but my tenacity and determination led me to try to do it all on my own. I am proud to say that my the end of this project, although not entirely functional to its full capability, I sure checked off a lot of boxes.

The timeline of this project spanned from the end of February through May. I worked tirelessly at the beginning of this project and even through sprint zero to spend time building up the structure of SafeSki and learning about each of the given components– firebase, JavaScript, json, html, and CSS. I was most comfortable with HTML and CSS to start and had done some JavaScript previously. JavaScript and Google Firebase were a very quick way to push me out of my comfort zone and I sure learned rapidly. One of the things I learned from this rapid growth period was how much I was capable of doing in such a quick period of time. I spent mornings and evenings learning the nuances of these languages and systems and slowly but surely build up my own system.

One of my favorite moments of capstone was realizing that I was understanding what I was doing with firebase and Javascript. Firebase is a complex yet very comprehensive system which was awesome to use. Should I have had more time on this project, I would have spent more time on firebase to get my system fully functioning. At the beginning of April, I had to limit my firebase capabilities due to timing. I chose a different route to make sure that I completely the project in a timely manner. I am very happy with that decision because in the position I am in, I do not need to know as much of the back end of things as much as I need to know the functionality of a product on the front-end.

SafeSki resulted in numerous interviews and questions about this project and ultimately will be an application that I pitch in the coming months. I believe and all of my users from testing believe in the capabilities of SafeSki and the ability for it to succeed in the industry as,“the helmet in your pocket.” Thanks for reading and look out for SafeSki on the market!

Thank You for Reading!