A practical guide to digital user experience design

Working as a designer for the past 18 years, I’ve had the privilege of working in a number of different areas from software development, website design, interactive CDROM (RIP), animation and app design. What do all these have in common? They all have an interface between people and product and to be successful, they all require user experience design.

 

A (very) brief history of user experience design

Although the term user experience, coined by Don Norman in the 90’s is relatively recent, the study of interaction between people and their environment is far from it.

The art of Feng Shui dating back some 6000 years refers to the spatial arrangement of objects in relation to the flow of energy or chi to create the most optimal, harmonious experience.

Henry Dreyfuss

From the 1930’s through to the 1970’s, the renowned industrial engineer Henry Dreyfuss was responsible for dramatically improving the look, feel, and usability of dozens of consumer products from some of the most iconic brands like Hoover, John Deere, Western Electric and Polaroid.

His design philosophy was based on applied common sense and scientific principles and resulted in significant contributions to human-factor analysis and consumer research.

 

Polaroid SX-70 Land Camera

In 1955, Henry wrote Designing for People, in which he said, “When the point of contact between the product and the people becomes a point of friction, then the [designer] has failed. On the other hand, if people are made safer, more comfortable, more eager to purchase, more efficient—or just plain happier—by contact with the product, then the designer has succeeded.” This sums up purpose of user experience design very succinctly.

The iconic Western Electric 302 dial telephone

Back in the digital world, our implementation of user experience design is far more contemporary. With the advent of Web 2.0 in the mid-2000’s, more and more emphasis was put onto the way users interacted with our digital products. We started to pay attention to the way people (or users) felt and how they responded to our interfaces. We started to overlay the concepts and rules used to design our physical objects and apply it to our digital ones.

 

Where should you begin?

In the last few years, there has been a veritable explosion of tools and techniques created to aid us in research, discovery and prototyping designs with the users of our products. To anyone new to the industry, this can quickly feel overwhelming.

Deconstruction of a Customer Journey Map – Nielsen Norman Group

 

Articles from prominent software development companies and design agencies evangelising their techniques and ceremonies can have you being pulled in different directions.

The truth is, all techniques can be distilled back to a few simple core ideas. These companies have taken these ideas and developed them into something that fits their organisations structure and needs. Not all these techniques will work for you, and that’s ok.

User experience design is a simple cycle: User research, ideation, prototyping, testing with users. Rinse and repeat.

You may find yourself working within an organisation that traditionally has not put an emphasis on user research and user experience. Thrusting an unwitting group of colleagues into a Crazy Eight ideation session may go down like a lead balloon – causing said colleagues to look dubiously upon this user experience design concept you speak so passionately of.

“Crazy Eights” showing multiple options for a donation screen – inVision

 

Keep it simple

Find a product requiring better user experience. It generally helps if this is a new project not caught up in the bureaucracy of existing stakeholder engagement, time and budget restraints. Find a project with a clear goal, for example,  “to make it easier and more intuitive for users to use a particular feature”.

 

Start small

When dealing with an organisation that isn’t well versed in the practice of user experience design, they may look upon this as a “nice to have” or “something we can look at further down the track”. The truth is, user research conducted right at the start of a project can pay dividends in the long run, providing essential insights, saving unnecessary refactoring of features, and a reduction in customer support budgets. This is often the best way of selling UX to a client or product owner as they will understand the benefit of savings costs in these areas. Try starting with a small, well-defined statement of work which could include:

  1. Conducting some user research: This could be as simple as observing people try to use an existing feature, noting down pain points and asking specific questions that will allow you to generate personas
  2. Producing a set of key personas: If it is not possible to obtain enough information about the users to properly develop personas, then proto-personas can be created and validated later.
  3. Creating an interactive prototype of a new feature: This can be as simple as different screens or visuals printed on a piece of paper, or using an interactive prototype tool like inVision. You don’t need to invest a lot of time into making these look amazing if you’re simply testing a workflow. A set of wireframes will suffice.
  4. Running a small user testing session to validate the prototype: You don’t need to run the same prototype passed a whole bunch of users. Between 3 and 5 is probably a good amount to aim for. Any more and the amount of insights to be gained quickly diminishes.
  5. Designing a few key high fidelity designs of the feature / product: Based on the results of your user testing, you should now have a good idea if your prototype will work. You can now back up your designs with this evidence.
Proto persona example of a university student

One or two people should be able to conduct this first piece of work keeping your spend to a minimum. Keeping the scope small also makes it low risk and allows you to gain trust and produce valuable outputs quickly.

 

Meshing visual design and UX together

As a designer, I’m constantly wanting to push the boundaries of the interfaces I create. I’m also very aware that some of my creations may not necessarily hit the mark when tested with users. Often those working within the UX field will consistently fall back on the tried and true patterns and concepts as they know they will have been thoroughly tested and accepted as best practice. If you’re not careful, this can lead to overly homogeneous interfaces. It is ok to try new and innovative designs patterns as long as you always keep the user in mind. If you’re unsure if something will work, test it! If your users understand how to interact with the new pattern intuitively and they can accomplish their task easily, then you have success.

