Role
I became Lead UX on the platform since early 2020 and took on the additional role of PO for a brief period during the project. As Lead UX, I was accountable for the entire end-to-end user experience, including the dashboard, user management, notifications, emails, reporting and other operational journeys.
In addition to design, I've created and led a multidisciplinary team of UX designers and visual designers. At any one time, there have been up to three UX designers and two visual designers in my team.
As part of my role, I've been constantly collaborating with PMs, BAs, POs, and RTE.
The challenge
When I started the role, it was clear there were challenges ahead. The platform in question was derived from the existing legacy M2M portal that suffered from multiple issues - instability, dated look and feel, low operational speed, and lack of freshness and accuracy of the data shown.
Meanwhile, the product strategy was clear: reduce the workload on our agents, provide fresher data, and move to cloud-based infrastructure where possible. In other words, this project was not a simple design overhaul. It needed to be a product overhaul, rethinking how things operate, and how to deliver them effectively.
Another challenge, one that cannot be underestimated, was scale. Unlike a simple dashboard project with some nice happy journeys, the product in question was an enterprise-grade product with many features and requirements.
Solution
When I started the role, it was clear there were challenges ahead. The platform in question was derived from the existing legacy M2M portal that suffered from multiple issues - instability, dated look and feel, low operational speed, and lack of freshness and accuracy of the data shown.
Meanwhile, the product strategy was clear: reduce the workload on our agents, provide fresher data, and move to cloud-based infrastructure where possible. In other words, this project was not a simple design overhaul. It needed to be a product overhaul, rethinking how things operate, and how to deliver them effectively.
Another challenge, one that cannot be underestimated, was scale. Unlike a simple dashboard project with some nice happy journeys, the product in question was an enterprise-grade product with many features and requirements.
Research and testing
One of the strengths of this project was the number of sessions I ran with various stakeholders over its course. Throughout the years, I've facilitated and conducted over 100 discovery interviews, concept validations, prototype tests, stakeholder reviews, and regular research.
These regular touchpoints kept us grounded in reality. Instead of making assumptions, we've found ourselves facing the truth about the current user experience. From identifying what information they need to see first, discovering what was wrong with the current journey, and finding out how difficult and unstable the interface had become.
The most important lesson was not simply the datedness of the UI. It was the difficulty that people faced performing crucial tasks on the product. People needed easier access to the necessary operational data, higher priority displayed, and confidence that the product represents the current status of their SIM estates.
Testing and stakeholder discussions have also driven the order of features delivery, allowing the team to bring the more useful functionalities forward and abandon less valuable ones sooner.
Design and delivery
As I mentioned before, I've relied on research, wireframes, user flows, prototypes, and collaboration sessions with stakeholders. My design approach included both creating designs and using design artifacts as communication instruments. User flows helped stakeholders understand what journeys are and their potential pitfalls, thus minimizing bugs during delivery.
Prototypes were instrumental in ensuring the product behaved correctly before committing development effort. Together with flows, they allowed the team to create the desired experience faster while reducing defects and saving precious time.
Eventually, I designed user experience across all major components of the platform (dashboard, reporting, user management, notifications, email journeys, and others), while conducting stakeholder workshops to align around most relevant features and prioritize them.
Team, tools, and systems
One important change during the project was switching from Sketch to Figma. At first glance, this may seem as a simple tool change. However, it allowed the team to collaborate effectively, iterate quicker, and maintain closer contact with the stakeholders.
Furthermore, using Figma made us able to redesign the existing design system and UI components properly, instead of patching it with new icons, assets, buttons, and patterns whenever possible.
With time, the components, patterns, layouts, documentation, and other assets evolved significantly, as informed not only by design decisions but testing and delivery experience. As a result, it gave birth to a more consistent design system, whose assets are still used across many other products within the larger IoT department.
This is also the aspect of the project where true leadership has taken place. Maintaining the consistency and scalability of the team effort involved a lot of work with stakeholders to set priorities and ensure the necessary level of quality.
Sometimes it was not so much about the direction but how much quality we should strive to achieve in order to justify delivery.
Outcome
It's impossible for me to cite hard numbers here. However, I can safely say that the efforts of my team and me contributed to fewer defects, faster handoff and implementation, better task completion rate, and higher functional capability of the journey features.
Apart from improving the product itself, the project also helped transform the way the team works – increasing collaboration, improving communication practices, developing design systems mindset, and becoming better at decision-making.
For me, this was a great example of how product design leadership is supposed to look like. It was not just about making the screens pretty. It was about creating a condition for success of a product and its development over time.
Reflection
Reflecting upon the project after the fact, there are two things I would definitely do differently.
First of all, I would focus more on quality. Working on a complex product in a highly technical domain makes it tempting to neglect quality to save development time. However, in an enterprise environment, quality is always important.
Secondly, I would spend more time working with our engineers. The closer designers and engineers work in such platforms, the better product-related decisions can be made.
