Tuesday, 24 July 2018

Principles of Design - Oh, and Tasks

Well, let us start with tasks. Not so much tasks in relation to getting information, but tasks that need to be done in the system. Let us consider a real world example, such as eating. There are a number of ways that we can go about it, for instance we could cook it ourselves, we could go to the restaurant, or we could order takeaway. We could also choose to go on a diet, but that would be a bit silly. Anyway, each of these tasks have a number of subtasks, and requirements. For instance, with getting takeaway, we need to find out if the store does takeaway, and whether we want Chinese, Thai, Indian, or just plain old fish and chips. We could even go down to the local supermarket and get one of those frozen meals, but they don't tend to be all that filling.

Not quite the task list I'm talking about


The same goes with systems - each of them have tasks, and we need to consider a number of subtasks. For instance, say we want to fly to Kuala Lumpar. Well, as it happens there is an app for that (though a friend is still pining about the fact that there isn't an app for her to find a boyfriend, until I directed her to OK Cupid). Thus, we have a task, so we need to define the subtasks, such as typing in the dates we want to travel, and then choosing from the list of options and deciding whether you wish to go via Singapore, Hong Kong, or go direct with Air Asia (if you can handle budget airlines, which I can't, though Air Asia actually wasn't as bad as I expected). Finally, we need to consider how we are going to pay for it.

So, when it comes to tasks, we need to define what the task is (booking a flight), determine how often it is going to be performed (not too often, unless the user is a frequent traveler), and how long it should take on average. Then we need to consider how a new user will learn how to perform the task, how they would respond to the design, and how intuitive the actions happen to be. Since the task we are attempting to define is actually one that isn't going to be performed all that much by the casual holiday maker, then we need to remember that in a lot of cases they are going to be first time users everytime they want to book a flight. We also need to consider what could go wrong, but that can be problematic because as Murphy's Law states: anything that could go wrong, will go wrong, such as the user experiencing a power outage in the process of arranging the transaction.  However, in determining this, what we do need to consider is whether there will be any other users involved, and whether any third party software is required (such as Paypal for the payments). So, I guess the big question then is, what are the risks?

A Few Principles to Consider

Now it seems as if the world of User Centered Design has created a new word that I have no idea what it means - Heuristic. Basically they are a set of principles that we should keep in mind when developing a piece of software, and they are quite user focused. Now, there isn't actually one set of principles that everybody follows, particularly since there is one lot that has 30 principles, and another with something along the lines of 644. Now honestly, that is getting ridiculous, particularly since they have ceased to be overarching principles, and more akin something you would find in your local law library. Anyway, the ten basic principles that we have gone with are known as Neilson's ten Heuristic Principles (and apparently we have to memorise them for the exam). So, let us now look at then one by one:

Visibility of System Status
This principle basically suggests that the user should always know what is going on, and how long it takes. For instance, if the computer is saving a big file to disk, but doesn't actually tell the user, then the user might just think it has crashed. Further, if we don't know how long it will take, because users are impatient, and expect way too much from computers, then once again they are likely to think the system has crashed.



Match Between the System and the Real World
This really comes doing to being intuitive. Notice how these days email apps look like, well, a letter. Okay, a lot of people probably don't know what a letter actually looks like these days, but that is something that has come back from the time when people actually communicated by what was known as snail mail (because it took a long time to get to where it was going). The idea here is that by using real world symbols, people can intuitively know what the button does. Want a button to stop something, then maybe shaping it like a stop sign will help. Mind you, I'm still a little baffled as to why Microsoft insisted on putting their 'turn the computer off' function under the Start Menu.
User Control and Freedom
The thing is that users really don't want to get locked into doing something, especially if they have gone somewhere where they don't want to go - such as that dodgy website that they have landed on, or they are having second thoughts about sending that email declaring their undying love to the person they have a crush on. The thing is that people need a way to back out of what they are doing, or stop heading down the path that they are heading, and this needs to be taken into account when developing an application.

Consistency and Standards
We really need to be consistent across all platforms, and that applies to the real world as well. For instance, what would happen if one town decided to be different and instead of going on green instead went on red, and stopped on green. Well, confusion is certainly going to reign. The same is the case with computer systems - if there is an accepted standard we should go with that accepted standard, no matter how much we may not like it. Sure, we might hate that envelope as an email, but unfortunately we have to swallow our pride and go with it, instead of experimenting and using Marvin the Paranoid Android instead. Mind you, the Americans seem to have stubbornly refused to go over to the metric system (and the British still drive on the left).

Error Prevention
Simply put, we really can't have the app crash on us, do we? Honestly, how frustrating is that, when you go into the app and it suddenly shuts down because it has crashed. This, in many cases, is a programming issue, and we should be looking for ways in our programs to avoid these errors, particularly since it could result in even more disastrous outcomes than the simple annoyance of not knowing how many people liked your last Facebook post.

Recognition Rather than Recall
This has probably been covered in the previous post, but it is important and should be reinforced. Basically people don't like learning things, and they certainly don't like remembering things (particularly in the days where we have so much information a Google search away). As such, if the user isn't all that regular, or even new, they should be able to use the product without forever going to that help menu, or randomly pressing buttons hoping they get the result that they want.

Flexibility and Ease of Use
So, how many ways is there to copy text in Microsoft Word (or I probably should say Libra-Office, but since I got Word for free, I do happen to be using that). Well, you can go to the menu, select edit, and then select copy; you could right click on the high-lighted text and select copy; or you could simply press ctrl-c. This is what this principle is about - while it should be easy to understand and use for the novice user, there should be shortcuts for the experienced user. In fact, ever since I started computer science I've found myself using even more of these shortcuts (ctrl-B to turn bold on or off).

Aesthetic and Minimalist Design
We call this the 'Google Principle' because Google is the prime example. Basically their home page has very, very little - a search bar and title in the middle, and a few buttons elsewhere. This is in contrast to, say, the old Yahoo page which was just cluttered full of links and whatnot. What the principle does is that it focuses the user on the important part of the page - the search engine, and pretty much discards everything else, namely because it just works as a distraction. There are plenty of other places to put distractions to keep the user on your site, or using your app.

You're probably too young to remember this

Help Users Recognise, Diagnose, and Recover from Errors
This isn't so much the user going somewhere they didn't want to go - that is dealt with elsewhere - no, this is the user doing something they aren't supposed to do, such as entering 'I love pineapples' in the box for the phone number, or typing in some malicious code that will completely wipe your website when they press the 'submit' button. Here, when the user has done something wrong, the computer should not only inform them that they have done something wrong but guide them to do it correctly. Mind you, this warning and guidance shouldn't be:


Help and Documentation
When worse comes to worse, the user should know where to go for help. Mind you, when I was growing up, there was this expectation that men never looked at instructions, and this is probably still true. Sometimes, though, we want to know how to do something, or something has been changed, so instructions not only need to be easily accessible, but also easy to understand. In fact, instructions really should be short, sharp, and shiny, as they say.

Evaluating Everything

So, now that we know what these ten heuristics are (though as I have mentioned there are more), we need to know how to evaluate them. This is where the results of our surveys come in. So, once we have discarded the pointless responses, we can then review them and determine what the real problems are. In fact, when the surveys are constructed, they need to be constructed with these ideas in mind, since it makes it easier to isolate the problems. Mind you, constructing the surveys is also important as we need to be careful not to create loaded questions and the like, or questions that direct the respondent to a certain answer (it is true that strawberry icecream melts faster, doesn't it?). 

So, now that we have identified the issues, what we do is to rate them on a severity scale, and then it can be determined which ones need to be attended to, and which ones can wait. One of the issues is that a lot of the evaluations are performed by usability experts, but they tend to be few in number, and not always regular users of the application. As such, it may be helpful to approach the users directly, considering time and budget constraints of course. Yet, as mentioned, relying entirely upon expert opinion could be a problem in and of itself because, honestly, some experts are only experts because they speak as if they were experts.

Design Principles

Now, these aren't strictly heuristics, rather they are principles that should be taken into account, depending on the context of course. There are quite a few of them, however we will only touch on a couple here:

Principle of Proximity
Basically this principle is about things being close to each other. You know when those really annoying adds pop up when you are playing that game on your phone? You know how when you go to cancel out of it you end up on the Google Play screen? Well, that is the principle of proximity at work, though in a way that is not really what it is supposed to be. Basically, similar buttons should be next to similar buttons (such as copy and paste).
The other aspect is that functions that do similar things should be grouped together. Notice how in word processors all of the font icons are next to each other, and the paragraph styles are also next to each other. Actually, lets illustrate this principle by looking at the toolbar for Blogger, since I am using it at this present time:


So, from left to right, we see the undo and redo buttons, the font and text style buttons, the app buttons, and the paragraph style buttons. It wouldn't do well to have the bold selector next to the block text icon, and the italics icon between the undo and redo icons - it just wouldn't make sense, and it is also confusing. Sure, you could try to be different, but don't expect anybody to actually use your app.

Visibility

There is a very simple way to illustrate this principle:

This 

stands out much more than:

this

The reason being is that visibility is used to catch our attention, therefore more important items should be used to highlight important points. Notice that writers do this using italics and bold (and usually add 'emphasis mine' afterwards). This is because they want to make a point. Notice that links are also highlighted, which us usually done to validate what is effectively fake news.

There are other techniques used as well, such as transparency. Where something is not important, or should actually be put aside (but not removed) for a short period, it should be made transparent. There are lots of other suggestions, such as typeface, colour, and contrast (and also an idea that logos should not take up more than 25% of the screen), but I suspect this makes the point.

Affordance
This is basically the art of making it impossible for people to do the wrong thing. Take socket heads for example (at least here in Australia). They are designed in such a way as to prevent people from putting them in the wrong way. Mind you, there is also the idea that it doesn't matter whether you make something idiot proof, people will just build a better idiot.


Finally, I will finish off with a couple of design laws, the first being Hick's Law. Basically that law states that the more options that are available, the longer it takes for somebody to make a choice. Have you ever been to a restaurant that pretty much serves everything? It takes a lot longer to go through the menu than a place that only does, say, hamburgers. Then again, that is a pretty poor example because if I go to a restaurant with nothing particularly appetising on the menu, it will take ages for me to make a choice. In short, Hick's law pretty much states that when creating menus, get rid of things that aren't really going to be used.

Then we have Fitt's law, which states that the bigger something is, the easier it is to hit. The best example of this is the pedals on your car. Notice that the brake is much, much bigger than the accelerator. This is to stop you from hitting the wrong pedal in an emergency. Anyway, it is generally better if you accidentally hit the brake than accidentally hitting the accelerator because the person that hits you from behind is always going to be at fault (though I wouldn't recommend attempting that on the German Autobahn).


Anyway, that's it for now. Next time it will be back to surveys (because it will probably be examined), though Boolean Algebra won't go astray.
Creative Commons Licence

Principles of Design - Oh, and Tasks by David Alfred Sarkies is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License. This license only applies to the text and any image that is within the public domain. Any images or videos that are the subject of copyright are not covered by this license. Use of these images are for illustrative purposes only are are not intended to assert ownership. If you wish to use this work commercially please feel free to contact me

No comments:

Post a Comment