(the original published version is here: http://www.annexgroup.com/2012/03/thinking-about-usability/)
Thinking About Usability
By Mike Hrycyk
I’ve been in the IT industry for some 14 years now. My experience has spanned quite a few different roles, from QA to BA to assorted manager/lead types. Throughout my time I’ve noticed that there’s one term that everyone likes to talk about but few people can define in any consistently meaningful way. Usability. What’s the big deal you might ask, it’s not like we don’t all have an idea about what usability is. When you’re put on the spot, it can be pretty easy to break it down into some simple terms. Just looking at the word gives you the out of saying that it means things are easy to use. But have you ever seen tacked onto the end of a set of requirements for a developer to make it usable? I’ve seen that more than once. How useful are those words to a developer? What does it really mean? Who could say?
There are people out there who purport to study usability. Some of them even claim to be usability experts. I’ve worked with a few of those so-called usability experts. As far as I can tell, if their success rate is significantly beyond that of anyone else that seems to have a knack for usability, then I am not the type of person who can really detect the difference. There are methods that can be set up to measure it, such as needs analysis, efficiency measurements and focus groups but in the end it’s an entirely subjective term that you can try to nail down. I am however, significantly dubious that there is really anything even remotely scientific about the knowledge to be attained. You’d almost think that this would depress me in some way, coming out of QA and BA where we like to have everything quantified or qualified in some manner, but I’ve come to a conclusion. It’s not important so much that you’re good at measuring usability. It’s sufficient that you consider usability on an ongoing basis and that it’s one of your core goals. Thinking about usability, considering it important enough to stop your development plan to fix things when they aren’t usable, that’s the simple path to success.
In the past few years I’ve picked up a lot of responsibility towards recruitment and interviewing people to join our organization. To the extent that I’ve put together some question lists that I use for different roles that I’ve been looking after. I rarely actually record the answers to these questions, just jot down notes about the responses that I’ve been given if they are interesting in any way. Unless the question is particularly technical I generally am not targeting a particular response but rather want to see how they think about things and how they put together an answer for me. Gauging how people think and approach thought problems is really important to my assessment of them. I came up with one question for my QA hires that I quickly extended to my other interviews because I found that it gave me some critical and useful insight into the applicant.
The question is a two-parter, that in and of itself is difficult enough to give the applicant some difficulty just trying to get past the standard interview hurdle of figuring out the right path between the answer you’d like to give, the answer you think the interviewer would like to hear and what you believe the correct answer to be. The question: “in your experience who do believe has been the owner of usability and in your opinion who should be the owner of usability?” I generally explain as I ask the question that there is no correct answer that I am looking for and that’s true. For I’m not sure that there can be one correct answer to this question, nor am I expecting one. The way to succeed in answering this question in a way that is going to impress me is to prove to me that usability is something that you’ve considered in the past and that can think cogently about.
For sure I’ve had some bad answers but even those could be well mitigated if they are backed up by some consideration and obvious thought process. I’ve had people why had no idea what usability is, never heard the term. Most of these get it when I explain it in other words. Invariably people for whom the concept is too difficult to explain are dropped for consideration for the role. All of the software that I’ve been involved in producing has user front ends. If you’re producing front ends without an eye to usability you just don’t care about things like productivity, efficiency, return customers, word of mouth and etc and you’re simply not worth my time. I had one person insist that the owner of usability should be the end-user and without a doubt, if you don’t pay attention then they de facto become the owner of usability. They will speak with their mouse and stop using your software. By insisting that the end-user should be the owner, this candidate demonstrated to me a vast misconception of the system and the business.
Only once has an interviewee given me the answer of developer as the one who should be the owner. I believe I was slightly incredulous when I asked for more details for this one. I grant you that there may be developers out there that have a talent for design and can produce quite beautiful user interfaces all on their own but honestly they have the deck stacked against them when they go up against this hurdle. Their day starts and they are already under the influence of a number of disadvantages. They are generally reading twice converted requirements, if not more, and if they’re not being given designs then they have to themselves convert this into something both functional and usable. Then there’s the perhaps debatable notion that developers just don’t think like the rest of us. Developers are just too darned logical. When you give them a flow to produce they go ahead and produce it, and they might even test it. And it will work for them. It will be logical and make sense…to them. But users are incredibly complex (this is my nice article-way of saying what they are) and their sense of logic has a life-time of reasons to think differently. No matter what else you might think, your average developer does not have your average brain, experience, notions, upbringing, etc. Asking their logic to conform to the norm when their very business is assembling logic for a machine makes absolutely no sense.
With the person who answered developer, it would have been very difficult to make the decision to hire them. Not so much because they had come up with the answer that they did but rather in discussing their answer and what I consider the answer to be they didn’t really come around to thinking about it from the larger picture. That usability is largely about perspective. About trying to find simplest most common perspective that will be understood the fastest by the most people and figuring out a way to translate that into a user flow. It doesn’t have to be the fastest way through a dialogue, it doesn’t have to be the least clicks or the prettiest, it simply has to be the one that is most successful for the most users with the completely immeasurable side-effect of creating the least headaches.
For the record, the answer that I would give to the two part question is as follows. For the most part I have seen the owner of usability become QA, but QA is the wrong place to hold usability. If QA is not catching something as being unusable until their testing starts, then the mere fact that you are nearing to a launch date (schedules being the way they are) and usability often being so core to the development that the things that you find to change will not have the time to be altered without delaying the launch. I think the way that my current organization has bestowed usability jointly between the BA’s and the creative design group is the most successful. They are doing their work at the beginning of the project and therefore have all the time in the world to screw things up and then make them better. The BA brings to the table the voice of the customer, the person funding the software, so that whatever you build has a good chance of maintaining the requirements. The creative design group brings to the table the concept of what is good for the end user. But you might not have a BA, or a creative design group, or even QA…but you can still think about it. Thinking about it will always make it better…you know unless you over think it.
I’ve been in the IT industry for some 14 years now. My experience has spanned quite a few different roles, from QA to BA to assorted manager/lead types. Throughout my time I’ve noticed that there’s one term that everyone likes to talk about but few people can define in any consistently meaningful way. Usability. What’s the big deal you might ask, it’s not like we don’t all have an idea about what usability is. When you’re put on the spot, it can be pretty easy to break it down into some simple terms. Just looking at the word gives you the out of saying that it means things are easy to use. But have you ever seen tacked onto the end of a set of requirements for a developer to make it usable? I’ve seen that more than once. How useful are those words to a developer? What does it really mean? Who could say?
There are people out there who purport to study usability. Some of them even claim to be usability experts. I’ve worked with a few of those so-called usability experts. As far as I can tell, if their success rate is significantly beyond that of anyone else that seems to have a knack for usability, then I am not the type of person who can really detect the difference. There are methods that can be set up to measure it, such as needs analysis, efficiency measurements and focus groups but in the end it’s an entirely subjective term that you can try to nail down. I am however, significantly dubious that there is really anything even remotely scientific about the knowledge to be attained. You’d almost think that this would depress me in some way, coming out of QA and BA where we like to have everything quantified or qualified in some manner, but I’ve come to a conclusion. It’s not important so much that you’re good at measuring usability. It’s sufficient that you consider usability on an ongoing basis and that it’s one of your core goals. Thinking about usability, considering it important enough to stop your development plan to fix things when they aren’t usable, that’s the simple path to success.
In the past few years I’ve picked up a lot of responsibility towards recruitment and interviewing people to join our organization. To the extent that I’ve put together some question lists that I use for different roles that I’ve been looking after. I rarely actually record the answers to these questions, just jot down notes about the responses that I’ve been given if they are interesting in any way. Unless the question is particularly technical I generally am not targeting a particular response but rather want to see how they think about things and how they put together an answer for me. Gauging how people think and approach thought problems is really important to my assessment of them. I came up with one question for my QA hires that I quickly extended to my other interviews because I found that it gave me some critical and useful insight into the applicant.
The question is a two-parter, that in and of itself is difficult enough to give the applicant some difficulty just trying to get past the standard interview hurdle of figuring out the right path between the answer you’d like to give, the answer you think the interviewer would like to hear and what you believe the correct answer to be. The question: “in your experience who do believe has been the owner of usability and in your opinion who should be the owner of usability?” I generally explain as I ask the question that there is no correct answer that I am looking for and that’s true. For I’m not sure that there can be one correct answer to this question, nor am I expecting one. The way to succeed in answering this question in a way that is going to impress me is to prove to me that usability is something that you’ve considered in the past and that can think cogently about.
For sure I’ve had some bad answers but even those could be well mitigated if they are backed up by some consideration and obvious thought process. I’ve had people why had no idea what usability is, never heard the term. Most of these get it when I explain it in other words. Invariably people for whom the concept is too difficult to explain are dropped for consideration for the role. All of the software that I’ve been involved in producing has user front ends. If you’re producing front ends without an eye to usability you just don’t care about things like productivity, efficiency, return customers, word of mouth and etc and you’re simply not worth my time. I had one person insist that the owner of usability should be the end-user and without a doubt, if you don’t pay attention then they de facto become the owner of usability. They will speak with their mouse and stop using your software. By insisting that the end-user should be the owner, this candidate demonstrated to me a vast misconception of the system and the business.
Only once has an interviewee given me the answer of developer as the one who should be the owner. I believe I was slightly incredulous when I asked for more details for this one. I grant you that there may be developers out there that have a talent for design and can produce quite beautiful user interfaces all on their own but honestly they have the deck stacked against them when they go up against this hurdle. Their day starts and they are already under the influence of a number of disadvantages. They are generally reading twice converted requirements, if not more, and if they’re not being given designs then they have to themselves convert this into something both functional and usable. Then there’s the perhaps debatable notion that developers just don’t think like the rest of us. Developers are just too darned logical. When you give them a flow to produce they go ahead and produce it, and they might even test it. And it will work for them. It will be logical and make sense…to them. But users are incredibly complex (this is my nice article-way of saying what they are) and their sense of logic has a life-time of reasons to think differently. No matter what else you might think, your average developer does not have your average brain, experience, notions, upbringing, etc. Asking their logic to conform to the norm when their very business is assembling logic for a machine makes absolutely no sense.
With the person who answered developer, it would have been very difficult to make the decision to hire them. Not so much because they had come up with the answer that they did but rather in discussing their answer and what I consider the answer to be they didn’t really come around to thinking about it from the larger picture. That usability is largely about perspective. About trying to find simplest most common perspective that will be understood the fastest by the most people and figuring out a way to translate that into a user flow. It doesn’t have to be the fastest way through a dialogue, it doesn’t have to be the least clicks or the prettiest, it simply has to be the one that is most successful for the most users with the completely immeasurable side-effect of creating the least headaches.
For the record, the answer that I would give to the two part question is as follows. For the most part I have seen the owner of usability become QA, but QA is the wrong place to hold usability. If QA is not catching something as being unusable until their testing starts, then the mere fact that you are nearing to a launch date (schedules being the way they are) and usability often being so core to the development that the things that you find to change will not have the time to be altered without delaying the launch. I think the way that my current organization has bestowed usability jointly between the BA’s and the creative design group is the most successful. They are doing their work at the beginning of the project and therefore have all the time in the world to screw things up and then make them better. The BA brings to the table the voice of the customer, the person funding the software, so that whatever you build has a good chance of maintaining the requirements. The creative design group brings to the table the concept of what is good for the end user. But you might not have a BA, or a creative design group, or even QA…but you can still think about it. Thinking about it will always make it better…you know unless you over think it.
No comments:
Post a Comment