Web professionals talk a lot about the importance of writing great code. We should talk even more about providing great user experiences for websites and products we build.
Code quality is really important. We should have standards, and utilize them habitually. We should code with proper debug tools so we catch problems as they happen. We should document our work, embrace new technologies, and strive for excellent quality all the time.
But creating great websites doesn’t stop there. Not even a little bit.
How useful is code that doesn’t throw notices or warnings if what’s painted on the screen isn’t accessible across a broad array of devices, browsers, and user abilities?
Not very.
What is a user experience anyway?
Wikipedia provides the International Organization for Standard’s definition of user experience:
A person’s perceptions and responses that result from the use or anticipated use of a product, system or service.
So user experience can be a positive, or a negative thing.
It made me a bit sad to see Google’s use of user experience:
if a website degrades the user experience too much, people will simply stay away
The expectation, based on this usage, is that the website will degrade the user experience away from the web’s intent no matter what; it’s just a matter of how much. What a sad perception.
User experiences should be delightful
That’s easy to say. No web designer or developer would tell you they intend to create a poor user experience in the things they build.
But just because we don’t want something to be bad doesn’t mean it won’t be bad anyway.
User experience is design, and a process
We are creating a user experience from the time we begin a project. If we’re not thinking about the user experience from the beginning, then we’re still creating a user experience; it’s just more likely to be a poor one.
Building the user experience is a process.
No, it’s more than that.
It’s a process, and a mindset.
We must continually design and build with the sole intent to delight those who utilize what we build, and then implement procedures to test our efforts.
Great user experiences embrace an imperfect web
To create a great user experience, we have to embrace the user, and the way they use the web.
Believe it or not, the average internet user is not on a 27″ Apple monitor with pixel perfect display. They may have an old monitor, a small monitor, or one that’s off color, or one with no color at all (like a Kindle).
They may touch their monitor to use the web. Or they may use a mouse. Or a trackpad. Or just a keyboard. Or a screen reader. Or one of those awkward pointer things from their TV’s remote control.
What’s important is that we don’t know what they might use to browse the web today, or in the future. Fortunately, with great analytics, we can at least know what they’ve used in the past. And when we start new projects, we should consider this past and attempt to estimate the future.
Not all users are the same
People are different. People are users. We all have different abilities — and disabilities.
We see differently. We hear differently. We touch differently. And we use all three of these senses using the modern web.
When we build web experiences, it isn’t good for us to assume everyone’s senses are the same. Our considerations for enabling excellent web experiences for as many users as possible are many.
The Accessibility Project is a great place to begin your journey building better experiences for everyone, and not just a good one for you.
User experiences get better with tests
Fortunately, building better user experiences don’t stop at launch. Once the product or website is in a workable state, we can put it in front of real people and test our designs and assumptions.
We can do user experience testing all sorts of ways.
We can track people’s actions with fancy services. We can create multiple ideas and see how they perform with A/B testing. We can create flash tests.
We can do testing with real people, remotely. Or we can do in-person, live tests. Live in-person testing can be formal or informal. If nothing else, I like to get my wife, a friend, or someone that hasn’t stared at the project for weeks to give it a spin.
The key to testing is to remember that your test is going two ways. You are testing the user to see what they do, and testing your intuition to see where you have room to improve. Over time, our intuitive ability to create create great user experiences can improve because we’ve put our assumptions to the test.
Code is fundamental to creating great user experience
I started this post by stating that we talk a lot about writing great code and not enough about creating great user experiences.
That should not be interpreted as me believing code is not important. In fact, great code is fundamental to creating a better user experience.
Markup matters. Performance matters. Code definitely matters.
Code quality and user experience are part of the same conversation, but we sometimes don’t balance them very well.
Intentional user experience design is central to creating a better web
And creating great user experiences doesn’t stop for website visitors. It’s important on the front-end and the back-end.
I’m not calling anyone out with this post. It’s meant to be encouragement, and hopefully offer a few resources to help you out. Others offer great resources consistently.
Sometimes I find myself getting lazy about crafting great user experiences for those that use the web differently than I do. That’s not good. I write this just as much for me as for you.
Hopefully together, we can make better, more informed, more strategic decisions so that we can craft better web experiences for everyone.
This is actually one of the best make-the-case posts for universal design/accessibility I’ve seen.
In my experience the user interface is the system
And I think a lot of developers, as you point out above, often forget this.
One of the biggest things with our recent shift to simplicity was making sure the simplicity side of things is what the user sees. Under the hood, there’s still a good amount of code in our themes. But the difference now is, our code does things in a smarter way to avoid presenting additional user interface elements to the user that they don’t want.
For example, we use Sass in our themes. One of the big challenges with commercial themes is providing granular color controls while also not going overboard with it. We build our color controls to be extremely simple to the user. Behind the customizer UI, the code is tweaking text colors and ensuring it is readable at all times, even when switching from a pink to black to white background color.
The “simplicity” we pitch is for the user, not for us. Perhaps a blog post would be ideal to help explain that.
I’d love to read that. Especially if you wrote it here đ
This is why I’m trying to get lots of design talks at WCSF – this post would make an excellent base for one.
I’ve been inspired by a number of WordCamp speakers on similar topics. It’s why I nominated Aaron Jorbin to talk at WCSF. I’d love to see someone like him take a broad topic like user experience and really spice it up for WCSF. His more narrow talks on color theory and accessibility lately have been great.
Btw, I’m looking forward to the design track. I hope you’re getting good submissions!
My teammate Andy and I presented at WordPress Boston meet up this week about how to focus your product development around user research/feedback. One of our points was, “Code is just a byproduct of solving people’s problems”, kind of up the same alley. đ
leadin.com/how-to-build-a-popular-wordpress-plugin/
I can’t make it to WCSF this year, but I’ve done a talk a couple of times now specifically designed to give a high-level overview of why user experience matters and how to scale it.
The “why it matters” part is important because UX considerations often suffer when put up against real life obstacles: deadlines, authority figures, and misguided design approaches. I’ve found that, to be dedicated to a user’s experience, it’s helpful to have a deep understanding of how you can affect the person on the other side of the screen. That knowledge is really needed when you get tired of fighting yourself or others, and would rather just ship the utility of what you’re building in hopes it outweighs the frustration of unthoughtful design.
I often use WordPress’s choice to be largely backwards compatible as an example of the UX we don’t think about that actually makes a monumental impact. There’s plenty of discussion to be had around that particular topic, but understanding these types of concepts at a high level gives a better glimpse into what it means to be outside our own ecosystem and truly engage with users in a meaningful way.
That sort of understanding and meaning is what scales UX practicesânot white-knuckled commitment to testing, for example. The methods follow intent and resolve naturally.
User experience is about time spent developing that mindset, testing and thinking in advance, so end-users wouldn’t.
WordPress products often get more options and “features” that don’t do any good to user experience or provide any real benefit, just some false sense of power.
It’s the developers with no sense of design and mediocre code quality or designers who don’t understand how things work beyond their canvas and brushes that are responsible for less than delightful user experience.
Do you think that design and development should be done simultaneously?
“Do you think that design and development should be done simultaneously?”
How can you build something before you know what you’re building, who you’re building it for, and why you’re even building it? Design is much more than just a coat of paint. The visual systems on a page are part of the graphic design domain, but UX architecture encompasses graphic design, interaction design, IA, content strategy, and many other components.
If you launch straight into development, those decisions still *have* to be made, but they’ll be made implicitly by engineers rather than explicitly by strategists and designers.
That said, we can still accomplish this in an agile workflow. It doesn’t have to be waterfall. Design just needs to precede development, but design tasks can be part of the sprint all the same.
“If you launch straight into development, those decisions still *have* to be made, but theyâll be made implicitly by engineers rather than explicitly by strategists and designers.”
Good point, Taylor. I still have problem with designers not wanting to take part in the development process, so the decisions rest on developers’. I’m talking about the majority of designers, not all of them.
I guess they need more of these articles and the will to explore beyond their comfort zone.
Two years ago Obox invested many thousands of dollars in User Testing to make our themes better. The results were incredible, customers used our themes in ways we could barely imagine.
To this day we consider it the best money we’ve ever spent both in terms of education and in terms of making a better product. I’d recommend every single theme co do the same.
The original idea of responsive design was to respond to device. I think we should take that term back.
Responsive design is about responding to the goals and tasks of people. Perhaps that ends up being a mobile device. Perhaps it’s something, as you alluded, completely different.
Point is, we can’t design for machines or devices. The term design itself dictates that it must be for humans. We don’t design mobile first and we must design for humans first.