Do the design digging
I’ve recently been chatting with a former colleague and friend who is now working on a product I used to.
They shared some of the challenges the team was working through.
What was interesting was that some of challenges were things we’d worked through way back in 2019. Classic sort of “know your API and data” type issues every good interaction or UX designer learns.
Things that meant you have to make sure your designs are based on real data. The screaming capitals style of real data.
What was interesting was that there wasn’t an active part of the team telling and teaching what we’d found out in 2019.
Those lessons were no longer being carried across. And where we’d documented things, those lessons have been archived and no longer being used.
There are times when an outside perspective is useful. To ask questions like “why does this api work like that?”. But a good team should be carrying forward that information and stories. Even between and after suppliers or other teams come and go.
Because something didn’t work before, or there were limitations, doesn’t mean things can’t change. When looking at data and past decisions, you get to rethink or challenge things for the future. To tell the next chapter of how things work.
But when the stories are no longer told, we waste money and time learning what we could have already known. Our research and design doesn’t get past the “so what?”. Or it does a lot later than it could have done.
There’s no replacement for learning by doing. But it’s much more fun and valuable to learn new things. Rather than repeating the battles and lessons of the past.
A research and design team that forgets or fails to dig around what’s been learnt before is doomed to repeat the learnings.
How do we avoid this? A good design process starts by digging around and learning what’s been learnt before. And what’s been done. In the enthusiasm for change or design it can be easily forgotten. Every designer has done this. And will do it again no doubt.
But reach out to those before. Or those who’ve done similar. Particularly on a product or service with many dependencies and history.
Make it easy to record and share your thinking. Make it easy to find your thinking.
Make those that decide things aware that when they archive or remove the lessons and learning of the past they’ll be paying to repeat many of them in the future.
If you can influence how teams are put together. Make sure your team blends those that stick around and those that leave. Be they contractors, suppliers etc. Make sure you keep a thread.
But most of all. Do the design digging before you repeat the broken designs of the past.