Author: Serena Cooper

Thinking About Digital Design: Why It Matters for Your Academic Research Project

Posted on by Serena Cooper

Guest Post

Research IT work with a number of external consultants to provide expertise in user experience (UX) and design. We often recommend having these inputs early on in a project to provide clarity and focus, and the assurance that we will be delivering what is needed.  This post is by one of those consultants, Dr Stu Church. Stu is a former academic and current external consultant who works closely with Research IT to provide design thinking advice and support (also referred to as UX) across multiple academic projects.

Dr Stu Church  (stuartc@pureusability.co.uk)

Spring 2025

Academic research projects, regardless of discipline, increasingly involve creating bespoke digital products or tools. These tools can range from specific data collection apps, to digital archives of artefacts, or even interactive tools for querying and visualising complex data.

With fixed grant funding, the big question is always: how do we make the most of the money we have to ensure that our digital tools are a success? We want the digital outputs of our research to be genuinely useful and easy for people to use, and we need to develop them efficiently. This is where design thinking, particularly User-Centred Design (UCD), comes in. It’s a way of thinking and working that can help produce focused, well-designed digital tools and make the best use of your budget.

What’s the Problem with ‘Just Build It’?

It’s tempting to think of creating a digital tool as merely a construction task (“Let’s build a website!”). However, the actual coding and development is usually the most expensive and time-consuming part of creating digital products. So, before starting to write code it’s important to be confident that what you’re planning to build is really what’s needed – both for the project’s academic goals and for the people who will eventually use it.

Rushing into development without this understanding risks:

  • Building the wrong thing. We might create something that doesn’t actually solve the intended problem or meet a real user need. This can lessen the impact of your research, or even hinder it if the tool is essential for data collection.
  • Costly changes later. Making significant changes once coding has started can rapidly consume time and money. It’s far more cost-effective to invest time upfront understanding the problem and exploring solutions through prototypes.
  • Wasting the budget. Building something that isn’t right or isn’t used wastes precious grant money.
  • Poor usability. If a tool isn’t intuitive or appealing, people won’t engage with it. This limits its impact and could even jeopardise your academic objectives.
  • Trying to do too much. Packing in too many features (‘featuritis’) can lead to complexity, dilute focus, and stretch resources.
  • Project frustration: Discovering fundamental issues late in the development cycle can cause delays and frustration, potentially meaning less gets delivered than planned.

Fortunately, ‘Design Thinking’ offers ways to approach digital development that minimise these risks.

Design Thinking & User-Centred Design (UCD)

At its core, Design Thinking is about deeply understanding the people who will use the thing you create and the context in which they use it. It’s also important to involve them in the design process (that’s the ‘User-Centred’ part). 

It’s not just about how something looks; it’s fundamentally about making something work well for its intended users in their context. Your digital tool might be for the general public, other academics, specialist practitioners, policymakers, or research participants. These groups have vastly different needs, technical skills, knowledge, and expectations. Without understanding these, designing something truly effective is a shot in the dark.

One popular process that encapsulates design thinking is the ‘Double Diamond’ from the Design Council (https://www.designcouncil.org.uk/our-resources/framework-for-innovation/). The Double Diamond visually separates the design process into understanding the ‘problem space’ and then exploring the ‘solution space’:

The Double Diamond by the Design Council is licensed under a CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/).


The main aim of the first diamond (Discover + Define; aka ‘Build the right thing’) is to explore the problem space and define the problem. Discovery usually involves stakeholder and user research (such as interviews or surveys) followed by synthesis of the results to produce clearly articulated and prioritised problems/opportunities. 

The second diamond (Develop + Deliver; aka ‘Build the thing right’) illustrates the need to explore the range of possible solutions and then iteratively test and refine them. Initial design ideas are usually mocked up and tested as prototypes that can be easily discarded or modified at minimal cost, eventually converging on the one that hits the sweet spot of meeting the needs of both the project and the users, while also being technically feasible. 

