Genesis and assumptions.
A multi-level platform for managing the ski stations informations
The main assumption of the SkiOS product is to enable the ski stations in the region to collect up-to-date data on the status of their infrastructure. Which can then be made available through various information channels (internet, media, advertising screens, external third party services) to tourists visiting the mountain region.
The product included:
• A multi-level platform managing the entire infrastructure of the ski station (ski lifts, routes, weather stations, machines, gates, employees, service technicians).
• A mobile application for station employees to supplement up-to-date infrastructure data and respond to current incidents in the mountains.
• A mechanism within the platform for people managing information about the region and enabling moderation of content leaving the station to end users.
• Builder for generating fully configurable widgets with information about the region, not only in terms of displayed information and the appearance of the interface.
• Marketing and information tools that allowed the creation of advertised campaigns, sending information or warning alerts regarding safety in the entire mountain region.
• On-site information and advertising applications in the form of interactive kiosks and passive screens.

SkiOS System
Product design process
Think — discover.
Discovery workshops with the client (Tatry Super Ski) and part of the team:
Defining business and project goals, main problems and discussing what this project / product is and what it should not be. Attempts to organize the above issues with the help of Value Prosition Canvas.
Defining the initial user segments of the system (including the planned product development strategy), defining the initial protoperson and, at this stage, quite general User Stories, which translated into a solid basis of knowledge about users / customers, their needs and problems.
Expanding the knowledge about the main user segments by means of IDI interviews of various depths, environmental research in the form of participating in the daily tasks of the ski station employees, during which the enormous amount of information needed to create a product was collected (Kotelnica Białczańska, Rusiński, Meander).

Think — discover.
Verification of information and assumptions about the main user segments based on interviews and observations, introducing changes and corrections to Value Proposition Canvas and User stories, which gave a real picture of the needs and problems of our users and showed a more detailed direction of development.
Research of market solutions in the field of management systems, not only in the form of direct competition, as well as indirect products or solutions completely unrelated to our industry, which gave a picture of what solutions to avoid and which would be worth applying to our system.

Think — ideation.
Preparation of lists of functionalities that were to meet the needs and problems of our users and customers.
Prioritization of functionality using Priority Matrix but taking into account a strong MVP and meeting basic needs and solving the most important problems. We also had to take into account a very limited budget, which resulted in a lot of shifts of important (but not the most important) functionalities to subsequent iterations.

Make — implementation.
Preparation of user flow taking into account the main needs of users for various customer segments.
The next very difficult task was to draw a full map of the system with a strong emphasis on the architecture of objects and connections between them - mapping all functionalities and marking all connections.
The next step was to prepare full, low-detailed mockups based on previously developed User flows and system maps.

Make — implementation.
The final stage of designing was to create the basic Style Guide and System Design for the entire range of products. The style of the GUI was selected in terms of ease of implementation (limited budget) and matched to the client's branding.
Creating mock-ups was related to the implementation roadmap and spread over sprints, which resulted in the smooth implementation of new functionalities. Any corrections and errors encountered after implementation (whether on the design or development side) were broken down into subsequent sprints, ranging from critical errors to negligible ones.

Learn — delivery.
As the development of the system / platforms or even products can never be called finished, we had internal testing procedures after each sprint. We had to wait for usability tests, feedback from clients and users until the quarterly release of the feature group. Which, for the most part, resulted in tests and research being done sketchily and sometimes even omitted. The only thing that improved was the critical comments of customers and users.
Main problems.
Due to the very small amount of time, we had to release the main functionalities without internal QA tests, which resulted in huge problems with the operation of the platform: bugs, missing features at customers or general software instability. This was caused by some of the application's web code being saved locally by the browsers (Service Workers) at the clients' premises.
Another problem encountered was the omission of usability studies or even business insensitivity to customer feedback. On the other hand, there was again an exaggerated focus on less important problems and errors in favor of the critical ones that have been deepened and well described.
The problem with the integrations used with external partners that caused a lot of problems after implementation.
Very large implementation chaos caused by the lack of experience among people managing products / projects.
