Posted on 5th September 2024

How we build technology affects user experience

In an ideal world:

  1. Technology would improve our lives
  2. Technology that we pay for we would own
  3. Technology would be sustainable
  4. Technology would have a long and well understood lifecycle

These things aren't happening in the majority of cases when it comes to emerging technologies. Market forces and a lack of decent regulation has meant that the development of technology has evolved in a haphazard way, such that the digital world has arrived the following position:

In this post I will explore the reasons for this and how decisions about how we build technology can have an impact.

The web is what it is

In the majority of cases the obvious choice of medium for tech we want to create is a website. It will do the job well enough given that other alternatives are too costly, complex and reliant on third-parties in order to deliver. However the resulting level of innovation will likely be less than the tech has potential for, and the majority of people will get an average user experience from it, leaving many specific segments of potential users with a sub-par or even unuseable experience.

Essentially the web is the lowest-common-denominator platform for delivery of technology. And yet it is so precious because it is the most universal and ubiquitous a platform we have in the world of technology. It was never intended to deliver 'software' or 'applications', or interact with data or devices directly, and yet here we are operating an unfathomably large amount of our technology via the web.

We are where we are with technology: The two largest vectors for delivering digital technology to the end-user being the web and 'mobile' apps. We are reliant on browsers and app stores over which we have no control. Directly affecting the future of these environments in which our hard work will live is beyond the wherewithal of most of us who work in the industry.

What is within our control and some useful questions to ask ourselves that might help

Technology alone will not solve the problem. It may be part of the solution, but forces beyond 'engineering' will also be required. We have seen time and time again that in absence of a better mechanism, well crafted policy and regulation is the only thing that makes certain aspects of technology better for everyone.

I'm under no illusion that any of this is something individual people working within the industry can change single-handedly. Nor is it likely to be an easy task for anyone due to the politics involved. But being mindful of these issues does also allow those of us working within the industry to ask questions about the things that we can control:

How should we be developing technology ourselves? What platforms are best for achieving positive outcomes for everyone?

Since studying user experience design, these are questions I've been thinking about a lot. When a new project comes along I have the opportunity to affect how it is delivered and I want to be mindful of how those choices impact users. Making good choices about how we build technology is important given how reliant we all are on it.

So what is it to be: Go all-in on 'web-as-a-platform'? Develop specialised applications for specific devices? Abstract out the 'core' of your technology's logic so it has better modularity? Use an existing framework or design your own solution? These choices have far greater ramifications than you can ever predict when starting out on a project and it's important to take them seriously.

R & D* FTW

* (Research and Design)

Research and design relating to the project you are undertaking and the people it affects are crucial to answering these questions as best you can. It is important to remember that these kinds of choices are fundamental to what we can deliver and place certain limitations on it that we will have to live with.

If I've learnt anything in recent years as my career advances it is that:

The success of 'the thing' we are building is entirely contingent on the environment in which it will operate and the people who interact with it.

Where we have agency to influence decisions we have to understand what our options are. One of the most important aspects to consider early in a project is the world in which you envisage it will exist, even before you have a strong idea of what it is you're building:

Asking these questions is a part of tried and tested user research techniques, something we would all do well to invest in more. But what I think is not always considered is the importance of using these questions to inform not only what we are building but also how we build it.

At times the industry has tried to separate the what and the how, but I believe they are intrinsically connected. That is because there are always constraints we all have to work with: Not least of all the inherent pros and cons to our current technological landscape, over which we have no control. Therefore we must consider how the decisions we make about design and implementation can impact users (and try to effectively negate as much of the negative aspects of the things we can't control).

Implementation and iteration

The design and implementation of technology should be an iterative process. Feedback loops containing new information should be applied to decisions at every level. That includes reviewing how you deliver your tech. The following questions should be considered when first creating a solution and also when maintaining and improving it:

These are open questions relating to implementation that absolutely depend on what matters most to your users. It is important to keep in mind that that the balance of the debate can change anytime.

Influencing choices like these in your work might not solve the tech industry's problems overnight but they can have an outsized effect on how the technology you are responsible for will be received.


* An opinionated note on complexity and tech stacks

If you are in a position to affect the tech stack used, it is arguably one of the most important decisions you will be involved with making, and will have to keep making as a product or service evolves. The choices made are reliant on what it is you need to achieve and your priorities, which should be informed by proper design work.

I believe reducing complexity increases your chance of a reliable, long-lasting and maintainable solution. It behooves us to think about these factors when choosing external dependencies (from JS frameworks to hosting providers and cloud services). I don't want to force an ethos on anyone, but I do believe that the starting point should be to develop things using the most basic building blocks available.

If we're talking web, that means HTML & CSS and most likely a server side component for data and logic. Chances are you probably will need some Javascript eventually, but think about if you really need a framework, and most importantly why. In your tech stack choices, and in the software's architecture, try to make things as easy as possible to replace.

Most of all I'd really love it if more people thought about what their solution will look like for users and developers in 6 months, 2 years, 8 years time and beyond. When considering this, the choices you make about the structure of the code are secondary to the choices you make about what you build the solution with. Good design and development practices won't matter if a component used results in the solution being too slow, clunky or unable to be updated, especially if that component is deemed too costly to replace. This situation is far too common in the tech industry and I think we could all do better to avoid it.

Obviously we can't anticipate future needs for solutions, nor accurately predict the longevity of a third party component or tool. But there are some universal truths such as the fact that users will always want technology to work for as long as possible and every 'moving part' introduced poses a risk to the of the lifetime of a solution. In my experience, worrying about whether a solution is 'scaleable' is a phantom problem, compared to the very palpable issue of whether it is sustainable... Which is something that depends heavily on the tech stack chosen.