#begin

Ever since I started working at Dephion I have been doing a lot of user-interface stuff. The team I work in is also called the “front-end” team, but we are not the regular Javascript front-end developers you might expect. We are not designing any webpages, but we use the Unity3D game engine for our front-end.

We need Unity’s 3D capabilities for the best possible mobile experience for our users. I’ve been working with Unity3D for a long time but I have always leaned heavily towards coding and not 2D or 3D design or production. Of course I have made some small models or designed some basic user-interface. But let’s be real, the UI’s I design, as a developer, are true “developer UI’s”.

I would often just make square, flat UI that exposes every possible config value, slider or input. Then the user can decide what to change… right? Haha, no I’ve known for a long time that I’m pretty bad at designing nice, intuitive and user friendly UI.

So, I decided to do something about it, and after searching the web for the best possible books on UI design for webpages and/or mobile apps I found this book: Don’t Make Me Think. A Common sense Approach to Web and Mobile usability by Steve Krug. It got praised a lot in reviews and since I’m not using any JS frameworks or CSS I thought this would be the perfect book. There are many books about design, but lots of them just focus on webpages combined with css, which is something we will probably never use in Unity3D. Yes, there have been things on Unity’s roadmap that indicated they were going to implement css support for Unity, but it will probably take a very long time before they actually implement it, remember nested prefabs?

So, with this blog, I want to kick off a new series; Book reviews. This will be the first entry in the serie and funny enough it’s not about programming but usability. Yet, interestingly, when a technical marvel has a bad UI, it’s still crap, and quality suffers greatly from it.

The way I’m going to structure these blogs is as follows: First I will discuss the general subject of the book and how chapters are layed out to create a smooth storyline. I think that every book does this in the “Preface” so I will probably take a lot of inspiration from the actual preface of the book for this part. Then I will discuss each chapter and end with a conclusion and my opinion of the book. Here I will also highlight what I found particularly interesting and lessons learned.

So, let’s get to it!

 

Introduction:

So this book starts off with two introductory chapters; First a chapter explaining why this is a revisited edition of the first edition that was released in 2000 which is marked as the preface, and a “Read Me First” chapter which is marked as the introduction, and still not a chapter. So let’s discuss these first before we step into the actual content.

In the preface Steve explains why this is a revisited edition of his “Don’t Make Me Think” book he wrote back in 2000. He says he always thought the idea’s in the book are timeless, and should always be applicable, no matter the technology, since this book is about the concept of Usability and not specific technology.

But after getting many, many requests to update the content he gave in, and decided to release a new version of the book that also looked at mobile app development.  The reason was the ever and rapid evolving web technology. People were asking if he would update his book to match the current state of the technology, and so he did…

The introduction explains Steve’s role as a usability consultant. What exactly he does for clients and why, you, the reader are probably not a usability consultant. But, usability is not rocket surgery, so everyone can learn it. He also explains what he changed in the book to make his content apply to mobile apps. He says he sometimes changes the wording from “webpages” to “webpages and mobile apps” and that he slapped “and mobile” on the front cover of the book. I think this is pretty funny, because he did not really change anything right?

He finishes the introduction chapter with his definition of usability, which is the following:

A person of average (or even below average) ability and experience can figure out how to use the thing to accomplish something without it being more trouble than it’s wort.

The rest of the book is separated in 4 overarching categories; First there are some guiding principles which are explained in chapter 1 through 5. Next chapter 6 and 7 explain things you really need to get right to have a nice usability experience. Chapter 8 and 9 discuss how you actually get these things right and what you can do about it. Lastly, chapter 10 through 13 discuss larger concerns and outside influences.

Let’s start with the guiding principles, in chapter 1.

 

Guiding principles

The guiding principles are slit up in 5 chapters. In each chapter Steve explains one of his five most important principles when it comes to usability.

 

Chapter 1: Don’t make me think!

The book starts off with a chapter on the most important principle, which is the same as the name of the book: Don’t make me think (They said It!). Steve explains that if you have a free room in your head to persist anything you read in his book, save at least this one rule in there.

He says that webpages and apps must be obvious, and self-explanatory, to not make him think about what he is doing. Everything should be no more than two clicks away.

