This is the first in a short series of posts looking at how Dimensions Research Strategy came together – from the earliest conversations with our development partners through to the choices that are shaping the product.

Dimensions Research Strategy is Digital Science’s new agentic AI platform for institutional research intelligence — delivering strategic expertise across every dimension that matters, on demand, for every institution. 

But anything built to deliver strategic expertise needs to be grounded in the real-world workflows and challenges of the people who are going to be using it. Which meant starting with conversations — long, sometimes messy ones — with the analysts, research office teams, and strategic leaders who spend their working lives trying to answer questions their existing tools were never quite built to handle. 

In this first blog of the series, we speak to Ross Andrews, Director of Design at Digital Science, who led much of that early discovery work, running structured sessions with our development partners to understand not just what people wanted the product to do, but how they were currently getting by without it. We sat down with him to talk through what that process surfaced, how it shaped the product, and what it takes to get people to trust an AI-supported answer in the first place.

Hi Ross! What was it that drew you to this line of work, and what do you value about it?

I come from an editorial design background. I worked in magazine publishing for 26 years and never once spoke to a reader in all that time. Discovering UX design was realising it was about actually talking to and understanding people, then translating that into solutions, and something clicked with the way my brain works. I like putting disparate things together – engineering requirements, product requirements, commercial strategy, but first and foremost our users’ needs – and building something that works effortlessly for them.

I love being the dumbest person in the room. I’m not from a bibliometrics background, so I get to ask what seem like stupid questions to people, and it’s exciting to hear them talk about the work they do and help them do it

And how did we choose who else should be in that room when we were engaging with potential development partners?

We wanted breadth – across the UK, US, Europe, Australia and New Zealand. We wanted people who were analytically sophisticated – though that doesn’t necessarily mean technologically sophisticated. We also wanted a balance of people leading with AI and new tooling, and people doing it more traditionally, so we could serve both. And we wanted people who’d give us challenging, candid feedback. I start every session by saying: this isn’t a test of you, please be honest, I want to learn. 

What kinds of questions were institutions asking of their data or existing tools that they couldn’t get a straight answer to? Were there frustrations or themes that came up repeatedly?

A lot of the partners were struggling with the same things, even if they didn’t always express them the same way – when you look into it, it’s the same problem just framed slightly differently. The most common one was: how do we really compare ourselves to our peers on a specific topic, not just overall. That’s difficult for a lot of reasons; it relies on a lot of back-and-forthing, quite messy collaborative working.

Then, who do we compare with? How do we actually compare across different institutions? And how do we show societal and real-world impact beyond just citation counts? That gets particularly interesting in fields like the humanities or the arts, where citation count doesn’t really display impact at all.

There’s a quote from one of the partners on that citation point that I love. When a senior person asks an analyst to do some work on impact, they’re often asking for citation count when they actually mean impact – and the problem is, that’s like trying to find out what the best restaurant in a train station or an airport is by foot traffic alone. McDonald’s will always win! But that doesn’t help you if you’re looking for who makes the best artisanal sandwiches.

You don’t want to just find the lowest-hanging piece of fruit – or the lowest-hanging burger, in this case, I suppose. 

Pulling an answer together often means working across systems that were never designed to fit. Can you give us some insight into what that work looks like day to day?

The most common thing you learn when you sit down and do this kind of task analysis properly is that “workflow” is probably too strong a word for what most institutions have. It can be quite a mess! It can take days, weeks, months just to get to the point where you can actually run the analysis. You might get a single line in an email from someone senior – “please can you tell me what our impact is in this topic” – and it seems like a simple request, but it definitely isn’t.

Some partners rely on a default set of peers, established at some point in the past, and in a lot of cases they don’t know when it was last reviewed, or who put it together. 

I’ve yet to speak to an institutional team who has any kind of pre-defined brief for this. And once you’ve got the brief nailed down, pulling data together from sources that were never designed to line up is genuinely hard.

Can you give me an example of partner feedback that changed or evolved the way we built or approached a piece of functionality?

I was able to share genuine reports with development partners, built from prompts they’d submitted themselves. One partner invested an awful lot of time – must have been hours – going through the PDF I sent and adding direct feedback onto it.  What I desperately want to do when people invest that much is to be able to close that loop and say thank you, we’ve actioned it. In this case, I was able to go back, and say: because of these two main points you raised, we’ve directly made these two changes – go and try it now, you’ll see they’re already done. That’s exciting for partners too, because they can see their feedback actively shape something, in real time, very quickly.

Many people are, quite reasonably, sceptical of the results given by AI. What does it take for them to trust and defend those results – and how did that shape what we built?

Even partners already using AI told us they’d spend a couple of days beforehand cleaning a dataset, just so they could hand it to the model with confidence it wouldn’t hallucinate – and then spend significant time afterwards verifying everything it produced. A very frustrating process to get from the original brief to something usable and reliable.

That started to frame the problem differently for us: not how do we save people time, but how might we enable people to trust the output without having to redo the work themselves. Being able to show the provenance of data, how it’s been interpreted, what the caveats are – the more honest we can be about that, the better. And giving people an easy bridge to take a query out of the platform and check it somewhere else, rather than having to manually recreate things, makes people’s lives easier when they do want to verify.

There’s an idea we keep coming back to – appropriate trust. I’m old enough to remember when sat nav came out and people were driving into rivers because they had an inappropriate level of trust in the system: it said turn right, they turned right, there was a river, and they thought “well, that must be right, I’ll keep going.” 

With AI platforms we’re looking at enabling people to trust the platform exactly the right amount – not sceptical of it, but understanding its limitations, because we’ve communicated those limitations openly and honestly. 

It has to initially be a bit like building a relationship with a person. Early on, you’re testing what each other says, pushing back on it a bit. Ideally you eventually get to a position of trust. We’re moving at the moment from the idea of an assistant to the idea of a thought partner, so that relationship becomes more pivotal and more complicated. 

I think it’s what I’ve always loved about product design across the various guises I’ve done it. I love doing the work I do because I’m working on products where people build a relationship with them. It’s a long-term relationship, and I think looking at how you build that – and particularly with AI systems, how you build that level of trust – that’s not a one-shot thing. It’s something you build over time with the people using it. I think that’s a lovely way to work. 

There’s a nice sort of twinning here in terms of us very much building up that relationship of trust with our partners at the same time as we’re building something that’s trying to build a relationship of trust with a user.

I hadn’t thought about that, but that’s a lovely parallel. That is a lovely parallel.

Next in this series: a look at the product decisions themselves, from the team who turned this partner feedback into what’s now live. 

Interested in what Dimensions Research Strategy can do for your institution? Find out more