Design for real data
It’s vital to design for real data.
If you don’t, your service or product design is artwork. And your design will not be made. Even if it tests well. Because it can’t be.
When designing a service that includes data from a database you will have to design around the quality of data. And any business process rules for that data.
Designing for real data is vital when you have to accommodate data from other sources or APIs. Especially ones not designed for being shown to your users.
When tackling a database or APIs you need to ask:
- what’s the source of data?
- what’s the original purpose of that data?
- who looks after the database?
- how is it kept up to date?
- how consistent is that data?
- what’s the exact format of data?
- what’s the most (length, number of items etc.) something can be? What’s the least?
- what are some real examples you could use?
Understanding the real shape of data will let you ask why. Stretch your design. And potentially create moments to really transform services.
A colleague Sam recently finished a project rethinking data collection. Part of her process she looked at previous submissions. As she did, she could point to failings and data quality issues. Which provided real evidence for change.
You can either design for data so good it’ll never exist. Or accommodate what a user will really experience.
It’s hard work. But it’s where the work really is.
Do the hard work. Design for real data.