Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
by
Lessons:4Length:27 minutes

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

1.2 Recognise Your Influence

In this lesson I’ll share some examples of how you, as a developer, can make or break the user experience. We’ll look at areas such as performance, validation, security, and accessibility. This will help you see how important your role is.

We’ll go on to discuss how you can become a user experience advocate. Finally we’ll address how to balance the needs of the many with those edge cases that often take so much development time.

1.2 Recognise Your Influence

Hello, and welcome to this presentation on becoming a user experience developer because who says designers are the only ones who shape the user experience? My name is Paul Boag, and over the next three videos we're gonna look at how developers are essential. They're essential contributors to improving the user experience. I'm gonna help you understand how you could make that experience better and discuss a few ways to make sure that you get listened to in the conversations about user experience. But let's start by dispelling a few misconceptions about user experience. You see, in the minds of many, user experience and user interface are interchangeable. That's why user experience is so heavily associated with designers. After all, many of the frustrations we experience with digital tools revolve around the interface, frustrations about readability, scanability and ease of use. But the user experience doesn't stop at the edge of the screen. It's not just about the pixels. Much of what user experience boils down to making the experience faster, easier, and less frustrating. And how a digital service is built is a key component of those factors. This means unfortunately that you, as a developer, have ample opportunity to ruin the user experience. Take, for example, performance. Nothing frustrates people more than having to wait for technology. Whether it's waiting for a page to load or a progress ball to complete, we're incredibly impatient when it comes to dealing with digital services. Research has shown time and again that the longer a web page takes to load, the more likely users are to go elsewhere. And that means performance is one of the most important elements when it comes to creating a great experience and that lies firmly In the remake of you as a designer. Another area that is very much the responsibility of developers and yet has a profound impact on the user experience is security. Password requirements are great example of how developers' decisions can have a big impact on how easy a website or mobile app is to use. As developers, we sometimes have a tendency to make our problems with security the problems of our users. Whether it's a CAPTCHA form or a difficult to remember password, it's easy for us to ask users to jump through some hoops rather than put in the extra work to create a more streamlined experience ourselves. Another example of shifting the complexity from our own work to the user's interaction is for validation. Users have a tendency to be inconsistent in the way they enter data from person to person. For example, some people will enter a credit card number with spaces in and others will leave the spaces out. The same is true for telephone numbers or postcodes. Now it's tempting when deadlines are looming to simply set the form to reject spaces, so forcing the user to correctly format the field information. But doing this is likely to cause frustration and ultimately damage the user's experience. A similar problem with forms happens when data is not remembered after the form has encountered an error. Nothing's more frustrating to a user than having to reenter data multiple times. Yet in our rush to get work out the door, we often overlook these kinds of details. Another area where we tend to cut corners is in accessibility. When the pressure is on, it's easy to ignore older browsers or polyfill things with JavaScript or not test as thoroughly on mobile devices as perhaps we could. Unfortunately all of these things ultimately have a negative impact on the user experience. Of course, not all of these problems are our fault. Designers have a tendency to gloss over details and we're often not given adequate time to focus on these kinds of elements. But we don't do ourselves any favors either. We have a habit of working in isolation rather than ensuring we're working alongside the designer. We also don't push hard enough to be involved in the early stages of a project where we could flag these kinds of problems. Part of the reason for this is that we don't really consider ourselves user experience champions, and that has to change. In everything we do, we must ask ourselves what impact this is gonna have on the user and whether it's possible to minimize that impact or minimize what it is that we're asking the user to do. We also need to fight hard for the time and resources to make that happen. And that means getting in at the very beginning of projects before budgets are set and designs are finalized. In particular, we need to work very closely with designers. When possible, actually sit side by side with the designer, working on the design together. Instead of letting the designer hand you a design comp, sit down with them and design in the browser together. Not only will it shortcut the design process, it also means you can start to educate the designer about some of the details they have a tendency to overlook. That said, there is a balance to be struck here. Sometimes as developers our attention to detail can actually be problematic. For example, we have got a tendency to take our obsession with edge cases a little bit too far. When it comes to digital development, there's kind of two types of edge cases really. There are edge cases around audience and there are edge cases around unusual scenarios. These two types of edge cases typically manifest themselves and are saying something like but what if someone wants to dot, dot, dot? In other words, there may well be people who want to do something that is somewhat out of the ordinary in our application or website, and we feel a need to accommodate those needs. One may think that creating a good user experience involves allowing people to do whatever they wish to with our applications. And it's certainly true to some extent. However, it's also important to consider the impact that these users and their functionality has on everyone else. Catering for edge cases can be extremely damaging to the experience of others because it adds complexity to the user interface. For example, just because it's relatively easy to add advanced search features doesn't mean that we should even if there are people out there that would be interested in using them. Also take, for example, country lists. Sure, it might be possible that somebody orders your product from Antarctica or Venezuela, but how likely is that really? Every country that we add to that drop-down list of countries is another country the majority of people have to scroll by. Equally it's possible that some people might have a third line to their address and so it may be tempting to add this field to our forms. But wouldn't it be better to hide this field by default and allow the minority of people who need that extra field to add it on request. As to those advanced features that only power users want, perhaps we should introduce some form of progressive disclosure. In other words, the more somebody uses our application or website, the more functionality we start showing them. And we introduce it in maybe a more prominent way. This functionality could be hidden to begin with and then slowly revealed over time. We're starting to see this kind of approach happen with some mobile apps and it works really well. As a rule of thumb, I suggest using what I call the laws of simplicity. Law number one, ask yourself, can this piece of functionality be entirely removed? If that's not possible, law number two, can it be hidden in some way? If it can't be hidden, then we move on to law number three, which is to visually shrink it so that it's clear to the user that its secondary content, secondary functionality that may cover some kind of edge case. In other words, being a great user experience developer is as much about what you leave out and hide as it is anything else. Remember, ultimately our job is to remove complexity from the user experience. This may be by automating some of that complexity behind the scenes or it could involve choosing not to support every scenario that a user might potentially want. Nowhere is this principle more perfectly demonstrated than when it comes to the design and build of online forms. And that's gonna be the topic of our next video. But until then, thanks for watching.

Back to the top