User Research for Everyone
A lesson I’ve learned from the KDE4 HIG is that it is too large of a project for 2 busy people to work on (before you all go off on the HIG, we (Ellen and I) plan on getting 1, possibly 2 OpenUsability Season of Usability interns to work on it this summer). The HIG was a hard project because it required contributors who had experience in styleguides, experience in design, and experience analyzing and making decisions for ambiguous guidelines. When there are only a handful of people who meet that criteria and other things come up, the project becomes very volatile and ends up slowing to a halt.
In all its glory it might have been in a few years ago, there aren’t many active contributors to the KDE Usability Project at this time. This is very disappointing and discouraging, so I have thinking of ways of making usability and design a more sustainable effort in KDE. One of the most basic and important things you need to be able to do good design is to understand your user and what you want to enable them to do. Without this information (documented), it is all too easy to lose sight the big picture and focus on individual functionality instead of overall workflow.
Even in the real world, clients realize they need help with design when it is too late. When I join a project, one of the first things I try to do is back fill on user research, even if it isn’t something I’ve been tasked to do. It is both a necessary requirement for me to do the best job I can, and, it provides the client useful documentation they can use in current and future development.
It’s hard to know where you’re going or what you’re doing if you don’t know who you are developing for and what they are doing with your software. IMHO, each project should have the following information documented somewhere:
- Vision statement or concept of operation
- User group definitions supplemented with profiles or personas
- Use scenarios and use cases (these are distinctly different)
- Task and workflow documentation (not as necessary, but very useful for complex software)
- Probably some other things that would be useful, but not as necessary and I can’t prioritize without making the list really long
This information will be different for each project. Each project has its own goals and users, so it does not make sense to create a generic set of user groups and profiles for the entire environment to be applied to sub projects. KDE (the entire environment) should have its own vision and user group definition, but so should Kopete, Konqueror, Kmail, Dolphin, etc.
For example, imagine how useful it would be to know the exact goals and users for Konqueror versus Dolphin. And have it documented and easy to find!
I’m sure all of you are on the wagon now, but it is still a lot of work and I want to make sure this is something people want.
- If templates were available, would you fill them out and keep them up to date?
- Does your project have a developer or someone else who knows the project well enough to be able to document (or research and then document) the points I’ve mentioned?
- Once you collected this information, would you refer back to it and use it during development? Really?
- Where would this kind of information live? KDE techbase?
seele :: Mar.05.2008 :: Design, General, KDE/Kubuntu :: 9 Comments »
I would love to work with those structures, to help me to prioritize and focus. But I have problems applying it to Phonon. If I were to design one application the above items would be so much easier to apply. But thinking of a layer below the applications, unifying some of the behaviour of all applications (defining policy) and putting common configuration in one place just doesn’t apply 1:1. I actually started the design of Phonon with documenting what I want (I used http://sysiphus.informatik.tu-muenchen.de/ for it) but I found it too hard and killing all of the fun (like I said, I think this might have been different for an application instead of a framework). The parts that I actually managed to documented helped and I frequently referred back to them.
To summarize: I want more structure in the output of my thoughts/dreams/visions. :-) Any help on how to do that is welcome.
Hi, I’m studying Usability for my graduation thesis, and I have some experience with design and with programming. I’m working for 3 years on a company where I design UI prototypes, icons, design websites (something I really hate) and develop web applications.
Since I’m a computer science student I program c++ too..
So, resuming, I have some multidisciplinary skills and I want to know how can I help in the KDE Usability Project, since you’re saying there aren’t many contributors..
Now I only have my professional experience, some knowledge on usability trough some articles I read, and the books I’m reading (Nielsen and Raskin right now), but I believe I’m able to help on something, just don’t know exactly how.
thanks for the time
I thing that is of interest to me is similar to what has been captured in a bit of an overview at http://log.ometer.com/2008-03.html#5. An aspect that I cannot fathom is how to encourage an user-centric usability ie in addition to looking at ways to enable an user to “do things efficiently” with the software, looking at means to include the actual user in the usability assessment process. Right now, a large bit of usability assessment is reactive. Based on multiple content silos like bugzilla, wikis and mailing lists. The user doesn’t actually get some real time involvement in the effort.
One thing that discourages people is when attempts to help get ignored or discounted.
I wrote up a long description of some UI problems in KDE 4, and attempted to post a link to one of the appropriate mailing lists. I’ve also tried to point various KDE devs at it. I have had absolutely zero response.
I see that at least one of the issues has been fixed (the window is now resizeable), but still…
@mathew: Have you considered posting bug reports? I think it’s the only way you can get any developer to pay attention to your critique…
@matthias: phonon is hard because it is a framework instead of an obvious ui, but it . it may be useful to integrate some of the vision information in to the developer documentation. if there are some ui hooks, it may be useful to describe cases certain ones should be used versus others.
@paulo: joining the kde-usability mailing list is a good start
@sankarshan: although it depends on the definition, usability is only 1-part efficiency. also, i tend to refer to design, not usability. usability is only 1-part of design.
@mathew: it is unfortunate but typical in open source, especially when it comes to usability. open source is a meritocracy. design is somewhat of a sensitive subject because there are a lot of people with opinions and not as many with experience. besides that, a lot of the comments you make have already been addressed by the plasma folks, so that is another reason why you haven’t had any feedback.
[…] few weeks ago I tried to kickstart user research in the community by talking about user research for everyone. I outlined a few high level topics that every project should think about before they write a line […]
[…] few weeks ago I tried to kickstart user research in the community by talking about user research for everyone. I outlined a few high level topics that every project should think about before they write a line […]
Hi!
Great ideas one thing that I have learned is that when u have to talk about accessibility design and usability comes as a bonus since you realy can’t have the first without the other two but you can have the two last without the first as is the common thing in Linux and OSS. In both windows and OS X their is an api and framework for accessibility that outclass anything in linux. Just look at how gnome and kde are treating accessibility. They have both special groups that aren’t considered as important as other development since they have their respective small groups for it in each project. Since it isn’t included in the regular work and just a few people work on them very little progress is made. Sure linux is great and all but it lacks finish and accessibility\usability.