Navigation on a website must be clearly visible and not hidden in the sidebar, next to the 5th ad on your website. Buttons must also clearly be clickable. Don’t make black, plain text clickable, make buttons have some kind of border and color with maybe some shading.

He also says to choose simple words for the concepts on your website. The example he gives is the following: An obvious choice of wording for posting job openings would be “Jobs”, less obvious would be  “Employment Opportunities” and what would request the most thought would be “Job-o-Rama”.  It’s that simple, don’t use obscure words just to stand out from other websites because it makes users think!

Then he explains that when you have to fill in a form he likes how feedback or error messages should show in a red color, above or below the field you are currently editing. He also says that, if some selection needs to be made; like selecting a destination for some flight, make that selection some kind of dropdown or allow autocomplete and do not allow the user to type text himself because you will run into all sorts off issues like spell-checking etc.

Steve gives some more examples and then talks why it is so darn important to get the basics right. Well on the internet, competition is just one click away!

 

Chapter 2: How we really use the Web.

I found this chapter rather interesting myself because I never really thought about this properly. While reading this chapter I was constantly thinking; Yeah, this is so how I read and navigate websites haha, I think when you keep reading this part, you will think the same.

Many people design websites in a top to bottom, left to right (depending on language and place on the earth you are) manner, just like we would read a book. So we start at a header somewhere at the top left of the website. This would show the logo and brand of the website, then read to the right, where some kind of navigation menu aught to be and than jump to the left again, yet slightly down and read the categories or some other kind of sub navigation maybe.

Yet this doesn’t correspond to how most people, including me, read webpages. Most people read webpages as if they were newspapers, just scanning for important or interesting words. So we scan left to right, top to bottom and everything diagonal in between in just a matter of milliseconds. If anything of interest catches our eye, we click on it.

Why do we read websites this way? Well Steve has some explanations:

  • We are often on a mission; users are often looking for something really specific on your website so they scan for words that match their quest.
  • Users know they do not need to read everything; Users are only interested in what is relevant for their quest. Irrelevant information is just ignored and not read.
  • Users are good at it; As Steve said, users are trained to read this way by newspapers, and of course the 25 year’ich existence of the Web (for the common user this is, I know it is around much longer).

Steve has some wonderful images in his book on how this process works, where he shows how the designers view their site, and how average users that are looking for specific things view the site. He has blurred out some parts of the website for the different users, which shows it nicely.

And, because we scan pages instead of reading them, we don’t make optimal choices. When we read websites, we are often in a hurry, just looking for something. The penalty for guessing wrong is almost non-existent. You can slam that back button in your browser and you are back where you left off. Additionally, weighing your chances will often not improve your chances of ending up in the right spot, if wording is obscure or the design of a website is bad any click is a mystery. On top of that, guessing is more fun, there’s an element of surprise to this.

The last part of this chapter talks about how we often do not want to figure things out, we muddle through until we know just enough to reach our goals. It’s like reading the manual of your car, no one actually does until you need to replace or fix something; and then still, you scan for the part you are actually interested in.

 

Chapter 3: Billboard Design 101.

Now we know how people actually read webpages (and mobile apps) we can design to match that. Steve calls this Billboard Design, design for scanning, not reading. He explains it by the metaphor of street signs and billboards you might see next to the highway.

To do this he has setup a couple of rules:

Take advantage of conventions: use conventions as much as you can unless you have a very good reason not to. Using conventions will make your site recognizable even though the user might have never seen it. This includes where things exist on the page, how things work and look. As many people often say; we don’t want to reinvent the wheel.

Create effective visual hierarchies: As users on the web and apps are often in a hurry, it is very valuable and important to show simple and effective hierarchies of the content that is on your webpage.

He says to always make use of the correct header sizes, again, stick to conventions on their usage H1>H2>H3. Also position them on prominent places on the page. And, if they are related to each other, you should make it appear so by grouping them together or put them in a clearly defined area. Nesting related information can help too.

Break up pages into clearly defined areas: Steve says it is really important to split (all) your pages into clearly broken up parts. This will help the user better understand what options your site has. A simple example is to always show some header navigation of some sort or a navigation menu. What you also see often, is at the bottom of each page are important keywords separated by category like shipping information, FAQ, Contact etc. Clicking these items will navigate to the correct page.

