mail: dkunes@post.cz
mobile: +420 604 820 537
Portfolio
Polygon
Mycroft Mind
2019 - 2021
Description: Polygon is a software product that we have developed for the ČEZ power group. The dispatchers use it to monitor and control thousands of “smart” elements in the power grid. Polygon allows the operator to find out what devices are connected to the network. Also, it reads data from all those devices. Or, for example, it detects which devices are currently not working and why.
My role: As the sole UX designer in the company, I interacted with end-users, conducted user research, and translated the findings of that research into app design. I created the whole UI from scratch. I started with single UI components, and during the development, I elaborated on an entire design system that I then used when designing other applications.
Challenge: The biggest challenge in the project was to reconcile conflicting requirements. On the one hand, there was a target concept, a document signed with the customer that detailed the final form of the application. On the other hand, there were user requirements that were often not reflected in the target concept. The third force was the requirements of the developers, who already had a predefined backend framework for the entire application and a proposed database structure based on the target document, making it difficult for them to meet specific user requirements.
Lessons learned: I learned, for example, that using an elaborated design system enables the whole team to focus on real problems. I also learned firsthand how complex UX design is when a group of managers already specified the entire app’s functionality.
C1
Solitea
2018 - 2019
Description: One of the problems we solved during the development of the new ERP was the gradual expansion of the main menu. With each new functionality, new tabs were added, the menu was getting larger and becoming cluttered for the user. During testing, we found that users often got lost in the navigation structure and had difficulty finding specific functionality.
My role: I was assigned the task of designing research that would reveal how best to arrange the navigation to be in line with the mental representation of the users. I chose the card sorting method that is most appropriate for such a task. I labeled the cards with the menu items and submenus, and my colleague and I had the users sort the cards.
Challenge: While processing the results, I realized a fundamental problem: users did not sort the cards as it corresponded to their mental representation. Instead, they arranged them in the same way as they were presented within their current ERP tool. There was a transfer of learning going on.
So we reran the research. This time, however, we changed the procedure. Instead of menu items, we wrote on the cards the single tasks that could be accomplished with the ERP system, such as “processing an accounting statement” or “adding a new vehicle to the asset register.” We instructed the users to arrange the task cards into logical groups and then add the original set of cards with menu labels.
The conclusions of the second research were very different from the previous one. Through subsequent A/B testing of prototypes based on the first and second testing respectively, we concluded that the menu based on the results of the second research was more intuitive and easy to use. Also, it allowed users to solve tasks more efficiently.
Lessons learned: Everywhere in professional publications, it says how important it is to think through the setting of the research question. This experience has taught me that I also need to think carefully about the research procedure.
Weather Information Service
Honeywell
2013 - 2016
Description: Weather Information Service (currently Weather Onboard) is an app for transport aircraft pilots that displays current weather, trends, and forecasts on a tablet. It allows users to make decisions based on reliable weather information.
My role: In the beginning, I was involved in the development of the ground part of the application. It was designed for desktop computers and allowed airline dispatchers to monitor the weather and send in-flight warnings to pilots about possible risks on the planned route. After some time, the desktop application development was put on hold, and I started working on other projects. When the pilot app was ready, I was assigned as a non-team member to evaluate the product. The evaluation aimed to demonstrate to the regulatory body, the European Aviation Safety Agency (EASA), that the app did not pose a threat to air safety.
Challenge: Back then, there were no given procedures on how to carry out the evaluation. (By the way, I later helped set the industry standards or best practices in the EUROCAE working group WG-106.) But at the time, the only source I could follow in designing the evaluation was AMC 20-25, a document describing the basic principles of software application development in aviation. However, this document was written rather generally without any measurable criteria or requirements.
Therefore, I had to propose a whole set of metrics to verify that the application was safe and easy to use. The evaluation took the form of a simulated flight, in which pilots had to perform various tasks using our application. Based on the good results, we then received a certificate from the regulatory commissioners allowing pilots to use the application in flight. And about a year later, Airbus started selling the app on its aircraft.
Lessons learned: It took me six months to prepare, implement and report on the evaluation and I can say that I was constantly learning during that time. First of all, I had to communicate and cooperate with many people, be it the engineer and programmer supporting the simulation, the development team, foreign airlines, aircraft pilots, or safety commissioners. I also had to learn new research procedures and a lot of technical skills and knowledge. I am convinced that this experience was the most formative for my further professional development.
Contact