skip to content W3C SVG

Design challenges and barriers

When we asked people who work on Science and Research OSS tools to detail the challenges and barriers they have both generally and specifically toward understanding users, usability and design. Many of the general challenges and barriers have an effect on design and usability in the OSS and how users can be better understood. These challenges could be read as requiring a level of proficiency in how complex tech tools are built, how OSS is built and maintained as well as knowledge of the academic systems and science and research practice in these academic systems. This understanding, as well as time and the value of certain types of work (code as more valuable than any other contributions to OSS) can help us understand these challenges.

A widely accepted, inaccurate understanding of design is that it takes a long time, design and usability improvements will change too many things at once, or the OSS will have to refactor

One of the most worrying challenges raised by participants are challenges about the ‘scale’ of design and that design raises ‘false hopes’ for the users of the tool. Presumably, this means the tool will get directly better for specific users immediately. This is less of an innate challenge of design for complex OSS tools and more of a harmful public stereotype of design and designers. It also perpetuates a narrative around poor communication and expectation management on the part of both designers and OSS tool teams on what function design actually performs, and to what scale.

A developer at a data cleaning and transformation OSS tool speaks to these concerns about expectations and scale of design.

“[Our OSS tool] looks like it’s 10-12 years old. Intense technical debt in the UI. So we’ve been very shy, engaging in the larger UX work because that’s going to create false expectations in the communities that we’ll never be able to implement. Because there is so much we can’t do. And if we want to do more, it’s not a small step. But it’s, it’s really you take the front end, and you restart from scratch, and totally refactor, right”

In this next comment from a developer at an OSS microbiome bioinformatics platform, we see OSS projects notice when there are gaps in the expected user experience. The section that references ‘if it’s one user’ or ‘a couple of users’ paired with the assumption that they likely ‘misunderstood’ a part of the tool and that the best course of action is updating or creating new documentation isn’t inherently a bad course of action. Designers would argue that these couple of users are the users that decided to speak up on a usability issue and that there’s likely more users that either have the same problem that don’t voice it and move on with a different tool or solved their problem after battling it for a while. Regardless, the act of creating new documentation and improving the design and usability of these sections will not harm the other action, yet design and usability improvements are seen as complicated and less ideal than documentation that explains around potentially poor design or usability.

“When we run into a situation where users are not interacting with something like as we expected them to, we’re typically you know, if it’s, if it’s one user, you know, maybe it’s just something that was misunderstood if it’s a couple of users, you know, maybe it’s a gap in our documentation. And, you know, maybe it’s kind of clear if you’ve got some context. But you know, there’s some missing contexts that we’re just that we didn’t notice.”

A common usability challenge is that the language or workflows used in the OSS tool might not be the most accessible to the various intended users. Designers may not be aware of specific terminology without the close collaboration with science and research experts.

One of the clearest examples of where designer and scientist/research collaboration is essential to successful usability improvements is found in examples that were repeated by multiple participants across job functions and OSS tool types. Examples of the highly specific nature of science and research OSS projects can be found in their use of terminology and language. A word or term might mean something different to two scientific or research disciplines and might convey a completely different message to people without that specific context knowledge (e.g. when science and research becomes of interest to the general public). We found this is also the same with icons or symbols used in interfaces. Designers and usability experts are able to suggest commonly understood words and symbols for GUI and other interfaces (e.g. the terminal commands and responses back to users) but there is a clear need for a process that involves scientifically trained users to test these suggestions and collaborate with the designers in order to achieve a word, phrase or symbol that best conveys a meaning across various levels of scientific knowledge and expertise. Remember, that many of these OSS tools want to encourage users from other scientific disciplines and simply using the most ‘accurate’ scientific terminology could render the experience unusable for scientists and researchers not yet familiar with that term.

A developer for a Python component composer program summarizes the difficulties in simplifying the complex nature of their tools: “What we’re doing is kind of complicated, in some ways. And we try to make it as simple as possible, and how we encapsulate or abstract the complexity in a way that people can understand.”

A developer working across astronomy OSS tools as well as maintaining their own research OSS into financial data explains the dangers of making assumptions about users knowledge and usage: “Ensuring that we’re not making assumptions in the language that we use, when explaining to, to scientists about about how certain open software works, because, again, because we’re programmers, it can sometimes be a problem that we might make assumptions, like maybe there might be certain terms that they might actually not be aware about.”

A designer working in an university based lab across many Science and Research OSS on fixed term project times explains below the risks involved in communicating niche topics across many different levels of understanding: “Icons and going back to conventions and very niche topics. Some symbols may mean something different to the general public from the very experienced user.”

In the commercial space, employed developers tend to outnumber employed designers in tool teams. In house designers are still growing alongside design agencies that are engaged on a case by case basis for design projects The outnumbering of developers to designers is also largely true of general OSS where there may be between 1-3 designers across well-supported tool with a stable and large user base. In less well supported OSS tools you’ll begin to see less designers present, unless they are themselves users of a tool or have a special interest in the purpose of the OSS tool. We spoke only to designers in the Science and Research space that were employed or paid in some capacity to work on the tools they designed for. The design volunteer contributor space is a complicated one that is under-researched and still growing. Popular design contribution spaces tend to be those that have some kind of design leadership intentionally growing the design contribution effort.