Make it obvious what’s clickable: Next item on the list is to really make obvious what is clickable. Steve starts by giving some history lessons about this on the web. He says we started with the classic buttons that had a nice box, border and a specific color. But now, we have very nice CSS capabilities to show what aught to be clickable and what is not. We must make great use of this to make our site usable. With CSS we can make clickable items pop out more by changing font, color or size for example. Users do not necessarily expect to see buttons with borders and shading anymore like we had in the windows 2000 / xp era.

Keep the noise down to a dull roar: One of the greatest enemies of easy-to-grasp user-interfaces is cluttered, visual noise. The problem is that users have very varying tolerances for complexity and distractions. Not just on web-pages, but in general. So we must try to design easy websites, else people will put post-it papers on top of your annoying animations or ads. Steve explains 3 categories of visual noise:

Shouting: When everything is shouting for attention, nothing will get it. The truth is that everything can’t be important. On most pages, some specific things are important so we must make them pop out and the rest be a bit in the background to no confuse people.

Disorganization: Pages should have a nice, thought through layout. Never simply slap information anywhere on a page but always try to conform to things like grids in CSS.

Clutter: We all know these pages that show way to much information. Homepages are notoriously cluttered since every stakeholder in the company whats to reserve his spot on it. Steve’s advise is to always start designing your webpage as minimalistic as you can, and slowly add more information when it is actually needed.

Format text to support scanning: Try to format your text to support for better scanning of the pages. Use indentation, bullet points, clearly defined paragraphs, headers and highlight important terms on your page. Another thing I found interesting is that paragraphs on webpages should be short, if it gets to long, separate them into them into smaller ones. Steve keeps hammering on the fact that people are often scanning, and in a hurry to read the content of interest to them. So keep your paragraphs short!

 

Chapter 4: Animal, Vegetable, or Mineral?

This short chapter is all about why users do not really care how many clicks they need to access some piece of information, as long as each click is mindless and unambiguous. Steve’s second law of usability goes as follows:

It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.

Steve says that his rule of thumb is that three mindless clicks are equal to one click that requires thought. A nice example he gives in this regard is this:

Steve is self-employed and has a home office. When he was searching for some new product, the webpage gave him a top-level choice between Home and Office. He always finds this confusing because he does not understand what category he might be in. Funny enough, I’ve experienced this as well when buying a new printer. I think the HP website needs some of Steve’s advice!

Another thing he finds annoying, and I gladly align my opinion on this, is that many pages offer free downloads of articles or reports. But only after you click the link to download it, you are confronted with a login or registration form. This is so darn annoying that I will never fill this in and often skip reading the article. Maybe the article was not that interesting after all.

He ends this chapter with some advice on inherently difficult subjects we need to create webpages for. Sometimes we really need to show difficult to understand and complex information on webpages.

Steve says you should offer some guidance on the page, as long as it’s subtle and not annoying to experienced users. It should be brief, timely and unavoidable.

 

Chapter 5: Omit needless words.

Krug’s third law of usability;

Get rid of half the words on each page, then get rid of half of what’s left.

Steve says to ruthlessly get rid of the words you do not need on your webpage, because it will reduce the noise level of your page. Additionally, it makes the content more useful and prominent plus it gives the benefit of making shorter pages so people can glance the page without scrolling. That’s a benefit for everyone.

To do this, he has two simple rules;

Happy talk must die! We all know those webpages that have a homepage that says something like: Hi there! Welcome to my website blah blah blah…. Steve says to drop this content and make it something more useful. He also mentions that if you are reading content on a page, yet you hear blah blah blah in your mind, it’s most likely happy talk and thus uninteresting. Remove it and everyone will be better off!

Instructions must die! When your website or app requires instructions, you need to do something about your usability! No one will ever read through a massive block of text of instructions. As we discussed in earlier sections, people do not use the web this way. They will scan and muddle through until they get it somewhat right. Even if they can’t figure it our, they will almost never read your instructions, they will scan and muddle again!

 

Things you need to get right

Next are two chapters for what spots you need to hit if you want to have a nice, usable website or app. The next two chapters are an in depth view on navigation and homepage  design. I will try to de-still the information down to some usable information, yet, I encourage you to read them yourself.

 

