I told you so.
This is a story of an engineering team moving quickly and breaking things without waiting for their designer to catch up.
Was I happy? Well, no.
Did we have any other options? Also no.
Did I manage to prove them wrong about their choices? Hell, yes.
This happened back in 2022 when I joined Canonical. I was assigned to work on LXD, a promising product that allows users to spin up and manage virtual machines and system containers. It all started with a CLI (command-line interface) experience. Soon, it became too difficult for users to remember the commands, and they were spending hours going through the documentation to refresh their memory. This is when the idea for a GUI was born—users started complaining about the complexity of the experience.
Using the CLI as a base, we had to build a user interface. A pretty easy and straightforward task, if you're an engineer. And that’s exactly what my engineers did. They started building the UI themselves while I was still busy learning about system containers and getting up to speed with the product. UI demos took place, the UX got criticised, and the designer was behind. A mess.
Rushing through the experience, the developers kept introducing pages, not giving design a chance to catch up. It was time for a serious conversation. Unfortunately, the dev-to-design ratio is always 1:10, sometimes even more, so winning an argument with engineers is not easy.
What we did
As soon as I was ready with the first flows and high-fidelity mockups, I initiated user research. Instead of telling the developers, “The way I designed it is better because I’m a designer and you’re not,” I decided to invite users to test the existing UI (built by the developers) and then explore a design prototype. I also invited my developers to join all the user sessions.
Once they saw users struggling with the current implementation and making the same observations I had been making, the point was made.
Celebrate success
It’s important in situations like this to avoid saying "I told you so" and instead give people space to digest the lessons learned. Below is a screenshot of a Miro playground I used to summarize our research findings.First and foremost, always celebrate success. Some of the experiences already designed and implemented by my engineers were appreciated, and I made sure to give them credit for their work.
Key takeaways
After each session, I asked them to do something simple, but memorable. I asked each team member to write down three sticky notes on my Miro board—'The three key takeaways from the session.' People tend to write down things that surprised them, issues they spotted, or experiences that needed improvement. This technique helps the team realize that success is about iterating on a product, solving real user problems, and adopting a user-first approach, rather than simply mirroring the existing CLI experience.
