Design is not just what it looks like and how it feels: design is how it works.
Steve Jobs, Co-Founder of Apple
User-centred design has become the driving methodology of design in the past few years. Design used to be something that was purely driven by the aesthetic: how something should look. With user-centred design, the people using the product are what drive the design.
I recently was able to attend the UX Scotland conference in Edinburgh. The three days of sessions were insightful and thought-provoking, covering a range of topics including accessibility (of course), creating a community of peers, creating products and services with ethics in mind, insights as a new manager, and gestural interfaces for mixed reality.
I even got the opportunity to give a 5 minute “lightning talk” on being an introvert in an industry that is often biased in favour of extroverts, based largely on a my post on playing Dungeons and Dragons.
There was so much good, useful information that gave me a lot of ideas for ways to improve things in my role and organisation.
So why were there no other developers there?
Design is how it works
The term “user-centred design” was first coined back in the 70s — before computing with a graphic user interface was even a thing — but has built up far more traction relatively recently.
From the US Government’s documentation on usability, the general process of user-centred design is defined as:
- Specify the context of use: Identify the people who will use the product, what they will use it for, and under what conditions they will use it
- Specify requirements: Identify any business requirements or user goals that must be met for the product to be successful.
- Create design solutions: This part of the process may be done in stages, building from a rough concept to a complete design.
- Evaluate designs: Evaluation — ideally through usability testing with actual users – is as integral as quality testing is to good software development.
More simply, the process could be defined as:
- Analyse the problem that you’re trying to solve, and identify who you are solving the problem for
- Design a solution based on that analysis
- Test the design to make sure you’re meeting the needs
And repeating the process as required, taking insights from the testing and evaluation until you are confident that the designs are fit for purpose.
This process, however, extends far beyond a single type of job role, and requires not only interaction and interface designers, but also user researchers, service designers, content designers, and business analysts to name a few.
Though I haven’t been able to find a primary source, human interface design pioneer Brenda Laurel PhD, is quoted to have said that “design isn’t finished until someone is using it”. And people can’t use a design until someone’s built it.
Choices in development affect user experience
Notably absent from most lists of steps or phases in the user-centred design process is a development or build step; and absent from lists of roles related to user-centred design is developers.
But how a product is built has a large impact on how people experience the product. For physical products, we’d call it the build quality.
Digital products also have a build quality: things like the performance — how fast it loads, and how long you need to wait between clicking a button, and the action occurring; whether the product works with screen-readers, etc.
Regardless of how much effort has gone into the user-centred design process, a poor build can wipe out that effort.
Apple co-founder Steve Jobs once said, “design is how it works”. And how it works is determined by the build.
Focusing for the developer experience rather than the user experience
A trend in modern web development has been a focus on creating a good developer experience: tools and processes to make development simpler and easier; to encourage reuse of code and patterns, and to streamline our workflows.
When I started my career, a website was an HTML page that may or may not use CSS for styles, and that almost never included JavaScript. Everything was written out, in full, by hand. We had complete control over the code that we were putting out into the world.
Development isn’t like that any more. We have so many new tools and technologies that make developing large, complex applications so much easier and faster than it used to be.
But we’ve reached a point where the so much of the development process is abstracted away, that we have far less oversight of the code that we’re producing, rather than more.
The development is easier, and faster and better. But it also leads to complacency: because we no longer have to be in complete control over the code, we’re not taking as much care with the user’s experience. We’re including hundreds of third-party dependencies into our projects, and onto our pages without really thinking about how it’ll affect the experience.
Analysis by HTTPArchive from October 2022 shows that the average page-weight — the combined sizes of resources required to load a page — has increased significantly over time. Their analysis showed that, in 2012, the average mobile page weighed only 288KB, while the average desktop page weight 669KB. In 2022, that increased to 2001KB and and 2299KB respectively.
Their analysis largely credits images and videos as the source of the increase.
However, a quick search can show many threads on StackOverflow with developers concerned with the size of JavaScript bundles reaching almost 2MB.
And the analysis from HTTPArchive on JavaScript shows not just that, in the 90th percentile of websites, JavaScript weighs in at 1,503KB on desktop and 1,367KB on mobile; but also that 645KB of that JavaScript is entirely unused on desktop, and 604KB on mobile.
And that size of JavaScript is problematic. Not only does it put more strain on the servers handling the HTTP requests, but it increases load times, delay interactivity, and — when using a mobile device — can burn through their cellular data quickly.
The focus on creating a simpler and more streamlined developer experience has made us complacent to user experience.
To mis-quote Dr. Ian Malcolm from Jurassic Park, slightly: “We’re so preoccupied whether whether or not we could, we didn’t stop to think if we should.”
Design isn’t finished until someone is using it
I have a great appreciation for the design process and good design; and a great envy of people with the creativity to start with a blank page and make something beautiful. I think that’s why, throughout my career, I’ve always tried to insert myself into the design process as early as possible.
In a lot of organisations — particularly large, enterprise organisations — development can be quite insular. It’s a technical profession often under an IT or “Digital” department, and therefore entirely separate from the more creative or analytical user-centred design professions.
And because developers are often silo’d from the rest of the user-centred design function we often receive completed designs, tossed over the fence; and we have a tendency to view the build as “the thing”: that what we make is the product.
But development — particularly front-end development — isn’t a solely technical profession: we straddle the line between the technical and the creative.
Conferences focused on development tend to focus on the technology: how to use this cool new thing, and why it’ll make our lives as developers that little bit simpler. But there’s often no significant focus on the user, and what we can do to create a better product for them.
But design isn’t finished until someone is using it. Design is how it works. Someone can’t use it until it’s developed; and you don’t know how it works until it’s built.
The build itself isn’t the thing. Development is part of the design process.
And I think the biggest take away from my time at UX Scotland is how it would result in far better products if more developers appreciated that; if more developers attended conferences that focus on user needs, as opposed to technology; and gave more focus more on the who and why, rather than the how.