Chapter 6: Street signs and Breadcrumbs

“People won’t use your website or app if they can’t find their way around it.”

I think everyone knows this; if you cannot find your way on a website, you will most likely go to a competitor who did get his shit together.

In the beginning of this chapter, Steve shows some really nice flowcharts of his thought pattern when navigating through a store like Sears. (We don’t have “Sears” in The Netherlands, however, we have Makro, Sligro, Hornbach, Gamma, Praxis and many other large stores)

Steve gives some example when you are looking for stuff in these stores, it is most often pretty difficult to find the aisle you actually need. The main reason is that many products belong in multiple categories, and when you check the signs on each aisle you are unsure which one it is. So you will try each aisle, and if you don’t find it you will either storm off, or ask some random person who works there. And if that does not work, you are probably pretty pissed.

On the web, we can experience the same thing. We have no sense of scale, we have no sense of direction nor location. Imagine trying to navigate the web without search engines… It’s pretty impossible, only if you know exactly what you are looking for which is almost never.

So never underestimate the value of good navigation because it tells us what’s on a website exactly, how to use the site and Steve even says it gives the user confidence that the people who build the site knew what they were doing. Steve advises to always follow conventions like; Have you logo and tag line in the top left corner of the website. Your navigation menu on the top somewhere, with some additional filtering of categories right below it.

Another very important thing he says is that there are two kinds of users; Users who will use your navigation, muddle through and hopefully find what they are looking for; and users who will instantly gravitate towards your search bar somewhere on the top of each webpage.

Some other advise he has is to have a clear hierarchy in the content you provide. Always think about the fact that the top lever content is most important, and it should not be cluttered with information that is not needed. Users will most likely go about 2 to 3 levels deep into your hierarchy; if they want to dive deeper, they are more likely to use the searchbar instead of manually traversing your hierarchy. So try to keep your hierarchy shallow.

Next Steve says that every page needs a name, just like each street has a name. Without street names, you will get lost very quickly. Also, always put the name of the page on the same spot, just like street signs… and make them prominent!

The last piece of advice Steve gives in regard to good navigation of your app or website is that you must provide the user with so called breadcrumbs. By providing them breadcrumbs they always have a way to navigate back to where they came from. It also shows the user exactly where they are. It’s like having a “you are here” sign in a forest or amusement park. You know where you are and you can easily back-trace your steps.

 

Chapter 7: The Big Bang Theory of Web Design

This chapter is all about the importance of getting people off on the right foot, in other words, your homepage. Steve has some general guideline here, some things you should absolutely do:

Right of the bat, the users must be able to see your site identity and mission. Also the hierarchy of your website must be clearly visible with an additional search box prominently displayed. Next, your home page must tease people to click on certain parts, just like a magazine would do. You can do this by showing feature promo’s, timely content and deals. Another important thing is to display shortcuts to the most visited parts of your website, or maybe the parts you want to steer your users to. For example; software updates or shipping costs. The piece of concrete advise Steve gives is to always show a link to the registration or login, if possible on your site or app.

So this all boils down to show the users what they are looking for. The homepage should be obvious. Also, it must make clear what the user is not actively looking for. The homepage aught to show you all the awesome stuff that is on the website and show clearly where the user should start. But, the most important aspect of the homepage is to establish credibility and trust, because if users do not like your homepage they will often leave. So you must always leave a good impression.

 

Making sure you got them right

Now that we have reviewed the most important things of your website; the navigation and homepage, we can discuss the steps you can take to make sure you got them right. There are two chapters in this part of the book, lets take a look.

 

Chapter 8: The farmer and the cowman should be friends

This chapter is all about biases we, as designers of websites have, about our users and discussions about usability. We all know, and regret, these discussions about how ALL users like certain means of design or navigation. But as a matter of fact, there are so many types of users it is impossible to satisfy everyone’s needs.

Another funny thing Steve points out is that in many meetings about usability of a website there are many different points of view involved. Think about how the CEO, developer, designer and the business developer would preferably design the home page. Steve has some nice screenshots in the book to show the difference. He wants to point out it is always a struggle to find some common ground with all stakeholders.

Steve ends this chapter with a hint to the next and how to actually know for sure if you got the design and navigation right: Testing.