It is so important that we keep challenging our understanding of our users. Technology is constantly evolving and improving, therefore the way our users interact with that technology is constantly changing. User experience design lives at the heart of these interactions and the best toolset we have to make sure we always build the right thing.

Transforming Code: Refactor by example

Firstly, let’s explain what refactoring code means. It’s like a music remix. You know how you hear a really good song, and five to ten years later some random artist, or sometimes the same artist, makes a remix of it? And the remix is even better than the original. It’s almost always better because it’s been updated. It’s got the new beats and sounds, but with the best bits of the original track.  

That’s what refactored code is. It’s better because it’s updated, with the best bits of the previous code. It’s got the new design patterns, frameworks, libraries – but, most of all, it’s got the new you as a more experienced developer. Just like any artist who continues their craft, you improve.

Refactoring code before it becomes a burden is one of the trickiest and best examples of software development best practices. There is a really important differentiation in there. It has to happen before the task of refactoring becomes burdensome.

If you’ve been in the development field for many years, you’ll have experienced refactoring an ancient code base or an old, unmaintained application. Once you hit a certain level of refactoring, the work becomes tedious because it’s such a huge amount of work. It’s no longer fun. It turns into busy work as you update seriously outdated code, requiring a lot of effort and man hours. Once it turns into busy work, you will find a way to script it or automate it.

And so, instead of spending nine hours manually editing files, you build a script in two hours to make all of the changes in three seconds. The scripting bit is actually quite fun. The problem is, it’s the only fun part in a situation like that.

You shouldn’t have to spend two hours building that throw-away script, because the code should have been refactored well before that point. Refactoring code shouldn’t be tedious.

A good rule of thumb is, if you notice that your code is really, really obviously in need of a refactor, then you’ve probably waited too long. By the time you start, it’s already well past the point where it became tedious. So, I guess what I’m trying to say is, refactor and refactor often, because the cost of refactoring too much is a lot less than refactoring too little.

This is a timely reminder for me, because I witnessed some coworkers make this early refactoring decision recently.  It was awesome. There are three of them on a new project right now. (I’m not on it, and don’t have anything to do with it at this point, but it would be a fun project to work on.)  It uses some frameworks outside of our core stack, so they get to brush up on some interesting libraries at the same time.

The other day, they all suddenly stopped what they were doing. It was about 5pm and you could tell they were a bit tired from the day’s work. This is early on in the lifetime of the project and a lot of developers, especially the inexperienced ones, would never think to refactor code so soon. They would think that making those updates means admitting they failed at some point, when that is not the case. The team stopped and said “this code is too complicated, it’s too deep.”  

The cyclomatic complexity of the code is what they were talking about. They felt like it shouldn’t be this hard to follow so early on. And so one of them said, “I think we need to refactor this code.” It’s such a hard thing to admit, but it’s the best admission you can make on a project.  It’s an admission that saves a whole lot of time and effort down the track. Seeing this unfold first hand was exciting because I know the feeling (once you’ve made the decision). So, not only do they get to work with some cool new tools, but they have a nice healthy refactor to do. Should be fun times ahead.

It’ll be fun because you’re taking something that has already been built and improving it. And if you have good test coverage, you can make changes to your heart’s content.

 

Refactoring – who to ask, and examples

Wondering how to improve a particularly intricate chunk of code? There are patterns for that. Or, if you work in a larger team you probably have coworkers that would be happy to help. Don’t be afraid to ask! I’m not a proponent for always pair programming, but there are situations where I find it beneficial to pair programme. This would be one of those situations. If you work remotely, there are even solutions to pair over the intertubes!  If you use Slack, then you have built-in support for screen sharing – they took my favourite code collaboration software, Screen Hero, and integrated it with Slack. I’ve also used Zoom to screen share but it doesn’t have all the bells and whistles. Or you could try the plethora of other screen share applications.

I’ll end with a couple of concrete examples of when to refactor. The first example is an easy one to spot. This is a bit of Loopback model code. I needed to reuse a chunk of code in related polymorphic classes. So I extracted the function to DRY it up. Variable names have been changed to protect the innocent.

BEFORE

AFTER

The second example is not as obvious at first glance. This is a chunk of Ember model utility code. The switch statement was getting a bit too big for its britches. To clean this up I used the Strategy pattern.  Again, variable names have been changed to protect the innocent.

BEFORE

AFTER

If you’re looking to hone your refactoring skillz, there is plenty of material online. But by far the best thing you can do is practice. Good luck and happy coding!

Further reading on when to refactor:

Other blog posts:

A book by the well informed Martin Fowler: