Design artifacts eventually need to be updated, so always check how old they are
Sometimes, starting a project redesign is like opening a fridge and checking what’s still good. You’ll be given design artifacts, research outputs, and other documents from the last time someone worked on it.
Before you start working with these resources, ask yourself the same question you would finding dodgy ingredients in the back of the fridge: is this still good?
Because, believe it or not, design artifacts (like personas) can expire.
The dangers of working with expired design artifacts
We all know that eating expired food can make you sick or hospitalize you, but what’s the danger of working with expired research?
The main danger is that you design and build something on faulty assumptions, which results in products no one uses. For example, one of the most significant project failures I’ve seen (a $1 million initiative) was based on the faulty assumption that Spanish-speaking users would prioritize using a website over other possible options (like in-office or over-the-phone visits).
However, it doesn’t have to be that large scale: perhaps the user research was suitable for the project goal at hand, but then the project’s focus shifted over time. I’ve seen project goals documents obsolete after six months, so it shouldn’t be surprising that user research could also become obsolete.
Personas tend to be the most significant example of this. Nielsen Norman talks about two major changes that result in personas needing to be updated, which can happen more often than you think.
- Changes in your business and technology
- Changes in user demographics and interaction patterns
These changes can come from several factors you might not be aware of. For example, a competitor might disrupt the industry; your Analytics might show an untapped user group or your business could have pivoted.
Usually, this isn’t a big deal when you have the resources. But, like tossing everything that looks dodgy in the fridge, you could spend some resources creating new or updated personas.
But when things are tight, as they might be in a recession, this becomes an issue. You might need to justify your reasons to your team, and you might need to figure out some cheaper ways to ensure things are still working if your research outputs are near their expiration date.
In that case, how should you find a solution to this problem? Here are a few things that you should consider.
Build in expiration dates (and versioning) for design artifacts
I can’t tell you how many times I’ve looked at the ‘final’ version of something only to be told that it’s not the latest version.
Keeping track of version control is tricky and becomes even more challenging after a few months. Would you drink a mystery carton of milk with no expiration date?
If not, why trust user research when you’re not even sure when it was created?
Fortunately, Tomer Sharon, head of UX Research at Goldman Sachs, developed a solution to this problem with his one-page research plan template for stakeholders. I use the whole template sparingly, but I often use the first sections in many design documents.
Three sections matter the most:
- Who’s it by: Which team member created this thing, and how do I contact them (by e-mail)?
- Last updated: When was the last update to this piece approved?
- Stakeholders: Who approved these changes?
Having these three sections helps in several critical ways. First, rather than searching through e-mails or meeting notes to find who developed what, it gives you a point of contact to ask about the design artifact directly.
Second, it tells you not the date it was last worked on but the date of any last significant changes. If the “Last Updated,” for example, was ten years ago, then it’s probably safe to assume that you need to update the design artifact.
Lastly, and most importantly, it protects you from any arguments from the team. For example, if your team is angry six months later about what was designed, adding this to your documents helps show that something was approved and when to avoid any messy arguments.
Each time the stakeholders make changes and approve them, they (or, more likely, you) add their name to the “stakeholders” section and update the “Last Updated” date.
I would say that design artifacts should be updated every 3–4 years at the latest, although there are fields where they might need to be sooner.
However, a lot of the time, you’re updating a persona (or design artifact) instead of re-doing it. This is a crucial distinction because it allows us to make changes with fewer resources than you might realize.
If you need to update a design artifact, you often need to start with just one person: a Subject Matter Expert (SME).
Talking with Subject Matter Experts provides a good reality check
I’ve worked with Subject Matter Experts (SMEs) for most of my UX career, so I’m familiar with what they can and can’t do. Validating old research is something that they’re incredibly good at.
Why? SMEs tend to have a lot of experience, meaning they’ve lived and worked through several ‘shifts’ in their work. If they’re old enough, many of them might have shifted from Waterfall to Agile environments.
They’re an excellent 5-minute reality check to see if things are just a little outdated or if you need to rebuild a persona completely.
SMEs can tell you if the changes require a little tweaking to personas or fundamentally change who was visiting your site or how it’s being used. Of course, they will be biased, so this can’t serve as a full-blown study. However, this can help you make your case for additional user research resources from your team to update things.
SMEs don’t always have all the answers. Finding points of contact, other people to talk with, and more can provide a clearer picture. However, that’s fine if you get a complete picture later. It’s just better to take these actions early rather than relying on the last safety net that you have: your users.
Your users are a safety net for expired design artifacts (that you shouldn’t rely on)
Fortunately, even if you miss the expired research output warnings, there’s always one last safety net we can rely on: user testing and interviews.
Users will let you know if your understanding needs to be revised or if you need to include crucial steps. This ensures that your product can still meet user needs.
Unfortunately, relying on this safety net means you have a lot of catch-up work to do. In addition to reporting your user findings and making design recommendations/changes, you would also have to find time to update your user research artifacts in the middle of the sprint.
So rather than waiting until you can test with users (and find out that your understanding of them has expired), it’s better to be proactive and check how old your understanding of a subject might be.
After all, few people want to find out the milk is spoiled after you start cooking with it.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process