Training in Usability

Training in Usability

Naturally for someone in my position where too often I find myself writing a web UI, it would be really useful if I could say I have some skills in Web UI Usability. I am hoping to achieve this through reading a couple of books and an online course. That should be enough to qualify me as at least knowing more than average Joe off the street. I will leave my notes here from my studies along with my own experiences.

Fundamentally Usability and User Experience is often an exercise in common sense. Most of its principles seem really obvious in hindsight, but it's great to lay them out first and foremost. Unfortunately because they seem so obvious its hard to picture studying them as actually some kind of specialist skill.

One of the exciting points about approaching this is that I was hoping to put to bed all the arguments I have ended up listening to in the design room, but this isn't the sort of subject where you can do that. It would be nice that if an argument breaks out in Sprint planning to be able to say "actually 99% of people find using that sort of UI more difficult, so lets put this discussion to bed and go with what Jamie suggested." Sadly, the first book I turned to began with the words "Nothing is true, everything is permitted". The frustration is that there is no one way to do things. While it would be great to spend less time in meetings arguing or listening to arguments and more time pumping out work, it is a bit of a pipe dream here. There's always a matter of opinion and only the future will be able to tell the affect on a product's eventual users.

Everyone has an opinion and some of them stink

Why do people argue? Everyone seems to be coming at this subject from different perspectives. While not everyone falls neatly into these boxes I have observed these different people in the work place and their ability to contribute to the decision is not complete.

Developers know their stuff, but can they really sympathise with a user? I often find that developers are often very techy and used to using very complicated UIs, so they find it hard to sympathise with a user who might not have that experience. If you don't agree with me, just ask yourself how many developers you know that wouldn't mine a CLI? Well a CLI is major "no-no" for most people, so the dev really isn't "in their shoes", so to speak and won't ever wear their shoes, no matter how much they think they can. I am a developer and so I shouldn't be able to see developer's faults so easily because they are my own, but I can see these easily.

However a developer also often uses plenty of technology and in doing so they have seen a lot of UIs. With a little luck, they will remember which ones they found easy to use so their wider experience might mean they have access to some good inspiration when designing a UI. Most developers I know will have studied some form of UI design at some point in their career. I mean that's why I am here. So they should ideally have an above average knowledge in this area. Devs also cycle through company to company every couple of years, so often they are looking at a system with relatively fresh eyes.

Product owners should know the user better than anyone. Product owners often know how to work in a field really well. If they are making software for manufacturing they understand the manufacturing industry well. They can sympathise well with all the advanced users of a system. In fact, its their job to be on the same page as those users.

Often Product Owners are not as IT savvy as other staff and have less experience of other UIs because their experience is more focused on the field the software is being introduced into. Too often in my own experience I have noticed that Product Owners have gotten too close to an advanced use of their system and don't necessarily have a good understanding of someone who might be coming to their system anew. They have often stuck around the same product for at least 3 years sometimes closer to 10 years. They know this one system and everything about how it works, but they can't look at it like someone who had never used it before. Their idea of good UI is often great for Advanced Experienced Users, but not good for newbies.

Sometimes Product Owners are speaking to the managers of the managers of the users of the product and well for as much as their know what the customer wants to buy, they don't appreciate the day-to-day user of the system. I saw this a lot in the Civil Service. The product were not designed with consideration for the administrators who were going to use them so often things like typing short-cuts were not included and users who wanted to get stuff done as quickly as possible were left switching between keyboard and mouse constantly slowing down more experienced administrators like me. I remember when I was typing letters and I would type them in less than 3 minutes per letter, but then it would take me 5 minutes to record in the computer system that I had sent a letter because the requirements to go back and forward in wizards that were unintuitive and required constant swapping between keyboard and mouse because of a lack of keyboard short cuts.

Project Managers are awesome. They speak to every body. They context switch a lot and they can often understand everyone's different language. But they are often under pressure and want a quick solution.

They are normally using a lot of simple UIs and can quickly identify what's quick to understand and what is going to take a little bit more work. However the PMs desk is constantly being hit by problems and frankly some UI questions are a really low priority when a sales person is asking for a proof of concept of a new feature, the support team have uncovered a new bug, there's a release at the end of the month and the current feature is behind. Their response can often seem curt. Soon as there is a simple solution to get this low priority problem back in the developer's court then they will take it so they can focus on the things that are a higher priority.

A huge part of a PM's job is working with a multidisciplinary team of people who all have different skills which the PM does not have. This means they are frequently being made aware of their lack of knowledge and approach the subject with blissful ignorance. This means they are very practiced at looking at something with what the Buddhist call "beginners mind". They can sympathise with a new user.

PMs tend to shift around at similar speed to devs 2-3 years. So again they're thinking of the new comer to your product. Not only that but they can think of the advanced user as well since, they just had 3 meetings with them last week.