Even if you think you already know what’s needed, making time for (at least) a rapid  discovery to clarify your thinking and validate your assumptions from different perspectives is incredibly valuable. It ensures you’re tackling a genuine user need and building on solid foundations.

Design Research: Pragmatic, Not Perfect

Design research is a different beast from traditional academic research. While it can be just as rigorous, it’s usually more pragmatic and action-oriented. The goal is typically to do just enough research to gain the confidence needed to move forward with a particular design or approach.

It’s also important to recognise that there are different, sometimes competing, goals at play:

  • Academic goals. What new knowledge or understanding does the project (and the tool) contribute?
  • Project goals. What specific function does the tool need to perform for the research (e.g. reliably collect specific data)?
  • Administrative goals. Meeting funder requirements and milestones.
  • User goals. Is the tool or product easy and perhaps even enjoyable to use? Does it help users achieve their objectives?

Design thinking provides a framework for navigating and balancing these different needs as it encourages us to explore these issues, then narrow them down to be quite specific about the nature of the tool we are designing, and who it is for. 

Practical Design Thinking Takeaways for Your Project

Here are some practical takeaways to help you incorporate design thinking in your project:

  1. Start Early. Consider design and development needs before submitting the grant. Talk to support teams (like Research IT or similar digital specialists at your institution) about your ideas early on. Budgeting around 10-25% of the digital development cost for design thinking activities (discovery, prototyping, testing) is a reasonable starting point, though this depends on the project’s complexity.
  2. Embrace the uncertainty.  Be open during the design process. It’s an iterative journey of exploration and discovery, not always a linear path.  
  3. Don’t be distracted from the real problem. It can be tempting to jump straight to a particular solution. However, deeply understanding the real problem you’re solving and focussing on it can save significant time later; there are many potential solutions to a given problem, and you may discover that features you initially thought were essential aren’t actually needed.
  4. Don’t assume your users are like you.  This is a classic design mantra for a reason. Avoid assuming users share your level of expertise, motivation, or context. They almost certainly do not.
  5. Prototype early & often. Use tools (from simple hand drawn sketches, to prototyping tools like Figma (https://www.figma.com) or PenPot (https://penpot.app), or even AI tools like Bolt (https://bolt.new) or Lovable (https://lovable.dev)) to create tangible representations of your ideas quickly. 
  6. Test your prototypes. Get feedback on your prototypes from real users, but be clear what you’re testing – Is it the content? A specific workflow? The visual design?  Also, don’t just ask people what they think. Instead, try to get them to interact with prototype content in the context of a specific, real-world scenario.  You’ll get better feedback this way.
  7. Iterate. Your first design idea is rarely the final or best one. Use feedback to refine and improve.
  8. Keep it simple. Less is often more. Avoid unnecessary complexity and focus on doing the core things well.
  9. Get support if you need it. It’s very helpful if you can familiarise yourself with basic design processes and methods. However, digital projects are inevitably more complicated and ‘messy’ than they often appear at first sight. Research IT can help you to navigate these complexities.

In summary, by embracing design thinking and UCD principles, you can significantly increase the probability that your research project’s digital outputs will be useful, usable, and impactful, while making the best use of your valuable grant funding.

Written by Dr Stu Church   https://www.pureusability.co.uk/

If you’d like to find out more about developing digital tools for your research project, please visit the Research IT website (https://www.bristol.ac.uk/research-it/) and contact Research-IT@bristol.ac.uk.

Celebrating the women in our team – Serena Cooper

Posted on by Serena Cooper

How team manager Serena Cooper ended up in IT and her thoughts on how we can support our female colleagues.

I started with the Research IT team in May 2020 during lockdown. I love this job as it brings together my background in research with my experience managing IT teams  as well as my desire to use IT to do good.  I am proud to say I am a feminist, a strong independent woman who has had some excellent role models and advocates. My journey into IT was the long way round with a bit of avoidance along the way.

I grew up surrounded by computing, my father was a computer engineer and my mother a programmer when computers filled rooms and code was made by punching holes in bits of paper. Programming and hardware were normal dinner time conversation and my two brothers absorbed it like  sponges. I, on the other hand, found it boring and lacking in creativity. After briefly considering becoming a scientific illustrator, I pursued a career in biochemistry. I ended up in the computationally heavy area of protein X-ray crystallography and, although I worked alongside the CCP4 Team at Daresbury Labs, I was a user of IT and not a contributor.

X-ray crystallography was wonderfully female discipline not just with its big-hitter heroes like Dorothy Hodgkin, Olga Kennard and Rosalind Franklin but also the continued strong presence of women and how normal and expected that was. It was a stark contrast to the host chemistry department where even in the mid-90s there was not a single female lecturer. I always remember a colleague contemplating a temporary lecturer post being worried she would get all the pastural work and didn’t want the feeling of pressure of being the “first one”.   That particular department is doing slightly better, a quick look at their website now and I see they have six female lecturers!

Messing around with high energy X-rays, liquid nitrogen and high-end graphics was fun, but the day-to-day reality was of pipetting small amounts of liquids in a damp cold-room, of lack of results, and of a strong personal feeling of being an imposter.  So, in a turn to the side, I joined the Research Councils as a portfolio manager, and it is here through various good managers I lost my imposter syndrome and made the slow slide into IT.

I was recognised by the formidable Jo Booth Davey as someone who could articulate user needs in a way the “techies” understood.  All those years of being in a vaguely IT literate environment had paid off! Jo was EPSRC’s software development lead and, like a great general, inspired not a lfear but much loyalty, said it as it was, took no nonsense and got things done. She was a massive influence on me and a fantastic advocate and mentor, not least because I decided I liked the look of what she did and wanted her job! Five years later when she retired it became a reality.

Whilst my particular journey has included a lot of fantastic female colleagues, IT is still male dominated.  As I have moved along, I try to be a good peer and mentor and give back the encouragement, advocacy and support I received and still receive. I have also had, and taken, opportunities for female-centred training and support and would encourage others to do the same.

Through those past advocates I have gained the confidence to speak up when I see unfairness or issues that need to be addressed.  IT will only change with visible role models, if recruitment is less to a type and support given to those entering teams as “the first”.  Those who can must be supportive of those who don’t – yet – have confidence, and highlight all the undesirable behaviours or situations for the continuing benefit of all.

 

 

 

An introduction to Research IT at the University of Bristol

Posted on by Serena Cooper

Research IT at the University of Bristol covers a wide range of subject areas and a breadth of scope and technology.  This post is a general introduction. Future posts will cover our projects, aspects of our work, and areas around Research IT in more detail. We are hoping to have some guest posts from those who have used our services.

I took over management of the team in May 2020 and have been truly amazed at the variety of projects they are working on. For such a small team (3 developers, a sys admin and a relationship manager) they manage to work on quite a few projects. We worked on 24 different projects in 2020 and had conversations with over 80 academics about their research and how we could help.

I like a chart so have done some analysis on the university faculties we work with. As you can see, we have an almost equal spread of projects shared between Health Sciences and the Arts. I don’t know all the reasons for this distribution, but some of it may be down to word of mouth and ongoing relationships with some researchers. We are however able to, and very happy to work with researchers in any discipline.

projects are in Health sciences, 38% in Arts, 8% each in science and Engineering and 4% social sciences.
pie chart of Research IT’s active projects in 2020 by faculty

The topics covered in these projects include cataloguing and visualisation of data from historical manuscripts, producing tools to help with earthquake and drought management, and creating platforms for clinical trials of online mental health treatments and for sharing biological data sets.

The size of projects can vary from just a few days of consultancy, through to significant developments of many months and ongoing work for the years of the research project.

We maintain a pipeline of work and are always happy to hear about your research project to see if we can help. We are currently really interested in working on projects with elements of machine learning, AI,  visualisation and virtual reality.

Further details on some of our projects can be found on our website https://www.bristol.ac.uk/research-it/examples-of-work/