Portable Usability Labs As User Research Tools

Pete Gordon writes "Do Portable Usability and User Research Labs make sense in the software development life-cycle? This interview (my bias--it's with me, and I have a tool in beta now) covers some of the issues and questions on KDE's news site. I don't have the right answers necessarily, just looking for others input and opinions. Also, here are other links about the subject over the past few months. Info World and Harry's comparison."

Comments

Cost?

[Dancin_Santa]

Open Source projects, more than other types of projects, have serious financial constraints. Is the cost/benefit ratio of performing these labs worth it? Seeing as how Open Source projects typically form the backbone of systems and rarely form the front (user-facing) end, is it worth it to spend time and money on projects that will only be used by developers and hackers?

Re:Cost?

[metlin]

Short term, yes. Long term, no.

In the long term, it would be worth it. Hate it as you will, the precise reason Windows does so well in the market is its user interfaces.

User interfaces play a very very vital role in user behaviour, and usage.

I do not understand the argument that developers should not have good UIs. Why not? Would you not use a Visual IDE for your development if it had more features that you would use? Or would you rather that we all stick to CLI?

In fact, I really *like* Microsoft's Visual Studio .NET's IDE -- it's really quite well done, and very well designed with the developer in mind. And guess what? It increases my productivity by a significant amount when I code.

I'll just say this -- if Linux has to make it big, user interfaces _are_ a big deal.

There is a HCI maxim that says that the best designs are those that you do not notice -- that is what we should be striving for, Opensource or not. You never know who would be using your Opensource application for what.

And a good UI design is only going to help it.

Ppl and PC's

[Ex-MislTech]

As Engineers and coders etc etc, we tend to take alot of things
as granted, and already understood ie. intuitive for our mindset .

But for the common man sometimes it does not jive .

If you think that alot of ppl still have flashing 12:00 on their VCR's
its gonna take some serious simplicity to get past their (fear?) of
the technical or just grasp of it .

I think monitoring computer usage amongst beginners and maybe even
intermediates could show were ppl are frustrating themselves, and
perhaps tools that could be provided to ease the road more
travelled , ie. the electronic office/school/home .

Ergonomics is for human physical comfort, this might provide
one for mental comfort of sorts .

Best example I can offer is tech manuals that leave out a step
that is obvious to the person that wrote it or coded the app,
but leaves the first time user sitting there thinking its obvious
something was left out, but not sure how to proceed .

Computer literacy is still pretty weak IMHO, and on the level of
Linux and nomenclature of OS subcomponents even more so .

The more we understand the users, the better we can adapt the
interface .

Ex-MislTech

A good thing, but not indispensable

[TuringTest]

Elizabeth Neal has recently written on this subject, and the title says it all:

Why You Don't Need a Usability Lab

Promoting the mindset for usability and user-centered design inside the KDE project is a very good thing, though.

Re:A good thing, but not indispensable

[platos_beard]

I don't think the most important factor determining usuability is addressed in either article. User interface design should be done by user interface designers, not programmers. They need a completely different skill set. While programmers need to understand the working of a computer and be able to extract essential information from documentation, UI designers need to understand the people and processes in the domain they're designing for and be able to extract essential information from people.

Put simply, programmers need computer skills while designers need people skills. Sometimes they overlap, but no more than random variation dictates (and possibly somewhat less). And even if they do, its a different mindset while doing one job vs. the other.

And both jobs are hard. A good UI designer has to get beyond the specific suggestions from users to see what the underlying need. UI designers have to find a way to get users to envision a system that doesn't exist yet and figure out how it could work best. Prototypes are essential. Skills to run meetings are essential.

The toughest part is dealing with criticisms of proposed designs. Sometimes the criticisms are because the new design isn't understood well enough, but other times the criticisms reveal a design flaw. Distinguishing between the two, and correcting misunderstandings of the proposed design without stifling further criticism (which you need) is a delicate art.

Short-term testing alone is harmful

[mattdm]

Creating truly usable software is a difficult task, and it makes sense that we'd want to apply the Power of Science! to the problem. So, we get Usability Testing.

Generally, the usability tests I've heard of work like this: you get a bunch of people and stick them in a lab (portable or not), and watch everything they do with the program for a while, as they complete a checklist of tasks. It seems to be prefered to get users who have no previous experience with the program, to prevent "bias".

Well, that's great, but it doesn't really address usability. It addresses short-term pickupability. Now, that's really important, and it _should_ be addressed -- but if it's the *only* thing you're concerned with, you'll miss other important issues relating to long term software use.

There's a unix-geek saying: "Unix *is* user-friendly -- it's just picky about its friends". Like all such jokes, there's a kernel of truth here. There's a very steep learning curve to the command line tools that are at the heart of the Unix environment, but once you've gotten up it, they *enable* you as a user to more easily do complicated tasks that would be very tedious in a GUI.

I don't mean that this is about the CLI vs. GUI thing, though -- that's just an example. I'd certainly be frustrated if my web browser were exclusively designed based on the reports of people who use it for a few hours to complete basic tasks. I'm concerned about the line of thinking that removes features which save huge amounts of time every day simply because they might confuse new users.

I won't name any names, but I will cough subtly in the direction of the GNOME project and at metacity.

Please, usablilty people, don't just think of first impressions. Think of the long-term relationship. Both have to be good.