User-Centered Web Development
When we think of user focus we easily think of usability tests, following a usually strong wish to produce something that’s actually useful. For us as web developers, focus on the user has a tendency to appear distant though, for what users do we really have? Who “uses” our code? Yet it shouldn’t be a stretch to recognize that we do have users—and that with that, there’s also something like user-centered web development.
Web Developers Have Users
There are two clouds we may need to wave away before we can see more clearly how web developers have users.
The first cloud is team size. If we work alone, we do have no users in a team, for our team consists of only one. Evidently. But once we add a team, just one other person working with our code, we can tell how these people are actually our users: They use our code by working with it, whether that’s compiling it, trying to understand it, extending it, otherwise manipulating it, or even deleting it. Once someone else interacts with our code, we have users. [Here and particularly in the “developer users” section, I missed an opportunity to build a bridge over to developer experience (DX).]
The second cloud is use. Just because we “use” code in an editor does not mean that’s its only use: Editing code is clearly only one use of code, for we really write and edit it to be processed in some way or other—and that processing leads us to the other user group, the biggest one, the end user. The end user uses our code just as much as the peer, only indirectly, and so anyone using our website or app is also our user.
If this hasn’t been our understanding before, we’ve just put ourselves squarely in line with anyone else who traditionally has users, from the product owner to the project manager to the designer to the site reliability engineer. We all have users, and with that we can focus on our users.
Web Developers Can Focus on End Users
With a lot more users than our team would have suggested, why and how would web development now become user-centered? How would Google’s famous “focus on the user and all else will follow” apply to us, or how would we put it to use?
Fortunately for us, the motivation for many of our field’s sub-disciplines already centers on the user.
Accessibility, for example, is for end users, and much depends on us developers. When we take only a cursory glance at the Web Content Accessibility Guidelines we find a strong connection between users and developers. Many issues that users face—not only users with disabilities—can and must be addressed technically. Examples? On a higher level, not even looking at specific techniques, making functionality available from keyboards (providing sufficient ways to navigate, to find content, and to determine where users are) as well as maximizing compatibility with user agents and assistive technologies.
Performance is measured from the end user’s end. That makes sense: Performance influences user satisfaction and conversion. Our focus on the user begins with measuring the performance of our sites and apps (through tools like PageSpeed, Pingdom, or WebPageTest) and ends with improving what we can realistically—not dogmatically, by focusing only on performance—improve.
Functionality, even around trivia like working links, also connects developers and users: If a request is not sent, if a feature doesn’t load, if a page doesn’t exist, it’s a technical issue that falls straight into the user’s lap (and hurts them there). Functionality may make it most evident why user focus is so important for us as developers.
One can say that only design-related questions could create obscurity—usability testing is about end users, but may or may not affect us developers. But surely we have a relationship even here, because we test usability for our users by way of the code we write.
Now let’s look at our developer users. How does user-centered development look like here?
Web Developers Can Focus on Developer Users
Quality. First and foremost user-centered development means emphasis on quality. Alas, quality is vague here and, more importantly, not a true attribute to focus on to make our work more usable for other developers. There are other things that help with developer usability.
Consistency. Consistency has three stages. At a basic level, when there’s little standardization in our organization (or when we simply work alone), consistency merely means to be consistent with ourselves. We should always format code the same way. At the next level and here we assume code from other developers or third parties, consistency means to follow the code style used wherever we touch code. And then, normally a level reached in bigger organizations, consistency means adhering to our coding guidelines and style guides. These three consistency levels are not mutually exclusive, and in organizations, we typically find the second and third quite well-established.
Comments. Comments can be a part of coding guidelines but they must not necessarily; and because comments are maybe the single most important thing to improve developer usability they should be called out separately. Comments mean code comments, and code comments are important because code is not necessarily self-explanatory. Well-written code may give an idea of how things are done, but not why. To explain that, we need comments—and more discipline, as I, the here critical author, am responsible for scarcely commented code, too.
Documentation. Documentation actually addresses more user groups than only us developers—it targets developers, designers, concepters, project and product managers, business owners, organizational stakeholders, perhaps marketers and business developers and our legal teams, and maybe even end users—but as such it’s a prime area for user-centered web development. Much like quality code helps to understand how what things are done, and comments explain why they’re done, documentation can show the overall picture and give all their users a better idea of what’s going on in the first place. This may seem like a distant demand for us at first (and I’m with the ones who’d want to avoid getting bogged down by writing lengthy technical documentation no one may read in the first place), and yet I see this point as encouragement for us to find better approaches to documentation, precisely for more user focus from us as developers.
❧ Estelle Weyl suggested “we should be focused on the user experience, not the developer experience,” and from the angle she has come from she’s absolutely right. Developer experience (and developer usability, as suggested in Principles of Web Development) matters, but ultimately we as developers do have users, and our work should reflect that. User-centered web development, that lends focus we need more of.
I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma. I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe of interest to you, too:
- Next: CSS Optimization Basics
- Previous: HTML, CSS, and Dependency Direction
- More under Web Development, or from 2018
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try WebGlossary.info—and The Web Development Glossary 3K (2023). With explanations and definitions for thousands of terms of web development, web design, and related fields, building on Wikipedia as well as MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.