/ Genesis and assumptions.
A multi-level platform for managing the company's products and services
A multi-level platform for managing the company’s products and services
Due to the fast and dynamic development of the company in the field of Digital Signage and Hotel TV applications, the company decided to organize its activities and build a specific tool to solve the multiplying problems and needs of its customers.
The BergOS system was intended to bring together all the company’s products in one place. Thanks to it, was possible for our clients to manage their applications and devices, and to build the entire working environment around their businesses using our tools and applications.
The company’s products focused on the platform consisted of:
- Facility management (advertising and tourism industry), i.e. building customers’ own working environment through the structure of facilities and assigning their employees to them who were to perform the tasks assigned to them.
- Marketing & travel applications for Digital Signage devices and large touch screens.
TV applications (including Hotel TV, Streaming, Information) - Builders for the above applications, enabling the creation of applications without the specialist knowledge of our clients, which translated into the optimization of the costs of implementing new applications that were quite high and not every client could afford them.
- Integration and management of Smart Home & Hotel systems, i.e. the All in one place approach, which made it possible to solve a very important pain for customers, i.e. too many systems to manage various products within a given business.
- Marketing tools enabling campaigns and marketing activities in the above applications.
- Remote management of devices from DS screens, touch screens to auxiliary devices in the form of modems or hotel automation.
/ BERGOS SYSTEM
The process of designing a product
/ Think — Discovery Stage
The beginnings of the platform development were rather chaotic. As we continued building various products for the company, we were receiving a stream of requirements and problems to solve. Clients not only needed a way to manage the applications we had built for them, but also the devices on which those applications were displayed. Initially, we made unsuccessful attempts to create separate systems for each type of product, but those efforts ended in failure.
To bring order to the incoming requirements and unresolved problems, we planned a series of design workshops. Initially, these workshops were held with business stakeholders to define an appropriate business model for the future platform. During these sessions, we outlined business and product goals, mapped out existing challenges, and identified the target user groups. Tools like the Business Model Canvas helped us organize this information and solidify our assumptions. To better address our clients’ needs, we also created a Value Proposition Canvas that captured their goals, fears, and motivations. In addition to defining these values, we also clarified what our product should and should not be.
To support the product definition process, we wrote a series of user stories describing the platform’s core functionalities and how potential users might interact with them.
In the following workshops, we brought in technical stakeholders—mainly developers—which allowed us to better define the technical capabilities of our solution. This included the technologies we needed to adopt, required integrations with external systems, and the estimated workload needed to implement the product.
/ Discover — Research.
To deepen our understanding of the problems collected during the workshops, we conducted several user research studies with representatives from our identified user segments. These were primarily employees of our clients who would likely take on different roles in the system. The first study was a survey that acted as a screener to identify user needs and problems. It helped us gather valuable data that we compared with previously collected business input.
The second study involved in-depth individual interviews (IDIs), which allowed us to explore user problems, needs, motivations, and concerns at a deeper level. To help respondents visualize the concept, we used user story excerpts and low-fidelity mockups of earlier solutions. These interviews resulted in many useful insights and ideas directly from our target users.
/ Think — discover stage
Following the research phase, we aggregated and analyzed the findings, incorporating them into our previously developed canvases (BMC and VPC). These insights gave us a more realistic picture of user needs and challenges, helping us refine the direction of the product. To complete our understanding, I conducted a competitive analysis of similar management systems from both direct and indirect competitors, as well as from adjacent industries. This revealed valuable features and inspired us with ideas from tools like Wix, Squarespace, Webflow, and Bubble—especially for application creation and management.
/ Make — Ideation stage
At this stage, we moved on to ideating the future solution. Brainstorming workshops helped us generate functional ideas aimed at solving the identified problems and user needs. A particularly useful tool during this phase was the Opportunity Solution Tree, which we used to map functionality based on specific user and business needs.
After the workshops, I collaborated with a business analyst to describe and document a list of required features for the platform. These were based on our user stories and previous workshop outputs. Together with the business team, we prioritized these features using a Priority Matrix to define a long-term product and business strategy. Although every function seemed valuable, we chose to focus on addressing users’ core needs first—especially those in key behavioral segments.
/ Make — implementation
One of the most complex and challenging tasks at this stage was preparing the user flows and system map for the platform. The overwhelming number of required features made this especially demanding. Working with a system analyst, we began by mapping the core functionalities, such as managing applications, devices, locations, and users. We then connected these individual maps, carefully considering the touchpoints between them. One of the critical needs we aimed to meet was platform flexibility—for example, seamless navigation between device and application configuration.
Mapping functionality for the Digital Signage and Hotel TV application creators was also particularly challenging. Here, we drew inspiration from other industries, especially tools like the Wix editor. Once the system map was finalized, I began developing user flows for the core platform features, including application creation (with and without the creator), device management, user creation, and object structure management.
After the demanding system mapping and user flow phases, I moved on to wireframing. Before jumping into design, I conducted a desk research study on trends and best practices in management system UI. I browsed industry websites for inspiration and revisited the screenshots gathered during our competitor analysis.
I began visualizing key platform functionalities with low-fidelity wireframes, which allowed me to focus on mapping user flows quickly without getting caught up in visual details. Thanks to the previously defined flows, I was able to design the main screens with ease. I followed a top-down design approach, starting from the primary user journey and then detailing the secondary elements of each feature.
Once the low-fidelity wireframes were ready, I was able to start collaborating with developers early in the implementation phase—before final designs were complete.
/ Make — implementation
During this time, we also began working on high-fidelity mockups in collaboration with the UI Designer. We started by analyzing current UI trends for web applications—especially for management systems—by reviewing best practices on industry platforms. This research helped us define the style guide for the product, which we iteratively built by testing different visual styles and drafting example screens.
When designing the final UI views, we followed the same principles as in wireframing: starting with the main user paths and refining the supporting elements afterward. The development of final mockups was closely tied to our implementation roadmap, which required delivering a portion of the system at the end of each sprint. This helped ensure a smooth and continuous implementation of new features.
While designing the final views of our solution, we also started building a local library of reusable components that would serve as the foundation for a Design System. This system allowed us to speed up the design of future features and significantly reduce development costs.
The process of creating components was closely aligned with the work of developers, who built their own corresponding components at the same time. This close collaboration resulted in a consistent and well-integrated solution.
As each set of mockups was completed, I worked closely with developers, explaining how individual UI elements should behave, including interactions, transitions, and animations.
/ Learn — Delivery Stage
After launching the MVP version of the platform, we began internal testing. I was actively involved in this process, which allowed us to identify a large number of bugs and system issues. Next, we released the platform to our first clients, giving them access to core features for application and device management. To ensure proper onboarding, I created a set of user guides in both PDF and video format, explaining how to use each system feature.
Within weeks, we started receiving feedback from users pointing out bugs and issues. To better manage incoming reports, we created a ticketing system where the development team could track and resolve the reported problems.
Due to limited budget and some internal resistance, we weren’t able to run full-scale usability tests. Additionally, the number of features requiring testing would have made the process very costly. To support the product’s usability despite these limitations, I conducted a series of guerrilla usability tests. These were performed with employees and acquaintances and focused on testing the main features of the platform. Even though the tests were lightweight, they were conducted professionally—from preparing test scenarios to analyzing results in structured tables. These tests helped uncover some critical usability issues, which we addressed in later iterations.
/ Main problems
Despite conducting a thorough discovery phase and identifying user needs in detail, the business often imposed personal opinions—such as “I’m the owner and know better than our clients”—which led to major problems during implementation. This mindset resulted in huge resource waste on features no one needed.
Another major issue was the frequent, unjustified changes to business logic. Given the complexity of the product, these changes caused higher development costs and unnecessary delays, as the team had to pivot and return to earlier concepts.
There was also a tendency to focus too much on minor bugs while ignoring more critical issues. This led to frustration among clients when we failed to deliver high-priority improvements.
External dependencies created additional challenges—especially when integrating third-party systems or working with hardware providers. These often influenced how the user interface needed to behave. During development, we regularly discovered limitations on the supplier side, which forced us to change our UI. There were also critical bugs in device firmware that made key features unusable, as was the case with the application creator on Samsung and LG TVs.
Finally, the platform rollout was chaotic due to a lack of experienced personnel capable of managing the implementation process effectively.
