So, part of what I have been doing recently involves analysis of certain Web applications and really identifying areas of improvement in terms of user interaction and user experience. So, here are some of the things that I’ve learned along the way. Some of them may be obvious, but there are also things which are far too easy to overlook.Not everyone is the sameWorking with programmers there is a certain mindset that you encounter. I must confess that I often display this myself!
“I know what I’m doing, I have read the W3C standards, and I am making the app that everyone will want to use - and they will use it in the same way which I do”
Application development would be so much easier if this were true! Unfortunately, the ultimate truth is that people are not logical, even when you think they are. And, whilst everything you have read from Nielson suggest that users will want to use your app in a particular way, you will find a surprisingly large number of those who don’t! As an example, during the development of GMail, the developers identified half a dozen different ways that people would use it to manage their e-mail.
I don’t want to pretend I’m a user, I would have to pretend to be stupid.
Okay, perhaps thats a bit of an unfair statement, but it underlines the point - the user is likely to try and do things with your Web applications which are irrational and counter-intuitive. Its up to you to anticipate this and be prepared to accomodate this.A good example of this was seen at recent user labs we ran, looking at some of our Web applications. In this case we had a multi-page form, with a stepped progress indicator along the top of the page. It was quite surprising to see the number of users who would try to click on this progress indicator in order to navigate between the pages. In such a situation you have two options:
- Add that functionality to the proress indicator
- Look at the copy text and visual style of the indicator - why are people thinking that it is a link/button and how can this be reduced?
Either could be an acceptable solution. In our case we went with the second one, partly because it was a quicker fix, and partly due to issues with the underlying architecture which would make the first option unfeasable.So, part of what I have been doing recently involves analysis of certain Web applications and really identifying areas of improvement in terms of user interaction and user experience. So, here are some of the things that I’ve learned along the way. Some of them may be obvious, but there are also things which are far too easy to overlook.Not everyone is the sameWorking with programmers there is a certain mindset that you encounter. I must confess that I often display this myself!
“I know what I’m doing, I have read the W3C standards, and I am making the app that everyone will want to use - and they will use it in the same way which I do”
Application development would be so much easier if this were true! Unfortunately, the ultimate truth is that people are not logical, even when you think they are. And, whilst everything you have read from Nielson suggest that users will want to use your app in a particular way, you will find a surprisingly large number of those who don’t! As an example, during the development of GMail, the developers identified half a dozen different ways that people would use it to manage their e-mail.
I don’t want to pretend I’m a user, I would have to pretend to be stupid.
Okay, perhaps thats a bit of an unfair statement, but it underlines the point - the user is likely to try and do things with your Web applications which are irrational and counter-intuitive. Its up to you to anticipate this and be prepared to accomodate this.A good example of this was seen at recent user labs we ran, looking at some of our Web applications. In this case we had a multi-page form, with a stepped progress indicator along the top of the page. It was quite surprising to see the number of users who would try to click on this progress indicator in order to navigate between the pages. In such a situation you have two options:
- Add that functionality to the proress indicator
- Look at the copy text and visual style of the indicator - why are people thinking that it is a link/button and how can this be reduced?
Either could be an acceptable solution. In our case we went with the second one, partly because it was a quicker fix, and partly due to issues with the underlying architecture which would make the first option unfeasable.
Tags: webdev