WHEN I code a site, I prefer to use as much plain HTML as possible. This way, I feel more certain that there are no barriers to anything I write because plain HTML is the "lowest common" technical requirement to use the Web.
However, plain HTML can be quite dull. If you look at the home page of user:number 1, very little happens there to keep people watching. That's fine - the site is primarily an information website and was designed for visitors to find information quickly.
But other websites have different needs. For example, right now I am looking at a photographic gallery and the owner wants smooth transitions and nice effects. To do this, I am programming with Javascript (more correctly, ECMAScript) which is fun. It's an excellent tool for more dynamic displays and for a gallery of artistic photographs (mostly portraits), it's fine. The primary reason for visiting the site is to view the pictures which most people will take a bit of time over. Slow but smoothly animated transitions are acceptable in this case.
But for businesses, where should the line be drawn? How much Javascript should an online store have before customers are turned off?
There are simple rules-of-thumb to be guided by here. The most important thing is not to annoy your potential customers. This means that any transitions should be kept to a minimum. Keep down the total size of the page - many people still use dialup connections and a fast-loading page is always preferred, all else being equal. Finally, ensure that the transitions add to the experience rather than hindering them. So for example, animations can be used to draw the eye towards relevant information; but they should also not be distracting (this fine line is possible - I tested this kind of thing myself in the 1990s).
Testing is the best way to understand where these barriers are for most people. It's possible, but also risky for a designer to rely entirely upon their own judgement - their page load times are probably good and they're being paid to do this. Customers aren't - they are paying for the privilege.
The good news is that even a modicum of Javascript can add a positive experience to browsing.
The only problem is people like me who browse with Javascript turned off and hate having to turn it on again...
There's no pleasing some people ;-)
27 July 2008
14 July 2008
"Producing great search results" comments
I've just been reading an interesting blog article by Jared Spool about information search. This, along with information scent and structure, was my PhD thesis topic. Given the chance to dedicate myself to this topic for several years, I would like to weight in with a few comments about this.
First of all, a minor point: Jared said, "In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users." This is very true indeed. In one of my research's experiments, I found that the most effective way of presenting research results was the least satisfactory. People hated it because it required the most work to make a judgement, but their relevance judgements were the best.
And what was this method of summarising a document?
We found that it was just the title of the page (assuming that it was in some way related to the content and not due to a technical glitch like a 404'd page). We tried a number of different methods of summarising texts and these were all inferior to the title even when combined. For some reason, the summarisation methods interfered with judgements in a negative way which led to less accurate judgements. The summarisation methods we tested were: the initial text (as used by Alta Vista which was popular when my thesis began), keyword embedded text (as used by Google which was becoming big), and keywords. By this time, meta information was already being abused and few documents were workable.
There are other methods such as thumbnails of the page, lists of graphics, but I'm not aware of any research that shows that they improve upon a plain text summary.
Though we didn't test this, I think that a human written summary would provide the best way for humans to judge. Remember that this isn't supposed to be part of a machine's judgement, but rather a human's judgement. Sadly, with the amount of competition for ranking in Google and dynamic pages, there is little chance of a decent system now being developed without immediately being abused. A proper human-readable text summary of a document created by machine is still a long way off.
The main problem is when users try to identify a document's relevance from something that is considerably less than the complete document. To put it into other terms, the problem is whether users can judge the information scent properly. Conventionally, judgements are made using a short text summary or abstraction of the document that contains enough information for accurate discrimination.
Despite all this, people's searches returned relevant documents most of the time regardless of the type of information need; and even better, the "discrimination index". This was a metric we developed to work out the overall accuracy of a judgement. To calculate this, take the number of "hits" (relevant documents that were judged as relevant) and divide by the total number of relevant documents. This gives a proportion of hits. Then take the number of false positives (documents judged as relevant when they are not) and divide by the total number of documents that are not relevant. This is the proportion of false positives. Finally, subtract the proportion of hits from the proportion of false positives. This gives a real number between -1.0 and +1.0 with -1.0 being completely wrong, +1.0 being completely right and 0 being chance and is a nice stabilised figure than can be used across different studies.
You might also be interested in the idea of negative information scent. Pirolli and Card said that there was no such thing: there was only a presence (which would cause movement towards) or absence (which would cause random movements). We found that there was such a thing as negative scent. Something that was perceived as clearly non-relevant would discourage any pursuit.
"The problem with Search is that we force the user to specify their goal in terms of the phrase they think will most likely produce a reasonable result." This is true. See part 1 of my "interface as translators" article which explains how interfaces are two way translators between a user and his or her needs, and a language that the machine needs to use.
From personal experience, a lot of search interfaces are extremely damaged. I'm sure can all think of experiences with flight booking systems that seem designed without careful consideration never mind adequate testing.
For example, I search for a flights on particular days (journey out and return) only to be told that there are no flights available. Okay fine. But why? Is it because all the flights are fully booked (in which case I will either move my dates to quieter weekdays or fly several weeks later), or because the airline just doesn't fly that day (in which case I will try the days before). And if they don't, what days do they fly?
However, the screen remains mute for me. I have to go back (sometimes having to input all my information again which with dates and dodgy Javascript calendars is no fun) and try another date. I tried on a Thursday - would Friday be better? Or Wednesday? Is there only one suitable flight a week? How many are there?
And if I do find a date with seats, is there a cheaper day to travel? Perhaps if I tried the day before... But of course, I don't know flight frequency. Then multiply this by a number of airlines and it becomes a source of frustration that seems as though the airline companies are making it difficult for me to give them money. This is a very bad way to do business: Never make it hard for customers to give you money.
All this is information that a searcher wants. The best flight-booking system I have come across showed dates for both legs of the journey for the entire month along with price. Admittedly it was only a local flight service, but I could instantly see price and availability for a range of dates and adjust my journey accordingly with only a couple of clicks on each date and no waiting for new pages to download.
It was so good that I have flown several times with them and look forward with joy to using their website again because it is so much better.
Still, it's an interesting article and very important. As I have shown, my experience with more complex searches has not been good. I might spend some time developing a prototype flight booking system that works (TM)!
Part 2 has just come out and I will comment on that tomorrow.
First of all, a minor point: Jared said, "In fact, we’re confident that it really takes a lot of hard work and skill to make something that will create a delightful experience for your users." This is very true indeed. In one of my research's experiments, I found that the most effective way of presenting research results was the least satisfactory. People hated it because it required the most work to make a judgement, but their relevance judgements were the best.
And what was this method of summarising a document?
We found that it was just the title of the page (assuming that it was in some way related to the content and not due to a technical glitch like a 404'd page). We tried a number of different methods of summarising texts and these were all inferior to the title even when combined. For some reason, the summarisation methods interfered with judgements in a negative way which led to less accurate judgements. The summarisation methods we tested were: the initial text (as used by Alta Vista which was popular when my thesis began), keyword embedded text (as used by Google which was becoming big), and keywords. By this time, meta information was already being abused and few documents were workable.
There are other methods such as thumbnails of the page, lists of graphics, but I'm not aware of any research that shows that they improve upon a plain text summary.
Though we didn't test this, I think that a human written summary would provide the best way for humans to judge. Remember that this isn't supposed to be part of a machine's judgement, but rather a human's judgement. Sadly, with the amount of competition for ranking in Google and dynamic pages, there is little chance of a decent system now being developed without immediately being abused. A proper human-readable text summary of a document created by machine is still a long way off.
The main problem is when users try to identify a document's relevance from something that is considerably less than the complete document. To put it into other terms, the problem is whether users can judge the information scent properly. Conventionally, judgements are made using a short text summary or abstraction of the document that contains enough information for accurate discrimination.
Despite all this, people's searches returned relevant documents most of the time regardless of the type of information need; and even better, the "discrimination index". This was a metric we developed to work out the overall accuracy of a judgement. To calculate this, take the number of "hits" (relevant documents that were judged as relevant) and divide by the total number of relevant documents. This gives a proportion of hits. Then take the number of false positives (documents judged as relevant when they are not) and divide by the total number of documents that are not relevant. This is the proportion of false positives. Finally, subtract the proportion of hits from the proportion of false positives. This gives a real number between -1.0 and +1.0 with -1.0 being completely wrong, +1.0 being completely right and 0 being chance and is a nice stabilised figure than can be used across different studies.
You might also be interested in the idea of negative information scent. Pirolli and Card said that there was no such thing: there was only a presence (which would cause movement towards) or absence (which would cause random movements). We found that there was such a thing as negative scent. Something that was perceived as clearly non-relevant would discourage any pursuit.
"The problem with Search is that we force the user to specify their goal in terms of the phrase they think will most likely produce a reasonable result." This is true. See part 1 of my "interface as translators" article which explains how interfaces are two way translators between a user and his or her needs, and a language that the machine needs to use.
From personal experience, a lot of search interfaces are extremely damaged. I'm sure can all think of experiences with flight booking systems that seem designed without careful consideration never mind adequate testing.
For example, I search for a flights on particular days (journey out and return) only to be told that there are no flights available. Okay fine. But why? Is it because all the flights are fully booked (in which case I will either move my dates to quieter weekdays or fly several weeks later), or because the airline just doesn't fly that day (in which case I will try the days before). And if they don't, what days do they fly?
However, the screen remains mute for me. I have to go back (sometimes having to input all my information again which with dates and dodgy Javascript calendars is no fun) and try another date. I tried on a Thursday - would Friday be better? Or Wednesday? Is there only one suitable flight a week? How many are there?
And if I do find a date with seats, is there a cheaper day to travel? Perhaps if I tried the day before... But of course, I don't know flight frequency. Then multiply this by a number of airlines and it becomes a source of frustration that seems as though the airline companies are making it difficult for me to give them money. This is a very bad way to do business: Never make it hard for customers to give you money.
All this is information that a searcher wants. The best flight-booking system I have come across showed dates for both legs of the journey for the entire month along with price. Admittedly it was only a local flight service, but I could instantly see price and availability for a range of dates and adjust my journey accordingly with only a couple of clicks on each date and no waiting for new pages to download.
It was so good that I have flown several times with them and look forward with joy to using their website again because it is so much better.
Still, it's an interesting article and very important. As I have shown, my experience with more complex searches has not been good. I might spend some time developing a prototype flight booking system that works (TM)!
Part 2 has just come out and I will comment on that tomorrow.
Interfaces as translators
If you have a computer product that people use, it will have an interface whether it's a website, a desktop application, or an embedded device like an iPod. The interface is the way that people interact with your machine.
Our job is to make this interaction as simple as possible so that your product is easy to use. A hard-to-use product will have a harder time in the market place than an easier one because people will prefer one that just works.
Think of the interface as a translator than converts your user's actions into something that the machine can understand and then obey; and also that converts the machines actions back into something that your users can understand. If the translator is poor, the user's wishes will not be clear to the machine which will not then be able to obey them. Likewise, if the interface communicates the machine's messages confusingly, the user will not be able to understand the machine's state.
Viewing an interface as analogous to a translator allows us to understand interfaces more easily. Syntax refers to the way in which words are structured to give us complete sentences and we can use our analogy to think of the way an interface is structured as its syntax. Semantics (the meaning of words) can refer to the choices that a user makes within the interface.
With these points in mind, structuring an interface can be seen as a process in which it is the job of the designers (i.e., us) to help users create a conversation with your machines. Let's work through an example using a file dialog.
File dialogs are common on just about every GUI. Typically, a user wants to open a document in the current application. This involves several tasks which can be simplified and greatly understood by using the conversation analogy.
User: "I want to look at the file, 'document.doc'"
Computer: "..."
So no good speaking to it. Instead, the conversation with the machine is mediated entirely through the machine's interface.
User: "I want to look at the file, 'document.doc'. The "open file" menu items approximates this. By selecting it, I am telling you that I want "open file" and I guess I will have to tell you the document later."
Computer: "Ok, you want to open a file somewhere. Here are some files" (a dialog appears)
User: "You are saying that I have to specify which file to select from these options. When I specify a file, I will tell you and you will 'open' it for me."
From this conversation, you can see a few minor issues exist. For the conversation to occur, the user needs to understand the interface's syntax: first tell the machine what action you want to do, then tell it where to (i.e., what file), and finally tell it that you have chosen what you want.
But a better conversation might be like this:
User: "The last file I opened? I want to look at it again."
Computer: "Ah ok. I'll open it for you to view."
This is a simler dialog and is achieved when the user selects the 'recently opened files' option somewhere (often in the 'file' menu). It's helped by the fact that the user wanted the last file he or she opened but the problems start when users want to engage in a richer dialogue:
User: "That file I made 6 months ago about my gardening programme - I want to look at it again. FYI, I viewed it last month."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: No, not those. It has my gardening programme on it and I need to know if I should water my roses today."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: "Oh..."
And this is not a good conversation. Recent file lists can be useful but only so much. Working with a computer can be frustrating because it has an extremely limited and filtered ways of understanding our communications.
I'll cover a better example in the next part of this article which will show how we can generate a system-wide usability analysis framework using this idea.
Our job is to make this interaction as simple as possible so that your product is easy to use. A hard-to-use product will have a harder time in the market place than an easier one because people will prefer one that just works.
Think of the interface as a translator than converts your user's actions into something that the machine can understand and then obey; and also that converts the machines actions back into something that your users can understand. If the translator is poor, the user's wishes will not be clear to the machine which will not then be able to obey them. Likewise, if the interface communicates the machine's messages confusingly, the user will not be able to understand the machine's state.
Viewing an interface as analogous to a translator allows us to understand interfaces more easily. Syntax refers to the way in which words are structured to give us complete sentences and we can use our analogy to think of the way an interface is structured as its syntax. Semantics (the meaning of words) can refer to the choices that a user makes within the interface.
With these points in mind, structuring an interface can be seen as a process in which it is the job of the designers (i.e., us) to help users create a conversation with your machines. Let's work through an example using a file dialog.
File dialogs are common on just about every GUI. Typically, a user wants to open a document in the current application. This involves several tasks which can be simplified and greatly understood by using the conversation analogy.
User: "I want to look at the file, 'document.doc'"
Computer: "..."
So no good speaking to it. Instead, the conversation with the machine is mediated entirely through the machine's interface.
User: "I want to look at the file, 'document.doc'. The "open file" menu items approximates this. By selecting it, I am telling you that I want "open file" and I guess I will have to tell you the document later."
Computer: "Ok, you want to open a file somewhere. Here are some files" (a dialog appears)
User: "You are saying that I have to specify which file to select from these options. When I specify a file, I will tell you and you will 'open' it for me."
From this conversation, you can see a few minor issues exist. For the conversation to occur, the user needs to understand the interface's syntax: first tell the machine what action you want to do, then tell it where to (i.e., what file), and finally tell it that you have chosen what you want.
But a better conversation might be like this:
User: "The last file I opened? I want to look at it again."
Computer: "Ah ok. I'll open it for you to view."
This is a simler dialog and is achieved when the user selects the 'recently opened files' option somewhere (often in the 'file' menu). It's helped by the fact that the user wanted the last file he or she opened but the problems start when users want to engage in a richer dialogue:
User: "That file I made 6 months ago about my gardening programme - I want to look at it again. FYI, I viewed it last month."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: No, not those. It has my gardening programme on it and I need to know if I should water my roses today."
Computer: "You last opened files with these names: 'TV schedule.doc', 'letter to Aunt Peg.doc', 'list of CDs.doc' and 'shopping list.doc'"
User: "Oh..."
And this is not a good conversation. Recent file lists can be useful but only so much. Working with a computer can be frustrating because it has an extremely limited and filtered ways of understanding our communications.
I'll cover a better example in the next part of this article which will show how we can generate a system-wide usability analysis framework using this idea.
13 July 2008
Tutorial scripts
I've had some time to think about video tutorials for usability and they certainly seem possible. So far, I have only 6 planned and they will be between 5-9 minutes long. They are short but sites like YouTube have a limit on video length. This time should be enough to get the most important points across. Besides, I think that most people viewing them won't have time to sit down and watch a leisurely 50 minute video. A small chunk will be plenty for them because our target audience is developers and project managers who need the information quickly.
It was fun to script too. I have done two so far though the storyboards have yet to be done. I can pass this off to our multi-media expert who knows how to edit video and make excellent presentations. Of course we will be working to a tight budget but that won't make the quality suffer. I'm sure that user:number 1 can produce something very useful to a lot of people.
Then we would have to work out where to release. The obvious candidate is YouTube who can host the video for viewing on our own website; but there is also Showmedo who seem to be appropriate.
It was fun to script too. I have done two so far though the storyboards have yet to be done. I can pass this off to our multi-media expert who knows how to edit video and make excellent presentations. Of course we will be working to a tight budget but that won't make the quality suffer. I'm sure that user:number 1 can produce something very useful to a lot of people.
Then we would have to work out where to release. The obvious candidate is YouTube who can host the video for viewing on our own website; but there is also Showmedo who seem to be appropriate.
11 July 2008
Project management for usability studies
When I was forming user:number 1, I realised that to be a successful business, the company would have to understand clients' business issues. This is absolutely crucial. There is no point me coming in an making recommendations that are impossible for a client to implement. In business, we are not aiming for perfection: we are aiming to improve. Some clients do have the resources to get perfection, but in my experience, this is rare. Most have a limited amount of resources and within that constraint, they need to get the best that they can.
Communication is probably the biggest hurdle. user:number 1 works around this by offering good communication facilities for our clients.
When a project has begun, we record the details onto our customised webapp. It's quite a simple application but quite powerful. Our projects are divided into milestones which we agree with the client. These can be large ones (one may even cover the entire project if small enough), but most commonly are smaller sub-tasks (such as: gather user requirements or complete user testing). When a milestone is completed, our application goes to work properly.
During the project proposal, each milestone will be identified with a person or group of people within the client company. These are the stakeholders to each milestone - those people who have a working interest in the milestones completion. Perhaps it's a project manager who wishes to know when the user requirements have been gathered so they can use the information for some other purpose: or perhaps it's the entire development team who need to know the latest prototype so they can begin designing its architecture. Either way, it can be an arbitrary number of people.
When a milestone is 100% completed, all of the stakeholders are emailed and informed of the completion. That's good and keeping them informed, but they often need information. All our projects have a project key and a password which they can use to log in to the project management site. Here, all stakeholders will be able to view the entire project, download the proposal and view the milestones. Stakeholders can also query us directly about each milestone.
For completed milestones, reports will be available for download and viewing. There are two types of report: the full report, which contains all the information we have gleaned and goes into much detail; and the summary which is both a Flash presentation or a PowerPoint/OpenOffice Impress document. The summary contains only the most pertinent points of our research as detailed by the stakeholders in the proposal. So the above project manager will get an overview of the user requirements (for example, typical user tasks and their relative frequencies and, if possible, marketing information. If the development group will want to know about the main aspects of a prototype rather than the fine detail so this is what they would get.
To me, this seems like a better system than just sending a final report to a single person at the end of the project. Stakeholders can choose whether they wish to view the information or not; and if so, to the level of detail that suits their job.
So user:number 1 is geared towards being an effective and efficient service that integrates with our clients' practices. We aim to be a totally transparent partner to our clients. As soon as we have the details, we work and they get the information they need as soon as it is available. Our job is to take the burden of usability testing from a company - we have the skills and expertise to do the work and we can do it far more cheaply than it would take for an employee to do it. In some companies, hiring us for a medium-sized evaluation would be far cheaper than just advertising for candidates.
If you are interested in us working for you, you can contact us here.
Communication is probably the biggest hurdle. user:number 1 works around this by offering good communication facilities for our clients.
When a project has begun, we record the details onto our customised webapp. It's quite a simple application but quite powerful. Our projects are divided into milestones which we agree with the client. These can be large ones (one may even cover the entire project if small enough), but most commonly are smaller sub-tasks (such as: gather user requirements or complete user testing). When a milestone is completed, our application goes to work properly.
During the project proposal, each milestone will be identified with a person or group of people within the client company. These are the stakeholders to each milestone - those people who have a working interest in the milestones completion. Perhaps it's a project manager who wishes to know when the user requirements have been gathered so they can use the information for some other purpose: or perhaps it's the entire development team who need to know the latest prototype so they can begin designing its architecture. Either way, it can be an arbitrary number of people.
When a milestone is 100% completed, all of the stakeholders are emailed and informed of the completion. That's good and keeping them informed, but they often need information. All our projects have a project key and a password which they can use to log in to the project management site. Here, all stakeholders will be able to view the entire project, download the proposal and view the milestones. Stakeholders can also query us directly about each milestone.
For completed milestones, reports will be available for download and viewing. There are two types of report: the full report, which contains all the information we have gleaned and goes into much detail; and the summary which is both a Flash presentation or a PowerPoint/OpenOffice Impress document. The summary contains only the most pertinent points of our research as detailed by the stakeholders in the proposal. So the above project manager will get an overview of the user requirements (for example, typical user tasks and their relative frequencies and, if possible, marketing information. If the development group will want to know about the main aspects of a prototype rather than the fine detail so this is what they would get.
To me, this seems like a better system than just sending a final report to a single person at the end of the project. Stakeholders can choose whether they wish to view the information or not; and if so, to the level of detail that suits their job.
So user:number 1 is geared towards being an effective and efficient service that integrates with our clients' practices. We aim to be a totally transparent partner to our clients. As soon as we have the details, we work and they get the information they need as soon as it is available. Our job is to take the burden of usability testing from a company - we have the skills and expertise to do the work and we can do it far more cheaply than it would take for an employee to do it. In some companies, hiring us for a medium-sized evaluation would be far cheaper than just advertising for candidates.
If you are interested in us working for you, you can contact us here.
Movies!
Unknown to readers here, I used to do some acting. I was in a couple of movies (just student films, nothing like Hollywood) and I had the idea of producing some short video clips of usability testing. There are a few out there but not many. I think a well-produced and announced series of videos would be useful for a lot of people who wish to know more about usability testing. Obviously they would be sponsored by the company, but that's okay. The main problem is finding the time...
Breaking into usability
How does a person break into usability?
This question came to me as I was reading an article recently about contract employment and I remembered a post I made to Google Groups some years back to comp.human-factors. My question came about because I had received my PhD in human-computer interaction from Cardiff University's School of Psychology. At the time, I had some professional (i.e., commercial) experience in the field, but only for short contracts. I had also applied for jobs in usability companies thinking that my qualifications would get me a "foot in the door". However, the truth was that I wasn't invited for interviews to the companies I applied for. It is difficult to get into the field though it is hard to know why.
I found that asking for feedback from the companies I applied to was a good idea. Quite often, they would highlight deficiencies in my curriculum vitae (for example, I put my professional experience under the heading "Industrial experience" and was told that I was turned down because I had no stated commercial experience).
So since then, I have completed a number of contracts of differing terms and have now formed my own usability company because it's still hard to get interviews. The hardest part for this will be marketing and advertising - making the people who make the decisions aware of the company and the work it can do.
My advice is to realise that a lot of employers don't really know what usability is. I would try to put together a number of sites into a portfolio, receives critiques and use them well, and put yourself forward as a graphic designer with usability skills. I'm quite serious - just being demonstrably proven in the field will not be enough. Anyone wanting to enter the field needs to be multi-skilled to fit into the different concepts that people have of usability and meeting these will not hurt.
Work based experience is generally seen as more important than educational (this report is interesting reading), though sometimes it is not enough for a competitive field. From my own experience in this field, I would say that qualifications are actually of little use when compared to employment (and by employment, I mean permanent work for companies rather than contracts).
This question came to me as I was reading an article recently about contract employment and I remembered a post I made to Google Groups some years back to comp.human-factors. My question came about because I had received my PhD in human-computer interaction from Cardiff University's School of Psychology. At the time, I had some professional (i.e., commercial) experience in the field, but only for short contracts. I had also applied for jobs in usability companies thinking that my qualifications would get me a "foot in the door". However, the truth was that I wasn't invited for interviews to the companies I applied for. It is difficult to get into the field though it is hard to know why.
I found that asking for feedback from the companies I applied to was a good idea. Quite often, they would highlight deficiencies in my curriculum vitae (for example, I put my professional experience under the heading "Industrial experience" and was told that I was turned down because I had no stated commercial experience).
So since then, I have completed a number of contracts of differing terms and have now formed my own usability company because it's still hard to get interviews. The hardest part for this will be marketing and advertising - making the people who make the decisions aware of the company and the work it can do.
My advice is to realise that a lot of employers don't really know what usability is. I would try to put together a number of sites into a portfolio, receives critiques and use them well, and put yourself forward as a graphic designer with usability skills. I'm quite serious - just being demonstrably proven in the field will not be enough. Anyone wanting to enter the field needs to be multi-skilled to fit into the different concepts that people have of usability and meeting these will not hurt.
Work based experience is generally seen as more important than educational (this report is interesting reading), though sometimes it is not enough for a competitive field. From my own experience in this field, I would say that qualifications are actually of little use when compared to employment (and by employment, I mean permanent work for companies rather than contracts).
Usability and aesthetics
I my usability work, I have often come across clients and employers who confuse my field with that of graphic design. To be clear, graphic designers are primarily artistic and can produce some of the most breathtaking websites around.
There is one artist whose work as a graphic designer I particularly admire and I sometimes go there for inspiration. The main problem is that the websites are all in Flash which can be slow to load, impossible to resize, and whose contents are not indexed by search engines. These are not absolutely fatal issues, but they don't help.
Usability on the other hand is quite focused. It can be measured objectively against stringent criteria and is closely related to psychology (the first investigators into human-computer interaction were mostly cognitive psychologists though it has since become more multi-disciplinary). But should usability people ignore aesthetics?
Some say that they should Jef Raskin felt that usability was the primary key to any human to computer interaction: without it, such interaction would always be a failure. Aesthetics came second to usability concerns. Others like the clients and customers I have mentioned above feel that usability is just a branch of graphic design. Indeed, I turned up to a firm in Texas for 2 weeks of work once. They said they wanted a usability expert but really wanted someone with an artistic eye. This was a failure in requirements gathering that I have since not repeated.
But most design these days occurs within a team. It is very rare that a single person undertakes to design an entire product. Within the ideal team, there should be experts on all aspects: designers, programmers, and usability experts to fly the standard for the users who can sometimes be forgotten in the rush to produce excellent work. However, all members of the ideal team should know something about the demands of the other team member's field. For myself, I have an appreciatin of art though I do not claim to be a graphic designer. I like taking photographs and some of them are not too bad, though I am not Henri Cartier-Bresson (and his Magnum Photos.
Likewise, I am no Donald Knuth, but I know a little bit about programming and have produced my own program (for example, SalStat, indeed enough to know what things are and are not possible when building a product. When producing work, I know when something is demanding the impossible.
At user:number 1, I often find that the aesthetics are extremely important in a customers mind and I have to pay attention to them. This is no problem because in my view and experience, they can be easily fitted together with a usable interface that is programmatically possible. All this means that customers can have the product they desire. Indeed, I often find that in programming terms, a more usable interface is curiously easier to program and design around. Indeed, I have contacts within the design world that I can bring to a design specification so that their work along with ours produces interfaces that are not just wonderful to look at, but are also simple to use.
There is one artist whose work as a graphic designer I particularly admire and I sometimes go there for inspiration. The main problem is that the websites are all in Flash which can be slow to load, impossible to resize, and whose contents are not indexed by search engines. These are not absolutely fatal issues, but they don't help.
Usability on the other hand is quite focused. It can be measured objectively against stringent criteria and is closely related to psychology (the first investigators into human-computer interaction were mostly cognitive psychologists though it has since become more multi-disciplinary). But should usability people ignore aesthetics?
Some say that they should Jef Raskin felt that usability was the primary key to any human to computer interaction: without it, such interaction would always be a failure. Aesthetics came second to usability concerns. Others like the clients and customers I have mentioned above feel that usability is just a branch of graphic design. Indeed, I turned up to a firm in Texas for 2 weeks of work once. They said they wanted a usability expert but really wanted someone with an artistic eye. This was a failure in requirements gathering that I have since not repeated.
But most design these days occurs within a team. It is very rare that a single person undertakes to design an entire product. Within the ideal team, there should be experts on all aspects: designers, programmers, and usability experts to fly the standard for the users who can sometimes be forgotten in the rush to produce excellent work. However, all members of the ideal team should know something about the demands of the other team member's field. For myself, I have an appreciatin of art though I do not claim to be a graphic designer. I like taking photographs and some of them are not too bad, though I am not Henri Cartier-Bresson (and his Magnum Photos.
Likewise, I am no Donald Knuth, but I know a little bit about programming and have produced my own program (for example, SalStat, indeed enough to know what things are and are not possible when building a product. When producing work, I know when something is demanding the impossible.
At user:number 1, I often find that the aesthetics are extremely important in a customers mind and I have to pay attention to them. This is no problem because in my view and experience, they can be easily fitted together with a usable interface that is programmatically possible. All this means that customers can have the product they desire. Indeed, I often find that in programming terms, a more usable interface is curiously easier to program and design around. Indeed, I have contacts within the design world that I can bring to a design specification so that their work along with ours produces interfaces that are not just wonderful to look at, but are also simple to use.
10 July 2008
The serial position effect
Here is some basic psychology for those interested. It concerns memory and how it can be used for good design. It is already widely used in marketing and may be useful.
The serial position effect concerns how well something is remembered. It came from experiments where participants were given a list of things to remember and asked to recall them as best as they could. Numerous studies found that items at the start and at the end of the list were recalled best: items in the middle were recalled less well.
Why? The first-presented items may be processed to a greater degree. There are many explanations for this, but a useful one is that later items are similar and so are processed less because the mind prefers novel stimuli - another reason for my website's layout being different. Later items are also closer to recall but this is a poor explanation - quite possible, with repetitive stimuli, later items are encoded using elements from previous items (much like video compression) which causes a degree of the earlier items being "written over". Later items are not written over because similar stimuli are not presented for them to be written over with. Anyway, this is one explanation and there are many out there. The important thing to remember is that the earliest and latest items are remembered best.
What use is this to interface design?
Quite often, people are asked to remember things. For example, if using SPSS to analyse statistical data, I would have to remember the design of the experiment and the nature of each variable (how many levels, what are the levels, is the variable within- or between-subjects, the ANOVA model, etc). SPSS helpfully puts up a dialog but I have to remember all this information and input it. The serial position effect says that the first and last information I encounter will be remembered best so the most important parts need to be placed there. With some other tasks, I need some information and can work out others in the dialog. In this case, it is best to present the essential information first and last, and the information that can be worked out in the middle. Using the SPSS example above, I can work out the levels of the variable in the dialog itself, so those can be left in the middle.
Doing this reduces the demands of the task. This means that it is less likely to encourage errors or even "rollbacks", when a user has to quit the dialog and go back to find the information (often writing it to a piece of paper to aid recall).
btw, I dislike dialogs enormously. That's another article.
The serial position effect concerns how well something is remembered. It came from experiments where participants were given a list of things to remember and asked to recall them as best as they could. Numerous studies found that items at the start and at the end of the list were recalled best: items in the middle were recalled less well.
Why? The first-presented items may be processed to a greater degree. There are many explanations for this, but a useful one is that later items are similar and so are processed less because the mind prefers novel stimuli - another reason for my website's layout being different. Later items are also closer to recall but this is a poor explanation - quite possible, with repetitive stimuli, later items are encoded using elements from previous items (much like video compression) which causes a degree of the earlier items being "written over". Later items are not written over because similar stimuli are not presented for them to be written over with. Anyway, this is one explanation and there are many out there. The important thing to remember is that the earliest and latest items are remembered best.
What use is this to interface design?
Quite often, people are asked to remember things. For example, if using SPSS to analyse statistical data, I would have to remember the design of the experiment and the nature of each variable (how many levels, what are the levels, is the variable within- or between-subjects, the ANOVA model, etc). SPSS helpfully puts up a dialog but I have to remember all this information and input it. The serial position effect says that the first and last information I encounter will be remembered best so the most important parts need to be placed there. With some other tasks, I need some information and can work out others in the dialog. In this case, it is best to present the essential information first and last, and the information that can be worked out in the middle. Using the SPSS example above, I can work out the levels of the variable in the dialog itself, so those can be left in the middle.
Doing this reduces the demands of the task. This means that it is less likely to encourage errors or even "rollbacks", when a user has to quit the dialog and go back to find the information (often writing it to a piece of paper to aid recall).
btw, I dislike dialogs enormously. That's another article.
Our website design
So why is user:number 1's website designed like it is and not like all the others?
After looking around, our website is very different to other usability companies. Typically, a usability company will have a standard 2 column layout: header at the top with logo at top left, company name/aim/niche at top right, a narrow navigation column on the left and a wide area of text content to the middle and right side. Sometimes, there are nice pictures, but quite often there are none.
A quick bit of user testing showed one thing to me. Most people are not in the slightest bit interested in usability companies. We could be talking a different language for all they care and this includes people who hire us. I was surprised by the complete absence of interest. Of course, folks are very interested when we do our work well and a product works without them having to think too much, but other than that, we are on to a loser.
This was shown by the lack of reading of the main text content. This is quite disturbing really because it shows that potential customers probably won't read or absorb much of the main page. Yes, they will if it is a standard test and they are given a specific task to find a particular piece of information, but that's flawed. Users would have to be given the task of "look through 10 usability company websites and then 10 more. Then remember what the ninth one said." I bet that the primacy and recency effects come into play and users only remember the first or most recent sites they visited.
So in the best tradition of performance based HCI, I've reduced the cognitive demands of the site by reducing the amount of information on the page. This means a distinct lack of text and bullet points with links to more detailed pages should anyone want to know more. My experience with e-learning for postgraduate medical students also helps here because they, like business people, are busy too and don't have the time to wade through piles of information. Instead, they need the information they want presented as concisely as possible.
This means that there is not much to actually read on each page but that's okay. Links to more information are present.
But the websites were also boring. Unless I am fascinated by a subject, I don't like being faced with pages of text. Perhaps we in usability companies assume that everyone else has the same fascination as us, but they don't and it's a fact.
So the design also attempts (not sure how successfully though!) to reduce page boredom by using lots of white space around the edge to draw the eye into the centre. On the left hand side is a nice picture which hopefully conveys some of the text's meaning. The navigation bar is on the top with indicators of the current page / section and little else. On the right of the picture, occupying 35% of space, is the main text which as I have said is brief and can be assimilated quickly. Underneath is list of link to the left and the logo to the right.
In this, I was inspired by some wonderful flash-based sites by a graphic artist. In terms of usability, they are not so good but they looked wonderful. What I wanted to do was to have a site that looked pleasing and relaxing upon being visited, but one that also communicated information very effectively and was still usable and accessible.
Conventional practice always puts the logo at the top left hand side where most people (those whose written language read from left to right) set their gaze according to eye-tracking studies. To me, a logo is much like an advert and can easily be dismissed automatically without being absorbed. Instead, I have put the name and type of company there. The logo being bottom right is hopefully where the eye falls towards the end of its initial journey. I'm hoping that the primacy and recency effect encourages strong remembering of the company because in both places, the company's name are there.
All fonts are relatively sized and all images have alternative text. Being so concise, users with screen readers should also be able to whip through a page more quickly too.
I guess time and more testing will show if this idea works, but for the time being it seems to be doing okay.
After looking around, our website is very different to other usability companies. Typically, a usability company will have a standard 2 column layout: header at the top with logo at top left, company name/aim/niche at top right, a narrow navigation column on the left and a wide area of text content to the middle and right side. Sometimes, there are nice pictures, but quite often there are none.
A quick bit of user testing showed one thing to me. Most people are not in the slightest bit interested in usability companies. We could be talking a different language for all they care and this includes people who hire us. I was surprised by the complete absence of interest. Of course, folks are very interested when we do our work well and a product works without them having to think too much, but other than that, we are on to a loser.
This was shown by the lack of reading of the main text content. This is quite disturbing really because it shows that potential customers probably won't read or absorb much of the main page. Yes, they will if it is a standard test and they are given a specific task to find a particular piece of information, but that's flawed. Users would have to be given the task of "look through 10 usability company websites and then 10 more. Then remember what the ninth one said." I bet that the primacy and recency effects come into play and users only remember the first or most recent sites they visited.
So in the best tradition of performance based HCI, I've reduced the cognitive demands of the site by reducing the amount of information on the page. This means a distinct lack of text and bullet points with links to more detailed pages should anyone want to know more. My experience with e-learning for postgraduate medical students also helps here because they, like business people, are busy too and don't have the time to wade through piles of information. Instead, they need the information they want presented as concisely as possible.
This means that there is not much to actually read on each page but that's okay. Links to more information are present.
But the websites were also boring. Unless I am fascinated by a subject, I don't like being faced with pages of text. Perhaps we in usability companies assume that everyone else has the same fascination as us, but they don't and it's a fact.
So the design also attempts (not sure how successfully though!) to reduce page boredom by using lots of white space around the edge to draw the eye into the centre. On the left hand side is a nice picture which hopefully conveys some of the text's meaning. The navigation bar is on the top with indicators of the current page / section and little else. On the right of the picture, occupying 35% of space, is the main text which as I have said is brief and can be assimilated quickly. Underneath is list of link to the left and the logo to the right.
In this, I was inspired by some wonderful flash-based sites by a graphic artist. In terms of usability, they are not so good but they looked wonderful. What I wanted to do was to have a site that looked pleasing and relaxing upon being visited, but one that also communicated information very effectively and was still usable and accessible.
Conventional practice always puts the logo at the top left hand side where most people (those whose written language read from left to right) set their gaze according to eye-tracking studies. To me, a logo is much like an advert and can easily be dismissed automatically without being absorbed. Instead, I have put the name and type of company there. The logo being bottom right is hopefully where the eye falls towards the end of its initial journey. I'm hoping that the primacy and recency effect encourages strong remembering of the company because in both places, the company's name are there.
All fonts are relatively sized and all images have alternative text. Being so concise, users with screen readers should also be able to whip through a page more quickly too.
I guess time and more testing will show if this idea works, but for the time being it seems to be doing okay.
09 July 2008
Welcome
Welcome to user:number 1!
This journal will be a series of short articles about usability relating to my consultancy, user:number 1. We specialise in offering competitively priced offshore user testing, but this journal will discuss some of the things about usability that I have discovered over the years.
As a background, I am the founder of the consultancy and took my PhD at Cardiff University where I was supervised by Professor Stephen Payne (he of the task action grammar). I spent a few happy years there researching the usability of web search engines and found some interesting results. Then, one day in September, after being examined by Andrew Howes and Alan Dix (and John Pearce asleep behind me as chair!), my thesis was accepted.
In my time, I have done commercial consulting and research into e-learning for postgraduate medical students. I decided recently to take my skills more permanently into the market because I have a lot of research methods experience that could really help businesses become competitive.
Some articles here will be quite brief and others may be lengthy. The first one I have will focus on considering computer interfaces as a language translator. This sounds strange, but it can help an analyst understand how interfaces work before being committed to time-consuming and expensive user testing.
Subscribe to:
Posts (Atom)