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

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

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.

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.