Working together to design better with data
Here are 6 steps from a UX designers perspective that I learnt from working within this team and specifically with data scientists.
During my last year at the BBC, working in the Systems and Service Design team, I began to work on projects that involved data. More specifically, how we could use production, content, and audience data to help commissioners and content creators create better more relevant content.
In my experience, the standard product team includes developers, designers, and product people. However, in this new team, we had data people too. This included data scientists and data engineers.
Initially, I thought working with data scientists would be the same as working with engineers; that their roles were similar to developers except they also created models from data. After stumbling a bit, I learnt that this was not the case. It wasn’t just me who found this, and it took me and the team a little while to acknowledge the way we all needed to work. We spent some time defining roles and learning what we could do to work better together.
I’d also like to acknowledge that the experiences I’ve listed below were all achieved during the pandemic and therefore remotely. This may have affected our ability to work closer as a team, and during ‘normal’ work time we would’ve been able to have more casual check-ins.
Understanding roles and ways of working
Data scientists work in a similar way to product designers. They’re also creative problem solvers, although instead of post-it notes, wireframes and mind maps they use data and spreadsheets. In the same way that UX designers need time to go away and ideate, sketch and create concepts; data scientists need time to explore and experiment with the data.
One of the first things a colleague said to me when I started working on this project was; “Make sure you have the data before designing anything. Test it with real data.” Early on in a project, I still had no ‘real’ data to put into my designs, as the DS’s were still busy experimenting. I had an idea of what the data would look like and kept talking to product managers and data scientists about the concepts. Everyone was in agreement with what the designs should look like once the data arrived. However, when it did finally arrive, of course, it looked completely different. The pretty pixel-perfect graphs I had created looked cluttered and misleading. There were things that we couldn’t have realised until we’d put in real data. This meant that some very quick decisions had to be made in order to release something that made sense.
The learning for me here was that data scientists need time to create things, and that we needed to schedule this into our future roadmaps.
From this, I learnt that firstly, I should’ve listened to my colleague. Secondly, that the data team also need time to develop and build models, and this was something we needed to allow the Data Scientists in the future.
Understand your data before designing with it
In the most recent project, I was lucky enough to have a senior researcher join me on the team. She suggested that in order to understand the model, we needed to break it down into three sections
- Where we were getting the data from. What was the source? How often was the data generated? What was collected?
- What we were able to measure from it. What were the attributes that we got out of it? How flexible were these?
- What were the insights generated? How would these insights look? Can you give an example? What does the user get as the final result/page?
These may seem like simple questions, but there were times when there were multiple models combining and forming one output. This could sometimes get really complicated. I would constantly think to myself ‘if I can’t understand it, how can I explain this to the user?’. Don’t be afraid to ask stupid questions and to constantly come back to these questions too.
Ask everyone to sketch it out
There were multiple times during the past year, where we were presented with a new data model and had to then figure out what the model could produce for the users, and then how it would look and function. I ended up assuming a lot and getting it wrong before finally getting it right. One really helpful way of avoiding this back and forth was to get everybody involved in creating the model to sketch it out. I would ask for a simple sketch on how they see the tool looking at the end as well as a few more questions to prompt their sketch:
Asking questions like:
- Which information is flexible?
- What is an example of an input?
- What options does the user have, which things can they select?
- What will the user see when they see the final result?
- What data is available for the user to see?
You might have to do this a few times, go back and forth until you have a clear idea of what is really possible. If you already have an understanding of what it might look like, you could sketch something yourself and ask them if that looks right. Not being afraid to be wrong at this stage is an important skill — the aim is to get to an understanding of what their model is doing. It’s our job as communicators to find the useful things that the model produces and communicate that to the user in the most efficient way.
Get visual — show what’s inside that burrito!
One analogy that I read about (somewhere on Medium) was about a silver burrito. Let’s say, everyone on the team agrees that they want a burrito for lunch. On the outside it looks the same, it’s a parcel of deliciousness wrapped in silver foil. However, they will all have different ideas of what is in the middle.
This can be the same when designing, (well, anything — this is a great analogy), but in this case graphs for data. There are a lot of assumptions about how it will look and what data will actually be shown. You might think you’ve agreed what the graph is going to show, but by bringing something visual to the table, you stop everyone from having their own interpretation and start working on the same thing.
It’s the role of the designer to create something visual and to communicate the data visually. You may start out with something completely incorrect, but doing this and sharing it allows you to have a better understanding of what the correct thing is.
Share your sketches, concepts and designs as early as possible, with everyone involved.
I found this the most useful when presenting concepts that are quite far into the future but also for features or changes just around the corner. By including everyone in the concept stage, I found that team members were able to have their say from the beginning. This was a great way to get everyone on board with the ideas, and for the team to feel that they’ve contributed to the finished product.
- It allowed engineers to see what they might be building, and to mention any concerns,
- it meant data scientists had an idea of what might need to be included in any model changes or future models, flag misinterpretations, areas of confusion and highlight things that wouldn’t be possible
- it allowed product managers to predict future resourcing decisions and lastly,
- it meant that I could ask any questions I had to everyone all at once.
I found these sessions were especially useful when creating concepts for models which aren’t ready yet. It meant that we were all working at the same point and aligning our thinking by knowing what the other part of the team was working on.
I started an optional Design/Data/Dev meeting which ran once every two weeks for 45 minutes for the team. It was a very informal discussion about anything related to UX. I was always surprised at how many people would show up, I’d like to think they found value in having open discussions about the concepts and things we were building together. It was an opportunity for the team to have their say.
During these sessions, I would often screen share my designs, but they would look quite messy — with questions all over them. Questions that I would go through and ask the relevant people about. I hope this messy approach allowed everyone in the meeting to feel that the concepts were changeable and still in progress instead of a polished design that they couldn’t critique.
Relate back to your user needs
The above points have been about understanding the data and models, however, this is only the part of the process. The next stage is, of course, relating back to your user needs and seeing what data is applicable, what the best method of showing that is and to get feedback from your users as often as you can. This can sometimes be an easy step to miss if you’re focusing solely on what data is available.
I’ve seen a lot of dashboards that contain every possible piece of data recorded on it. I’ve spoken to the users who’ve tried to use these and struggled. They show too much information that it’s overwhelming and complicated to use. Just because you have the data, doesn’t mean you have to show it. A key skill in a designer is the ability to edit and to choose the most relevant and useful information.
I hope this was useful in some way, feel free to get in touch if you have any more questions.
Thank you to Alice Gregory and Megan Stodel for proofreading this for me and for being wonderful colleagues to work with.
