Posts RSS Comments RSS 377 Posts and 1,113 Comments till now

Archive for March, 2008

KDE User Research Profiles: Okular

This week’s project pick to complete their user research profiles is Okular.

Okular

The Okular User Research Profile (OURP) has already been copied over to techbase. Okular also has the advantage of having a long-term relationship with a usability specialist (thanks Florian!) who can help them with generating the user groups and profile data.

Other project updates

Although the Plasma team has only copied the PURP and not yet worked on it, they’re starting to think about user research. Last week we began an interview activity to help begin examining user types within Plasma. I hope to get most if not all of the interviews completed by the upcoming Plasma sprint. This information will be helpful in further user research discussions which I hope are on the schedule for the sprint (*hint* *hint*).

Jakob Nielsen: A Design Resource for Developers

Jakob Nielsen is a pioneer in early usability engineering and an evangelist who helped kick start the “usability” industry in the late 90’s. When I was a student in university I followed a lot of his work, but don’t really pay too much attention to him anymore. Maybe I grew out of his advice. Maybe he’s just passé. One thing I’ve noticed is that Jakob tends to restate the obvious, perhaps this is why I no longer follow his Alertboxes. This isn’t too useful for the people who already know the obvious (usability and design professionals) but great for those who are learning (students and developers). Case in point, TZ pointed me to Nielsen’s February 19 2008 Alertbox: Top-10 Application-Design Mistakes. This is really a great article for developers. The mistakes may seem obvious, but they are things I catch and fix in software all the time (Yes, in KDE too).

Also, the best bit of the article is near the beginning:

Usually, applications fail because they (a) solve the wrong problem, (b) have the wrong features for the right problem, or (c) make the right features too complicated for users to understand… The only generalizable advice is this: rather than rely on your own best guesses, base your decisions on user research.

More emphasis on user research! Jakob is now back on my hit list, but as a resource for developers rather than designers.

Leadership is a problem but not the problem

I was referred to a recent CNet article, Usability, a question of (open source) leadership, which talks about an interview with the Linux Foundation’s president Jim Zemlin on the topic of open source usability. I’m glad to see the higher-ups thinking about usability on this problem-solving level. The Linux Foundation has always been supportive of design activities in open source, with the OpenPrinting workgroup as a good example.

However, leadership is not the primary problem. While it is good to be thinking about these things, we won’t get very far without addressing the right problems. That’ why we haven’t gotten further than we are now.

My comment to the article:

I can’t say I completely agree. If you look at the literature of the professionals actually doing open source usability, leadership is only a secondary problem (in addition to developer-designer communication and lack of professionals involved). The primary reason usability in open source fails is that there is no vision or understanding of who the product is for. This can be solved on the developer level, and even at this level can and will make an impact. Things like leadership, communication, and professional involvement support user research and acceptance of the findings on a project-level. Sure, these things are very important too, but not the root of the problem…

Lack of leadership, especially when it comes to making design decisions, is certainly a problem. Having good leadership to help push good design practices such as user research is definitely good. But let us not forget this is not the root of the problem. Leadership will not get us anywhere if the user research does not get done. Without a vision or definition of your product users, what is there to lead? You can’t get the other “usability” activities done without a clear understanding of who your product is for and what they will be doing with it. Good leaders can help define this vision or definition, but it needs to be done at the developer level, not at the management level.

What we need are good people (developers or designers) to do user research, with good leadership to support it.

KDE User Research Profiles: The PURP

Being true to my promise last week, here is this week’s project pick for beginning their user research profiles:

KDE Plasma

Plasma already has a head start, last week Aaron copied the template over to the Plasma section on techbase: Plasma User Research Profile (PURP). This will be a great activity to work on at the upcoming Plasma meeting in Milan. If you have any questions, feel free to ping me.

Maryland LoCo Usability Testing

The Ubuntu Maryland LoCo met at the Howard Public Library last night. I didn’t get a chance to go, but they did talk about some interesting stuff. Many of the members are familiar with my work with KDE and Kubuntu, and wondered if the LoCo could go around and do usability testing on friends and family.

To tell you the truth, any monkey can run a participant through a script. It’s just if the monkey knows what he’s doing, he’ll observe more findings than the monkey who just poops on the keyboard. We’re not trying to do science. This is craft in practice. We’re not trying to get x usability findings per n dollars. The goal is to get real feedback from real users who are using Ubuntu right in front of us. It is not to prove any usability metric.

It will take some planning, but I think we could pull it off. Let’s talk about it.

Next »