In yesterday's email, I wrote about a calendar that works with a keyboard but still makes finding an appointment difficult.
I keep wondering how early we could have noticed that.
When we designed it, the booking screen showed a neat calendar with available appointments this week. Everyone loved that, they thought it was useful. So we all agreed it looked good and we started working on it.
But we didn't stop to consider what happens when the next appointment is six weeks away. If the design doesn't clearly cover that use case, someone still has to work it out. Often, that someone is the user trying to book the appointment. That's the worst case scenario, because the entire thing has to be rethought now. It's a lot of rework.
The polished design can make a decision look more settled than it is. I've mistaken that polish for completeness myself countless times.
After a few of these shenanigans, I decided I'd rather see an unfinished designs with open questions attached to them, which the team can discuss. We can clarify what patients need, design a solution and get dev consent before we commit to building it.
This visibility matters more to me now than an eye-catching design.
It's also clear to me that we won't be able to fix and cover everything in advance. There will still be some questions that come up later and those will need a working prototype or feedback from users. But at least calling out what we can anticipate helps everyone discuss the issues instead of discovering them close to the release date.
I trust a handover more when it tells me what's still uncertain. It's funny and ironic that sometimes a design where people have a lower level of confidence that it covers everything gives you more confidence to go forward with it.
I guess it's because it gives people something more useful than the impression that everything was decided.