The only way to know for sure you got it right is to run some user tests.

 

Chapter 9: Usability testing on 10 cents a day

The key takeaway here is to keep it simple, so you do enough of it and do it often, and focus groups are not usability testing!

The difference between focus groups and usability tests is that in focus groups a small group of people, usually between 5 and 10 sit and talk about their experience with the product. Focus groups are great for getting feelings and opinions from users. But not so great to get actual usability feedback as with usability tests. With this sort of testing you observe one, a single person, trying to fulfill specific tasks on your website. You are trying to detect what goes smoothly and more importantly, what frustrates them about your website or app. So the main difference between the two is that with usability tests you observe and see how users use things instead of listening to them arguing about it.

Steve says there are three things that are absolute truths  about usability testing:

First, if you want to have a good website or app, you need to do testing… period… There is no way around it. If you do not test, you will find out in production.

Second, it’s better to test 1 user 100% than testing no user at all. What Steve means by this is that testing always works, so testing even 1 user will grant you some insights! Just ask some volunteer to click through it, observe him/her and debrief their findings. Take these things seriously and do something about it.

Third, testing one user early, is better than testing 50 users at the end of a project. Bottom line, start testing as soon as you can, even before you think you really have anything to test. The problem is that people often think testing is a big deal. But if you test often, testing becomes very targeted and small. Do not postpone testing till the last week of your project because many issues could have been found maybe after the first week. Additionally, fixing problems early in the project cost less time and money than later in the project.

Now, how often would you test? Well Steve thinks that every development team should spend one morning a month doing usability testing. To me, this still does not sound much, but it is always better than nothing, right. He says to keep it to one morning a month because you can keep it it simple and thus you keep on doing it. It is also long enough to give you what you need since it is neither to long nor to short. He also strongly advises to pick a designated test day in the month, like the first Friday each month. Everyone on the team will know it and you can built up towards it. The last advantage of having one short test morning each month is that people will most likely attend the test sessions, again they are not too long so people will find it interesting to join them.

How many users would you need for such tests? Well Steve thinks you need about three people. He says three will most likely spot the most pressing issues anyway. When you allow more people in for testing they will often give you similar feedback, so three is about right.

But where and how do you find participants for these tests? Steve says you need to recruit them as you would with any other job opening you have, only is might be a one time job. He says he always likes to recruit people who are not from your target audience.  But don’t forget to get some testers with domain knowledge in the test group as well since they will be able to give you in depth feedback.

The last thing Steve talks about is how to setup a test room with the devices / computers and camera’s. His best advise from this is that you should prefer camera’s that film the user, his facial expressions and hand movements over a simple screen recorder to see what the user is doing on the screen.

This chapter ends with an example test session. This is a very nice, detailed fictional conversation of a host together with a tester which is testing some app. After this session Steve gives some points of interest to make sure you take into your debriefing of the tester. Debriefing is also a very important step in usability testing. His best remark here is this: Focus ruthlessly on fixing the most serious problems first! You don’t have time to fix all issues, so do the serious ones and low hanging fruit first!

 

Larger concerns and outside influences

We are heading towards the last four chapters of the book. The following chapters describe some more overarching principles. The next chapter is a chapter on mobile design and usability. I think this is the first chapter that actually goes into mobile specific stuff.

 

Chapter 10: Mobile: It’s not just a city in Alabama anymore

So finally a chapter dedicated to mobile design. Until now we have always spoken about websites and apps, or just websites. The reason was that the book was originally written from websites only. So let’s take a look at what Steve has to say about mobile design.

The most important thing is: your screen is most likely smaller! Even with our already overcrowded homepages, we need to make it even smaller to fit it all on a mobile screen.

We often solve this by using very short pieces of information that include images or icons. You will be able to click each item to get some more detailed information. So on mobile, more clicks are often required, to get the same amount of information than on a computer. This is not a bad thing per-see since people are use to this on mobile, but the same rule for clicks applied to mobile as well: As long as they are mindless and unambiguous!

Next Steve points out some of the problems with designing both for mobile as for computers; What we used to do is design two products, one for mobile and one for computers. But with modern CSS features we can design one app, with the same source, for both platforms. We must do this! We do not want to keep two source code directories in sync since one will always be newer than the other.

