Ideas from UX London

What?

UX London was a conference on user experience design, i.e. how we can design products/services/systems for users to have meaningful and pleasant experiences using them. The incentive was that within ARC, we have little experience in designing our products and with an increasing number of web projects which are not just intended for internal/researcher-only usage, gaining knowledge of how to design well is becoming more important. Granted, it won’t be the same for us as it is for regular for-profit companies, but there are still things to be learned and applied, as I touch on in this article. It will be something of a whistlestop tour

Product Design

Ideas about designing a thing (website, tangible object, app, system, possibly a service, etc).

• There’s a running theme of if you can see/reveal/identify a thing, then you can change it (for the better). This is not a new idea; I’m sure we’ve all heard “the first step is recognising [the] problem” or something similar in a range of contexts. This is not to say we should find problems as much as possible, but rather to try identify the problem with the most impact on what we’re aiming to achieve.
• It’s important to know your target audience as you can’t create something for absolutely everyone without losing specialisation/individuality/usp. Also, small changes can make a large difference (especially if you know your audience is or is not). A product designed just for researchers to interact with is bound to be slightly different to one designed for a general populace member, which differs from one designed for a child, and so on.
• A tool/technique mentioned, which could be beneficial for ARC to implement due to our size and range of subdivisions, is Zenko Mapping. This is a retro tool to help identify systemic problems and thus support interventions.
• There’s the European Accessibility Compliance Act 2025, which we should try to follow where possible, even if we’re not producing commercial products (often).
  
• UX doesn’t (yet) have standards of diligence but there are (EU) laws which can act as guidelines for digital products and services
• Whilst AI is the hot and controversial topic in the zeitgeist, collaboration with AI in design & development flows can help speed up the process quite a lot, we’re finding new and imaginative ways to do this. One such tool is tldraw, which, personally, I could see being used by people with little design or web familiarity who need or want a quick mockup, but also by those who have more experience and just want to bring a sketch to life quickly as a proof of concept.

Design Systems

This is distinct from Systems Design (the design of systems), and refers to the commonality of design elements used within a system – think about how UCL websites have the same look and feel even if they’re slightly different, that’s the design system at work.

• A design system is a comprehensive set of standards, documentation, and reusable components that guide the development of digital products within an organisation. We have one at UCL, it’s why all UCL branded websites and slides etc look the same. In ARC, we don’t tend to adhere to this design system as we do things on a project basis, and most of those tend to be small or don’t have a large UI focus. UCL is currently undergoing a refurb of the design system so it’s more modern and (I think) more usable across digital products, so in future, perhaps we can use this to some degree.
• Designers and developers should collaborate. Often in the corporate sector, they don’t do this; the designer merely hands off to the dev team and they have to create it. We’re already ahead on this front since most of the time, the design element is covered by a developer anyway, but it’s still good to bear this in mind in situations where there is someone who is more design-focussed (though we have the advantage of the odds being that they are also a developer, so the typical pitfalls of not understanding what’s feasible with code are less likely to occur). Sometimes, this does still happen and it’s important that we work together to find a suitable compromise.
• OpenUI is a resource that collates and compares how various design systems (eg. Bootstrap, Material UI, AtlasKit) have extended and styled basic web UI components (eg. alerts, tooltips, modals). It also allows developers to propose how we could improve the base component so that we don’t need to rely on an individual design system to have the improved version, on the basis that most, if not all, of the design systems are making the same changes to the component to make it more appealing/usable. For example, when was the last time you went on a modern website and saw a basic run-of-the-mill button? Probably never since the base component doesn’t really mesh with modern aesthetics and it’s super easy to style a button with or without using a design system (that’s not to say there’s no improvement to be had). The end goal is a global design system that’s still easily customisable, but without having to rely on an extra package, it’s just part of the web component. The nice thing about OpenUI is it’s got an inside line to W3C, who set the standards for the web, so the likelihood of OpenUI succeeding in developing a standard process for how we can propose these improvements and implement them is reasonably high.

 

TLDR

Even though the conference was aimed at designers in a more corporate setting, there were still some interesting ideas and takeaways as well as several tools that I think we could apply to our projects. It was also interesting to see how some of the issues they mentioned in their workflows we have inadvertently tackled. These largely revolve around communication between developers and designers (of which we are often both)