So no-one really can give the best answer. There often isn't just one truth. What's good for one situation isn't necessarily for another. Too often developers talk in absolutes when really in practice things are very much an art. With art there is not one way to do something there is only self expression. One person could make a UI that is fast to use for experienced users, but frustrates a lot of users particularly newbies. Another could use a method which is slower for the advance users, but the newbies get on boarded quicker because it's almost identical to something common like google mail.

Sometimes its just best to pick up a great idea and run with it, but if someone else says B then I go with it. As a general rule, I find it's rarely helpful to be assertive in the design room, because too many people have an opinion and its just exhausting to explore them all. If someone feels their idea wasn't taken on board or it was criticised they will get upset and waste people's time on it further. I will give my best way to solve the problem and if someone says don't do that, then I will consider their alternative suggestion (sometimes they don't even give one they just want to knock you down a peg). Once I have considered their opinion, I might say why I decided to go with what I did if I feel mine is better, but if they press their idea I'm not going to argue. Developers too often think in black and white. I do too sometimes. When they do so they will defend their opinion like a political activist. The only way to get the best opinion to make sure you listen to everyone and take on board all their views, but unless it is something that is going to be used 100s of times a day by 100s of users in 100s of offices then it won't be worth the time to hash out for 3 hours so every stubborn developer can walk away from a meeting like a toddler having a tantrum and not tackle anything else.

Principles to keep in mind

Don't Make Me Think

The first and primary principal is explored by Steve Krug. He felt this principal was so important he actually named his usability book after this principle. "Don't make me (the user) think". This is a nice quick read and worth reading if you get it. It's short, entertaining and succinct. I was turned onto this book in a previous role by a boss who kept it in the work environment. He recommend I read it and I got through it while still working there.

The main idea is that the user having to think is frustrating for the user. Luckily they will stick around on your website even if they find it frustrating, but they will not like it. If they are the user of a product they will learn to find your product frustrating and imagine the grass is greener with a different product. A user who knows what they are looking for should be able to identify the right thing to click on without thinking about it.

The User Doesn't Read

Steve Krug explains that the user does not use your page how you would expect. We often fill our page with carefully chosen text to explain everything. They don't read it. They barely skim it. Krug explains that the user is simply looking for something that vaguely matches what he might be looking for and is obviously clickable. It should be clear when something can be clicked so principle one is taken care of. Don't make the user wonder "Can I click this?". Make it obvious. If the user has chosen wrong well that's what a back button is for. So they can try again. We are not necessarily aware of it but often we scan pages only looking for words that are relevant to what we are looking for. Everything else gets filtered out. Do you remember the adverts at the side of your Facebook wall when you last logged on to Facebook? No? Filtered! That friend of a friend that you met one time called Bex posted again. Do you even remember or did you just skip? Last time you searched for information did you read the pages top to bottom or skip to the paragraph that seemed relevant? I certainly skipped to the paragraph and in research it has become apparent most people do and they don't even realise they're doing it.

In fact many users will not read the page at all. They do the equivalent of asking a member of staff in a department store, they search. I often do this when I am in a hurry and I know that I can go to Google and search and specify what website I want the search to be conducted on, but often you can go to the website and look for a Search box. Many users go straight to this so make sure it is visible and has "Search" as its label so the user doesn't think. Not "Quick Find", "Keyword Search" or anything but just search. This can be the text on the button or it can be to the left of the text box with "Go" on the button.

The User Assumes

This was also something written about by Steve Krug in his book. He calls it muddling through. He points out that a user doesn't get to know your website or product he just figures it out and when something works he sticks to it no matter how buggy. The user then makes up all reasons why it works and often these are far from the truth. My dad was wondering why a certain file had become corrupted. He spoke about applications fighting each other for control over files. He means media player, itunes and other media playing software which all try to make all media files associated with them. He thought one application had tried to keep hold of a file while another application had tried to take control. This was far from what was happening when each application was changing a windows reference table which told you which application to use for each file and what parameters. It couldn't have caused the problem. Krug gives the example of people who type URIs into search engines every time they want a website. It sort of work. It gives them a list of results and often what they want is at the top so even though they don't understand it is a enough to assume that's right and keep going.

Availability and Accessibility

The next principle is about whether the website is up and useable. If your website is not accessible then remember they are just one click away from the competitor. If your page doesn't work on their mobile they can go elsewhere. If your page had broken links then they might end up at a Search Engine... You lost them.

Consistency

This is related to the users assuming they know how the website works. If everything is consistent then when they figure out how one area of the website works then based on that understand they can make an educated guess how another part of the site works with minimal thinking.

Credability

I didn't feel this was really Usability but hey... it's info. The web is full of people who believe the strangest things... like some who believe the earth is flat and the sun revolves around it. Some believe that a ring of Satanists rule the world. So you have to forgive the user that might land on your page and not believe what you're saying. Give statistic, feedback ideally links to places where people can feedback separately like Trip Advisor and Facebook. Give a good About Us page, a telephone number and physical address and people are more likely to believe the site is genuine and trustworthy.

Concise

People won't read text. We already mentioned scanning but if you give paragraphs they just won't bother. If someone is reading this blog then you're a diamond in the rough my friend. It's basically just my notes put up there associated with my name so that one way when I'm like a consultant or something you can search some of these terms, come to my website and message me with work.

Krug also mentions this. He says its his second principle. Get rid of half the worlds ... then get rid of half again. They just won't be read anyway. He has a whole chapter devoted to this and says make everything self evident and you can do away with instructions. Also avoid "happy talk"... things like "Welcome to our page" and "We are about action and reliability". Things which are vague. Get rid of everything that doesn't say anything.

Billboard Design

Krug constantly mentions turning everything into a Billboard. Imagine people are walking past the computer screen as they try to read your website. To help you need to do a few things.

1. Hierarchy - People want to quickly narrow in, on the more reasonable sufficing option. Also the top of the hierarchy should break up the page a in to easy digestible chunks. If they can see a clear hierarchy ... let's say 4 headings. Then they can already ignore 3/4 of the screen. Then they can zoom in on the chosen quarter ... rinse and repeat. Things which are nested in an area should be clearly so. Things which are all children of the same parent should look alike. For example all the departments are children of the navigation menu so should all look alike. Also keep your site name and navigation bar at the top of the hierarchy so people know you're still on the same page. This can also be a link to the home page. This reassures the use that they don't have a loss of options which is incredibly frustrating for the user.
2. Conventions - Stick to conventions. You might feel like being innovative and creative, but if your user sees what they know from elsewhere then they won't have to even think about it. They will just know how to use your site. What's clickable should be obvious it is clickable. For example buttons having edges that make them stick out, links being underlined and in a slightly different colour. This means they can click without thinking.
3. Avoid background noise - When things are two busy it becomes harder to see. Let the colour of background things be a background colour ... for example grey and stuff you want people to read in black and white. Think about how hard it is to read links separated by dark lines.
4. Load quickly - You can establish a better CDN or traffic managers to help pages loads quicker but routing to servers nearer the users. Also preloading some elements. It was discovered that when users experiences a 2 second page load time often 80% of users were lost... 40% after the first two clicks and 40% more a short while after. Users asked said they felt it was broken and the company was probably of poor quality.
5. Reactive - Your site needs to adjust for different devices so people can see it on different sized screens. Some pages that load on a mobile have links so small the user gets frustrated.
6. Use White space - Often with counselling the provider will use silence to calm the patient. In visual design white space is used in the same way. It makes everything look less messy and busy. It can also help divide up things which belong to different areas of the page.
7. Pages Need a Header - Whenever a user comes to a page they need to see the header that matches what they clicked to get there. That way they know they arrived in the right place. The user is never questioning where am I? Which naturally is thinking...

Deep or Wide Navigation

This is a big debate. Should the user be presented with fewer things to consider, but they divide up the pages of the UI / website into larger chunks or should there be more options and divide into smaller chunks.

The reality is somewhere in the middle and there are lot of things to consider as you're going along.

1. Is the using moving around the navigation a lot??? If so a shorter navigation with more options is better because they will get to know it and there are less clicks to get them to where they are going. If however they're only likely to use it once this year then they don't want to have to think them they click links, but they could easily click more links.
2. Krug focuses on the thinking required in doing so. For example if you have a lot of product categories, but most of them are obviously not at all related then the user can easily without thinking filter these out. If however the categories seem to overlap a lot and many pages could easily fall under many different Nav buttons then you need to make it clearer by having fewer options.
3. Deep hierarchies are often more prone to hiding things where a user can't find it.
4. Use breadcrumbs to show where you are, so users don't feel lost. But they are not a great method of navigation so make them small. Steve Krug recommends "You are here" preceding them. Bold the page you're on and make it not a link so you don't think it is somewhere you can go other than here. But don't use it as a title.
5. Use an obvious header which matches the links that took you there so users feel they ended up in the right place

Home Page

Everyone wants a piece of this prime real estate, but there is only so much to go around. Unfortunately business politics often messes up this page having too many people wanting something on it.

As a web usability trainee you want to ensure the following are all obvious:

1. What the page is.
2. What sort of products do you have.
3. What can the user do on this page.
4. Why should I be here and no where else.

The front page should also include:

1. Navigation to take you through the rest of the site.
2. A reason to dig deeper in your website.
3. Something that regularly updates (for SEO).
4. Something visual - walls of text are a big killer of incoming traffic.
5. A place to start if you're going to search.
6. A place to start if you'd rather browse.
7. MAYBE: Social proof like copies of testimonies and customer feedback.
8. MAYBE: Content offers (this can be like a white paper that contains much wanted industry specific content but it's also a great place to explain the value of implementing your service / buying from you). Often you take email addresses before proceeding with this.
9. MAYBE: Success indicators for customers
10. MAYBE: Your product features
11. MAYBE: Resources that you offer. Often you take email addresses before proceeding with this.

Usability Starts With Accessibility

Not everyone has the same level of accessibility as others. So it's really important to consider the different level of different users. Some people with disabilities will find using certain interfaces so difficult they will end up rage quitting. We certainly can't call this usable. A lot of developers are very able than other people so won't immediately think to consider a user who might interact with a computer in a different way, using different devices or the same devices in potentially different ways.

Sometimes this is just a case of knowing how to use your HTML properly in a web interface. So for seeing impaired users having HTML that works well with a sight reading could make all the difference in the world. For user entry for example using different devices could be affected by specifying appropriately whether something is a text input, number input, phone input could work different with different input devices. Naturally this works really well with mobile design where if you were entering in a number then on mobile the number keypad comes up and entering numbers is much easier than if you were to type numbers into a full qwerty keyboard.

Placeholder text

This should not be used in place of labels. Yes it does make the form smaller but it does not work as well with the screen reader and if the user has entered data into the field they can no longer be sure it was the correct field it was entered into and the only way to be sure would be to delete their entry. Also while a field has focus this disappears. Make sure you use form labels to ensure the screen reader can help users with sight impairments.

Keyboard shortcuts

Don't break keyboard shortcuts. HTML gives you plenty without needing to implement stuff through JS but if you want to do things with JS instead that's fine just make sure you put all the shortcuts in place so users who are used to using them can do so. Some accessibility use the back button make sure this only ever goes back one step at a time and don't break this because it can be very frustrating for accessibility users.

Fonts

Where possible don't use set font sizes, use relative font sizes instead. For users with difficulty reading or visual impairments being able to set the front size for their browser can often make sites which would otherwise be easily usable require use of the magnifier which means the user will end up trying to look at the screen through a small window instead of being able to use their full screen. So in CSS you would write as follows:

h1{
    font-size: 2.5em;
}

h2{
     font-size: 1.5em;
}

p{
    font-size: 1em;
}

The following would be bad

h1{
    font-size: 32px;
}

h2{
     font-size: 24px;
}

p{
    font-size: 16px;
}

Also it's important to pick fonts that are easily readable and clear spacing. Arial is often said to have been created to save screen space rather than for readability. Verdana has more spacing between words and characters. You also need to pick a front which has clear round shapes, that doesn't use curves where a letter would normally be straight or straight lines where a letter would normally be curved.

A font should also stand out from its backgound easily using two very distinct colours such as white and black rather than two different degrees of grey. Be aware of common colour blindness. The most common types of colour blindness are inability to distinguish between red and green but also common is the inability to tell the difference between blue and yellow. Some people are completely colour blind and so it's important to really use two clearly different levels of darkness between the font and its background.

Separate Presentation Logic from Content

CSS was designed to take the presentation information away from HTML. Avoid using HTML tags just for presentation function only. Nearly everything can be done with CSS and it has an impact on the screen reader and text based browsing.

Slow Processing Power

Less of a personal impariement. Some users have slow machines. Often with a developer using a top spec development machine this can leave them totally unaware of the experience of a user who might be stuck with Windows XP less than a GB of memory and low RAM. This means that heavy JS libraries could be quite slow for some users. A developer needs to be aware of this and the traffic required to load a page.

Resources for Web Accessability

https://www.w3.org/WAI/

https://developer.mozilla.org/en-US/docs/Web/Accessibility

Good is hard to judge, Bad is obvious

It's often debatable what is good design, but often we don't notice what's obvious about a UI until it is absent. I think this a great site for showing you when something is wrong. It gives you a lot of things to think about and really consider. One of the major take-aways from this experience is the aphorism "don't break the mould". Everyone loves to be unique and different, but this just shows you how people are used to things operating a certain way and when things don't do that they often don't use them right.

https://userinyerface.com/

Usability Testing

This is where you get a single person at a time to use your website for some simple tasks while being watched.

Marketing teams often choose focus groups for this, but having users jointly decide how to do something hides many of the difficulties they might face because they work together.

This should be done early not later.

Don't spend all your testing budget at once. Get less users to test it more often and you will identify more problems that are relevant.

Don't get all the same users. You might like your target market but even that is going to be varied and the more varied you can be with tests the more inhibitors to good usability you will identify.

Conclusion

Okay so most courses I found on this subject were pretty useless, but I concluded stick to Steve Krug's book.