Steve also gives three high level suggestions: First, always allow zooming on mobile. Some resources will still be difficult to convert to mobile, Steve says you should always allow the users to zoom on the mobile version of your app or website.  Second, don’t make people required to enter your app through the homepage. When users click some link of your app on social media; that they think links to a specific article or page. You must allow them to enter your app on that page specifically. Do not force them to enter through your home page only! Third, Always provide a link to the “desktop version” of your website. Sometimes the mobile site hides certain information, and you would want to switch to the desktop version to view it, with a compromise in usability. I’ve encountered this many times myself, that I know for sure some information was on the website but I could not view it on mobile. A quick switch to the desktop version allows me to access this information.

Another well known usability flaw mobile has over desktop computers is the lack of hover functionality. We as designers really can’t forget about this fact. I’ve seen this too many times personally, that specific information was hidden under hover interactions, but there was no replacement for mobile platforms. So although your design might look really nice and thin, your design can become too thin and you loose too much information.

Your app also needs to be learnable. Some apps have some pretty neat gestures built in for extra efficiency. But, people rarely use them since they don’t know about them. If your app has some exotic gestures for increased throughput you should teach your users how to use them in a friendly way. You could add some tutorial for example, which they can revisit at any time.

Steve ends this chapter with some advice on how you can facilitate usability testing for mobile devices. He talks about this specifically since it i much harder to get a decent view on the user since the devices are way smaller. He says you can buy these small camera’s you can attach to your phone which can film the screen and finger movement. The combination of these is very important if you want to understand how your users operate your app. He says he once made such camera himself which you can check out here: http://sensible.com/rocket-surgery-made-easy/.

 

Chapter 11: Usability as common courtesy

This is one of the more abstract chapters in the book. It is about how your website “treats” your users. Steve explains this nicely though an analogy which he calls his “reservoir of goodwill”. This is essentially his state of mind and his motivation to keep muddling though.

He defines it with four concepts:

It’s idiosyncratic: some people have a large reservoir, others have a small one. Just because some people are inherently more curious or patient than others. You cannot take a large reservoir for granted!

It depends on the situation: It might be that your website is very high up the ladder for usability, but when users enter your site coming from a horribly designed website, the reservoir might be empty already.

You can refill the reservoir: When you have a nice website that satisfies the user’s needs hit reservoir will fill up again. You make the user feel like you are looking out for his best interests.

Sometimes a single mistake can empty the entire reservoir; the prime example he gives here, and what I have experienced as well for sure, is that when you enter a website and want to view some content, you are faced with this immense registration form. This will put you off so badly that you leave the website immediately.

Next Steve starts to explain what things diminish goodwill and what actions increase goodwill.

He says that hiding the information I want greatly diminishes it. Don’t hide support phone numbers, shipping rates and prices for example. Also, don’t force your users to format the data correctly for you. Always format the data correctly yourself. Don’t force your users to add spaces in creditcard or phone numbers.

Never ask them for more information than you need. In the current day and age, users are very skeptical when giving out information you don’t need. Most of the time, some nickname and email address is more than enough!  His last mention of something that diminishes goodwill is that a sloppy, disorganized website will put off most users. So step up your usability game!

Steve ends this chapter with things that increase goodwill: it is very important that you know exactly why users use your website or app and what they want to achieve with it. You really need to design your website to support that. The website needs to tell the user what he wants to know, so always be upfront with things like shipping costs for example. You should also try to save your users some steps when you have the option to; an example he gives is you can provide the user with a tracking number for his order, or even better, send a tracking url to his email. And by the way, put your effort into user support…

Another aspect of a great website is that most common questions can actually be found in the FAQ. I think we have all experienced this; some sites have great FAQ sections, while others seem to have put no effort into actually understanding what questions users might have.

Steve also mentions you should provide the user with printable pages. You need to setup your website so a printer can easily print it in the format of the website. Modern CSS has the capabilities to do this. Personally I think this is a bit overrated; I know no one who will print entire webpages, do you?

The last piece of advice Steve has is that you should recover from errors elegantly and when you are in doubt of the users intentions, apologize.

 

Chapter 12: Accessibility and you

The first to last chapter in the book is all about how to design your website with support for less capable users; like people with poor eyesight, or perhaps entirely blind.

