Someone at work clearly grew frustrated with having to position the coffee pot under the drip. They attached a ruler to the coffee maker with rubber bands so the pot is positioned properly if you just place the pot against it.
If only it were so easy to adapt poorly designed software to your needs.
I lost my paper bill for this month’s gas utility invoice and wasn’t sure when payment was due or how much was owed. We had just signed up with Terasen (our last place was electric only) and I hadn’t tried their web site yet. I had a pleasant surprise when I got to their login page. First time users don’t have to call customer support, request a PIN, or any other such nonsense. You can login with your account number and phone number! After the initial login, you choose a “proper” login ID and password. Very nice.
I really like the new(ish) Blogger redesign, but a few things still bug me. They have some design elements that look like buttons (like the Sign In button), but they aren’t buttons at all — just links. You need to click on the hyperlink itself, not the “button” area. Affordance, anyone?
Why does my computer have three volume controls? I can adjust Window’s sound volume, iTunes’ (or insert favourite media player here) volume, and the external speakers’ volume. I find that I end up twiddling all three of them on a regular basis to get things just right. Any computer system designers reading?
–
On a personal note, we have moved homes and are now recovering. I hope to re-engage my brain soon.
We recently switched cell phone providers and got a Siemens A56 phone (can’t find it on Siemens’ web site, but it’s similar to the A55). Over the first few days we used the phone, we grew so frustrated by its many usability flaws we traded it in for a more expensive model from Sony Ericsson. This is a mini-review of the major issues we had with the phone.
I think this is the first time I’ve returned a product simply because of usability issues. Usually, I can get by but these problems convinced me to pay an extra $25 + shipping for a much more user-friendly phone.
I don’t know whether this is a good idea or not. I received an email asking if I want to subscribe to various email newsletters. Here’s what I’m supposed to do:
Please reply to this message, marking your choice with an X
- ‘I want to receive Noldus News, your printed newsletter’
- ‘I want to receive Noldus Newsline, your digital newsletter’
- ‘I want to receive both Noldus News & Noldus Newsline’
My initial reaction was, “Mark it where?” I realize it probably doesn’t matter, but I can imagine how I’d parse the reply.
Using a paper analogy doesn’t always work, but maybe it would in this case. However, It still “feels” weird.
–
A more substantive entry should come soon, but it’s been a hell of a week. Have a good weekend.
I got an email the other day advertising PlanetHCI. It’s a feed aggregator focussing on HCI issues. However, they have a few feeds that are low on HCI and high in personal or other issues. I wrote to one of the admins complaining about the falling signal to noise ratio and he replied that they are working on filtering the feeds, but it sounds like it will take some time.
In the meantime, I think I will scan the PlanetHCI for interesting new sites and add them to my news reader so I can avoid the noise.
Back from Chicago.
We did a very interesting usability test. Unfortunately, I can’t write about it since it’s for an unreleased product. What I can say is that it tested a software design that attempts to solve a very complex problem. There was definitely friction between the users’ understanding of the problem and our solution, so we’ll have to do better. It was the first time I tried a hybrid paper/software prototype test and it seemed to work quite well even though users bounced between paper and computer many times during the session.
What’s the most conceptually difficult design you’ve worked on and/or tested with users? How did it go?
I’m off to Chicago for a usability test, so my already sparse posts will be sparser. 
Ron, I’ll answer your questions in a couple of days.
Ron comments in a previous post that design issues should be addressed before usability work. (For the sake of this discussion, I’m drawing a border between design and usability; however, this division is often fuzzy and I acknowledge that).
How do you know your design is bad (whether it’s process, result, or a combination)? And, if it is bad, how do you get your organization to acknowledge the problem and correct it?
Design is hard. Unfortunately it’s also subjective, leading many designers to assume their designs are good, even when they are not. Often, any problems can be ignored because your product’s other strengths overcome them (e.g., it has unique features, a strong sales force pushing it, etc). Any reports of difficult interfaces are dismissed because, bottom line, it’s profitable. This is the case in many growth industries where commodification hasn’t set in, yet. I think it’s also a factor when the buyer is not the primary user (the situation for most of my company’s products).
So if you have a profitable product and you’re not getting a lot of flak, then do you really have a design or usability problem? Well you probably don’t have a crisis, but you can still do better. Poor design may not be costing sales, but it’s probably costing more to train and support than it could.
In Institutionalization of Usability, Eric Schaffer lists a number of “wake-up calls” that might cause a company to reassess their current practices and adopt a user-centered approach. One example is the “train wreck” but my company hasn’t experienced that. Another wake-up is usability testing. Once development has seen usability test results (or, better yet, observed a test) they will come around and adopt new processes.
To address Ron’s point directly, this is why I’m focusing on usability before design. Having woken up myself, I’m providing the wake-up call for my company. Thanks to my background as a software engineer and the respect gained from being one of “them”, it’s been relatively easy to convince the engineers I’ve worked with so far of usability’s benefits. I am in the middle of making the pitch to middle and upper management and this is where I’m encountering resistance. (As I write this, I realize a great way to overcome this issue is to invite management to observe a test — duh).
I believe its easier to work within an organization’s structure and change it slowly. I think introducing more user-centered activities will benefit development even if the design processes or staff take a while to change. For example, I’ve done paper prototype usability testing early on with some projects and these tests have pointed out fundamental design problems. We’ve been able to nip these problems in the bud. Just the process of preparing for paper prototype tests has forced the engineers to consider important design decisions they may have postponed.
Another bump I’ve hit on the road to usability is the question, “Would development team X prefer another developer or a usability engineer?” The person asking this question generally answers, “Probably a developer.” After all, a developer can add more stuff quicker.
I’m coming to see that the question is fallacious. Why don’t people ask, “Would team X prefer another developer or a tester/doc writer/name-your-well-accepted-role?” The obvious answer is because those roles are recognized as being crucial to product development. An extra developer will create more code, maybe get an additional feature in, but at the expense of a more usable product. The counter-question when usability is challenged is to ask, “Is usability an important part of our development process?” If not, you either have to prove its worth or move along as you won’t make any progress in that environment.
However, if you think you’ve proven the benefits of usability and the question still comes up, you need to squash it early. Do not let it fester. If usability is seen as an important development component, the logical thing to do is ensure there are enough resources to cover the entire company’s development effort. Anything else means usability is only getting lip service and you haven’t made the progress you’ve thought.
As I attempt to role usability out into the wilds of my company, I sometimes get pushback that comes in the form of, “Why do we need a formal process? Shouldn’t usability be an integral part of product development like quality or reliability?”
There are two parts to that challenge. One is making usability happen and the other is ensuring it did happen. The obvious response to the second part is that if quality is ensured by a test or Q/A team, then shouldn’t usability have similar resources? That’s an easy argument to make.
The first part is more challenging since it involves changes to the way a company develops products. How do you make usability happen as an integral component of development? It sure doesn’t happen on its own and is not a technical task like coding. (A recent article and thread on OK/Cancel addressed this issue quite well.) While it’s easy to show development how a usability test pays off, it’s harder to justify the expense of user studies that aim to provide the team with a better idea of their target users.
Another aspect of usability is good design. In my company (not sure about others), most interface design is done by engineers, not experienced interaction designers. I believe better designs would come from specialists in that field, but that’s a battle I won’t be fighting for a while.
Ongoing testing or evaluation can help mitigate the lack of user research and optimum design staff. If we can test early and often, it may take a little longer to iterate to a great design, but it should be possible.
Today, the product management group agreed to add usability as an official consideration for all new projects and all projects about to go to beta. There was no real challenge to the idea which makes today a little bitter-sweet. I’d prefer to have to fight a little harder for this.
I suspect that the fight is to come. I now have to inform the product group leaders (in charge of budgets and staffing) to allocate resources in what turns out to be overhead positions. If there’s going to be resistance, this will be the time. However, with the COO and President on side, it will be short lived.
My next challenge is figuring out the best way of training and managing this group. There will only be one, maybe two, usability people per group (to start, anyway) and I do not want them wallowing in a vacuum. I also think it’s best to get usability engineers to facilitate each other’s tests to keep an air of objectivity.
As I mentioned below, I’m trying to grow a group dedicated to doing usability work at my company. This seems like a subject worthy of blogging about and I promise not to give away any company secrets.
I spoke with our COO a few months ago and he’s been helping me push usability out into the rest of the company. After a meeting with various group leaders, I’m now in the middle of attempting to have our product development process officially modified to incorporate usability as a key component in a product plan. The proposal is currently under review by the company’s product managers and today I received the most challenging question to date (and one I ask myself). Someone asked me why we need to change the development process. Why can’t we just evangelize and incorporate it into product development without making it another hoop to jump through?
Indeed. This is the approach I’ve been trying for almost a year with some success, but not a lot. I call this the “grassroots” approach to spreading usability. The problem I’ve hit and the reason I’m trying the top-down approach as well is that existing teams are not prepared to dedicate a person to usability. Schedules are so tight (or optimistic) and teams are maxed out and can’t take on another task — besides, they’ve made it this far without usability.
I hope that “forcing” projects to look at usability requirements will get them to budget for usability. I also hope that, as a result, I will be given the head count to grow a small team that can build specialized usability skills and help a number of projects. I still come back to today’s question, though, and wonder if I could have been successful if I only pursued the grassroots strategy. From what I’ve read, the answer is no, but I wonder.
Stay tuned.
I feel the urge to blog something, but I’m afraid I’m too tired to write anything meaningful. Let’s see what happens, though.
Work is really picking up. In addition to my usual usability work, I’m trying to get the rest of my company to adopt more usability and user-centered design practices. I am one person doing this work in a company of around 4000 people, so it’s about time I got some help! (Besides me there is one other person focusing on usability for one small group.)
I’ve been getting some excellent feedback from project engineers I’ve worked with in the last year and a half and that helps adoption, but I’ve learned that you also need to get buy-in from the top. Only from the top can you change the company’s high level processes that control important items like budgets and head count. Luckily, our COO knew the importance of usability before I could get more than a sentence or two into my “pitch”. So, I have a senior executive on board willing to jump in when necessary, but it’s still slow going. Now, the real work is starting as I attempt to educate more and more people in usability and its benefits.
This is a very risky endeavor in many respects, but it’s incredibly exciting to both change development practices and build a group from scratch. I hope I’m up to the challenge.
Steven Den Beste has a post about some surveys he’s received recently. I think it’s a sarcastic post, but I can’t tell for sure as he seems overly serious in the majority of his writing.
Anyway, he has some comments about surveys and survey methods. I’ve read a bit about surveys after experiencing a disaster at work a little while ago. He seems to have two main points:
1) The surveyors could have answered most of their questions by examining the site themselves.
He writes:
It strike me that if an academic wants to learn about blogs, then the best approach is field work: read a bunch of ‘em. You can observe them in their native habitat without leaving the comfort of your desk, as long as you have a net connection.
Of course they could, but how would that be efficient? I suspect they are trying to collect data from more than one blogger. (Or is Steven’s ego that big?)
They are also asking questions that can’t be answered by reading someone’s blog. They probably think that they will get more truthful answers from a survey than reading possibly fictitious blogs. I can think of other reasons for a survey that probably complements “field work”.
2) The surveyors have preconceptions and a hypothesis they are trying to prove.
Again — of course. He says the surveyors are academics, so it’s not surprising they are trying to prove a hypothesis. What else do academics do and why is it wrong to gather research data via a survey?
The fact that Steven doesn’t seem to fit in the box the surveys are attempting to draw around him either means he is an outlier or, more likely, the survey is poorly constructed. It’s simply challenging to create a good survey. You have to decide on closed vs open questions, get the wording of the questions right, the order correct, keep it a reasonable length, and more. Then, you have to test it and pick an appropriate sample set.
One of the tips to good survey building is to be up-front about the purpose of the survey. As Steven writes, “What in the heck is this person trying to learn?” Since the surveyor wasn’t very clear about that, everyone who answers the questions will do so from a different context. The collection of responses will be impossible to compare meaningfully.
But, the real lesson from his post is that the recipient does not have to respond to, let alone read, the survey. And even if he does, he probably shouldn’t write about it. Not that I’d tell Steven what to write about!
You come back to your computer after a long break and see a Word document still open. You’re done with it so you close it and are asked, “Do you want to save changes?” Your first thought is, “What changes?” You swear you just had the document open to check something and made no changes to it.
I hate this. It happens again and again. I want an easy way to see the changes its talking about. I want to know if I really made a change, if I accidentally typed a spurious character, or if Word is just doing one of its weird things with templates.
Somewhat related: Microsoft has a number of its employees blogging away. One of the guys, Rick Schaut, working on Word for the Mac often posts about the inner workings and bugs of Word.
Design by Fire: Design Eye for the Usability Guy. Design by Fire’s Andrei Herasimchuk takes on Jakob Nielsen in a hilarious column. Jakob gets an unsolicited make over! It’s like watching an episode of What Not to Wear.