It is therefore not surprising that designers find it difficult to find other designers to work with and gain support from when working on Science and Research OSS tools. Some designers have other role functions that are design supporters, collaborators and advocators but not all designers have access to these allies.

Below a designer working across the Python OSS ecosystem for Science and Research describes that pushing for user needs to be implemented is more manageable when you have another advocate or designer to pair with on design work and to talk through ideas. Finishing with a comment where encouraging the tool teams to ‘stick with’ usability and user centered design is harder solo.

“I know one thing like when I do get to work on projects, with even just one more person in some kind of design, specialty, whatever that may be, like, honestly, even having one other person to bounce things off of has been really helpful. I’ve had others come in for projects, people have done all kinds of creative things to get some more designers in, and I super respect that. But in terms of sticking power, we have not.”

The benefits of having a multi-functional team inclusive of a designer are detailed by a designer working in a university lab across many different OSS tools on a project basis. They described positively their experiences in working collaboratively with their team and the support they received to advocate for users as well as develop their own academic and pedagogical growth.

“We build collaboratively, there is not a single project that is done by one or two people only. It’s always a team effort from different remedies. So it’s not just technological partners. This was also pedagogical and there were academic partners.”

The designer in the university lab was able to push against what the community manager working on a Python based data visualization tool describes below. They begin to describe the danger of homogeneous viewpoints being the dominant ones in tools that are meant to be accessible for many different kinds of users.

“So yeah, I mean, I think, like one thing we don’t talk about but part of this is also like our steering council, it still has a very technical focus. And that helps speak to a farmer, geologist, a physicist …and also all white men in their 40s and 50s. Right. Trying to explain at some point, like why that homogeneity is not good.”

Science and Research OSS tools will always need the views of those described above, the consistently well represented people. But the challenge of widening access to more users and de-prioritising usability design will remain as long as those that remain focussed on the code-based technical work as the most important work.

Embracing change and communication is difficult when your structure of power within the OSS tool is historically those not familiar with design and have rarely seen benefits of design and usability improvements.

We’ve seen evidence from previous sections that the Science and Research OSS tool space struggles to broaden access to roles and functions that are not historically represented or responsible for founding the OSS tools, like design and usability practitioners. An effect mentioned in our research is that when similar kinds of people consistently are responsible for steering the direction of an OSS tool, it means that hesitancy to deviate from processes that have worked previously or feel comfortable in maintaining the status quo are not risked. Design and usability are only as risky when poorly planned. Change appears to be difficult to enact, a designer working across astronomy base OSS tools details a 25 year long process that, while rare, can be a source of friction and resistance to user centered design processes which often seek to challenge established norms and whether they remain relevant in the present.

“Old people who have been doing something a very specific way for 25 years, and they don’t want to change. I haven’t run into too much of that. But it’s an attitude that I definitely see occasionally.”

Designers go to great lengths to establish foundations of communication. Without understanding the perspectives and knowledge that our collaborators have about what design is working on, designers would struggle to effectively communicate specialist and unique terms. Design can be viewed as a facilitative function, balancing the needs of users alongside the configurers of a tool.

“It’s all about communication, finding a common language, because that’s another barrier that I found. And it’s, for me as well, understanding their topic and not, you know, I need to learn every time what they’re talking about.” A designer, who works across multiple OSS tools from a university based lab, speaks to the understanding and shared respect designer and OSS tool builder need to work well together, ensuring that they understand enough from the scientific and research expertise to accurately balance the users needs with the purpose of the tool.

Conclusion

Helping Science and Research projects understand that design and usability work can be small, iterative and doesn’t require a ‘big rehaul/refactor’ process to be undertaken is the biggest impactful recommendation after understanding the challenges and barriers for projects. The key takeaway here is that even if users are having immense difficulty using a tool and are seen to be talking about that difficulty with the tool builders, unless the improvement to usability is seen as ’non trivial’ which it often is not when it comes to design (this is likely because properly scoping design and usability work is difficult without a designer on staff or available) then it will not be done. It will likely be argued as a ‘you need to read the docs more’ or ‘we need to provide training’ to help these users as opposed to making the OSS tool more usable. Many of these challenges come down to communication around time, expectations and scale of a design or usability intervention along with appropriate preparation and rollout time.

Below a designer working on a specific integration to a data cleaning and transformation tool, explains how they learned to adapt their design expectations (high fidelity prototype implementation) to a developer lead implementation that followed user research outcomes.

“High fidelity prototypes were never implemented, as they were designed. So they will, it was also a learning process for me to understand that this open source community will just not just, they just won’t do what the designer tells them to do, they’ll just do it, whatever they want to do. And they may or may not choose to listen to you, they will roughly stick to what outcomes came from, like the research. So users wanted x feature, they will try to build that feature, that feature will not look like the prototypes look, but they will be there.”

For the foreseeable future, designers will need to adjust their expectations of what design and usability looks like in Science and Research OSS. These OSS tools are not yet ready to match the commercial technology world in how design and usability is valued and trusted. Understanding what can be achieved within these complicated OSS systems is a good first step in making sure users are centered in these tools. If a level of design integration is able to be maintained, effort can then be invested in design becoming normalized and having better established positions for advocacy within these tool teams along with higher numbers of designers practicing in the Science and Research OSS tool space.