I think it is really interesting Steve put in an entire chapter on this since I had never really thought about it. This chapter is really interesting since Steve shines some light on how users actually read with those screen readers.

So for example; your browser most likely has the option to set text size to largest. Please make sure, when users toggle this feature in their browser, your website supports it!

Steve says there are four main things you can do to make it easier for people with disabilities to use your site: Fix the usability issues that confuse everyone! When certain things confuse people without disabilities, they will most likely confuse people with disabilities as well.

Next, read an article or book about it. He has a great example article you can read here. He also provides some example books like: A web for everyone and Web Accessibility: Web Standards and Regulatory Compliance.

The last tip he gives is to take care of the low hanging fruit like putting appropriate <alt=”text”> to all images. Use headers in the correct way and order so H1 is for the main content, H2 for major sections and H3 for subheaders and so forth. Also make sure your forms work with screen readers so add<label> elements to your fields. Put a “Skip main content” button at the beginning of each page and make all content accessible by keyboard. Lastly, use an accessible template and make sure it has high contrast.

 

Chapter 13: Guide for the perplexed

The last chapter is about selling usability to people higher up the management tree. To do this, you need to speak their language, talk about pain points, touch points, KPI’s and CSI or whatever buzzwords your organization uses. Next you also must be able to show the ROI like; after we made this small change we got 30% more visitors on this page and sales went up 6%.

Next he gives some more concrete advice: You should pull your boss, or even the CEO into the usability test sessions. As we have discussed, these sessions are only once a month, they are short, and easy to follow. If you boss, or the CEO comes over to check it out, he will most likely stick a bit longer because of this. Next, make sure you do the first usability change in your own free time and do some testing with volunteers in their free time. By doing this you will be able to kick things off in an accessible way and you can demonstrate the improvement. Another piece of advice Steve gives is that you should make your boss or CEO test competitive websites or apps. When they see the websites of the competition they often see problems with their own which can start the usability frenzy.

He ends this last chapter with few definitive answers: Don’t use small, low contrast type. Always use a high contrast type that varies in size, yet not too small. Don’t put labels inside form fields! Preserve the difference between visited and unvisited links; nowadays browsers do this automatically. An unvisited link is often shown in blue, and visited is shown in purple. Last, don’t float headings between paragraphs. Headings should be close to the text that follows, and further away from text that precedes them.

 

Conclusion

Alright, damn. I thought I was going to write a short review but it went a bit overboard. I think this shows my interest in the book. I really think this is a great book, and anyone who is building an app or website should read this. It’s a short book, about 200 pages, so I think everyone with just a slight interest in usability aught to be able to read through is rather easily.

Things I really like about this book was the writing style and the many concrete examples Steve gives in his explanation. This really makes sense though; it would be really difficult to describe many of the visual tricks he shows in just words. The images really make it complete.

I chose to read this book since other reviews said it did not get to deep into specific technology, but more on the psychology and universal laws of usability. I agree with this 100%. The book shows many generally accepted truths about usability and I think they are perfectly applicable in our awesome Unity3D projects.

What I realy like about this book is the fact that Steve also describes the testing process. I think this is a very good idea. Imagine to read a book on usability, implement all it’s great idea’s but never test anything. This way you will not know how the users respond to them. Having Steve give you some process to follow for testing is really nice. You can implement this process very easily I think.

Now, what I dislike about this book might be surprising; it’s not any of it’s content but they paper / ink used in the printed version I have. The paper or ink used is a bit reflective/glossy so when the light shines on it a certain way, I could not read it. This might sound weird but sometimes I was just having difficulties holding the book in different positions since the light was reflecting off the page in a certain way. This was a bit annoying to say the least.

So to wrap this first review up; Should you read this book if you want to know more about usability? Oh yes, absolutely! This book is really, really great! It will give you some deep insights to think about and apply to the project(s) you are working on. There are many practical, independent of technology, tips and tricks that will really help create a better experience for he user.

My final score for the books would be a 4/5. I would have given it a 5/5 if it weren’t for the reflective font.

#end

01010010 01110101 01100010 01100101 01101110

Hey, sorry to bother you but you can subscribe to my blog here.

Never miss a blog post!

You have Successfully Subscribed!