Designing calm, when every alert feels urgent
Industry
Water management
Outcome
Banking
Role
Product Designer
Duration
7 months
Tools
Figma, Miro, Microsoft Office, Midjourney
the beginning
In the beginning there was some chaos
Let’s jump to 2022. That’s when a Business Analyst (BA) was hired, who carried out a series of user interviews during the discovery phase.
Based on that, I was able to build personas. While identyfing key roles we found, for example, that many job titles of our target group referred to the same role. Similar to how, in the UX world, a "UX Designer" might be listed as someone who writes code or prepares graphics for whole company. Therefore job titles vary, and responsibilities can shift depending on the company's needs.
The project was named “Posydon.”
The goal – developing a software that would enable service managers to maintain their stations in a proactive way. We wanted to give our clients recommendations of their station current and future status.
Anna completed her work by creating the Posydon Scope Definition and feature tree. The problem was, from a product perspective, it was huge/enormous
target group
And then I came in
The company launched an Early Adopter Programme, looking through their client database for stations with a specific type of pump.
At the same time, I ran our first joint workshop. Over three intense days, we mapped out top priorities, data sources, and both current and target user flows. This helped us plan 2 iterations, based on scope and user types. We decided to start with a shared structure for all users to split it later into:
Customer – wants clear recommendations and the reasons behind them
Wizard – makes those recommendations and keeps an eye on the data
Oh, and did I mention? We wanted to squeeze top engineers knowledge into AI-based solution?
What a great moment to talk about what being a wizard really means.
technique
It’s always about the right people
In IT, a “Wizard of Oz” technique might look like a smart AI chatbot, but behind the scenes, it’s humans replying in real time.
It simulates advanced tech when resources are tight or you’re still early in development. Before you feel cheated, AI doesn’t happen overnight. Good things take time.
To make things more interesting, we had to manage two product versions:
Version 1 – ran on a single data source, with automated recommendations from an internal algorithm.
Version 2 – focused on gathering insights from top engineers and turning that knowledge into an AI-based solution. We called those experts them Subject Matter Experts or, if you remember - wizards.
lessons
We’ve covered a lot, so here’s the essence boiled down to three key points.
Accomplishments
Created Design System from scratch
We needed to work fast and meet the mother-company branding guidelines by using the components, that you can’t edit. Welcome to the corporation world. Solution? Internal library that complement superior Desing System
I am especially proud of introducing “Product Trio meetings” based on Teresa Torres book – Continuous Discovery Habits. Product trio include business, tech and user representatives. On those weekly meetings I presented project owners the latest design changes, we discussed technical details, near priorities and long-term goals.
Kept “Design Decisions” next to right screen or flow. I learned about them from Edward Chechique and since then life is not the same. The author, recommended keeping them in a text file. I expanded them a bit by keeping information about future cases (e.g. add responsiveness ), research outcomes or future tests to run.
Lessons learned
It’s always worth to meet your team in person, especially at early project stage
Deliver small finished pieces (Minimum Viable Functionalities)
User interviews
I didn’t write up the interviews the same day — big mistake. Once other priorities kicked in, it took me two weeks to get back to them. Always leave breaks between interviews. You need time to process what you’ve heard, and that space often brings up new or better questions.
Record all necessary meetings, even the ones meant to last 10 min max.
Prototypes
Do the best job explaining that prototype is not a product
Fill the prototype with data that is likely to users, especially when they are engineers
Regrets
Not being able to create research repository
Not enough real data to confidently shape features — yet. That’s the standard we’re working towards. But that’s always the goal.