Re: [Usability] Usability and I

[Janne Kaasalainen <janne kaasalainen gmail com>]

Hi,

I need to start with apologies, this will not be any sort of a  
definite answer and depending on the situation may be outright dumb  
post. However, I've gone through a project or two so I might just as  
well post something to think about. What I put here is some basic  
stuff that seems to always come up in the beginning. Later on one may  
(and should) start to break rules.

Usability engineering and user-centered design is often broken into  
steps such as following by UPA*:

1. Specify the context of use
2. Specify requirements
3. Create design solutions
4. Evaluate designs
5. Goto 1 till you get results that satisfy your goals.

Now, all that fine and dandy stuff aside, we get to more of matters of  
opinion and personal experience how the steps work out.

In initial states of a project I've noticed it's not as much creating  
information as it is observing and gathering how the people and the  
world functions today. One may have a set task, such as "create a  
better accounting system for us" in which case the context of use is  
more clear. On some instances, you have to initially imagine these  
things. If such is the case, it might be a good idea to somehow  
evaluate if what you plan to do makes any sense at all. And this can  
be notoriously difficult to decide.

In any case, once you've established what it is that you do and  
approximately to whom, you start to decide what the system should  
exactly do. Say, you want to create an image gallery (what you want);  
it should at least browse images, import and export them  
(requirements). The detail of requirements depends on the project,  
team, workflow and the position of the moon and the stars. And if your  
grandma has pink socks and wind blows from east. Again, it might be  
good idea to evaluate if your requirements are about the correct ones.

Then you create the design solutions and implement them to sufficient  
level. The level, yet again, depends. I personally prefer quick and  
dirty wireframes for sanity check, Photoshop for (near) pixel perfect  
mock-ups and assistive Flash animation where interaction is needed. It  
depends on the project, but for me it's been that it is better to  
screw up fast so more effort (and thusly detail) is used in the  
beginning of the project to ensure it's not facing show stoppers. This  
can mean highly interactive demos with minimal effort just to  
prototype stuff. Fake and cheat all you can to make it a fast process.  
Better to kill the project early than to try to stick with something  
that will not work in the end and thusly wastes peoples time and  
money. So again, it's nice to evaluate what you can along the way.

At some point you have complete enough thing that you can evaluate.  
Since people who succeed at once are very rare if they even exist, you  
end up with feedback and results about what went wrong or was at least  
imperfect. You can (and probably should) use both qualitative and  
quantitative tests. Just measuring is, imho, not really worth much but  
when combined with qualitative data it has its benefits. One also  
gains more information based on which it may be reasonably to evaluate  
if your estimates in first step were the correct ones. And the cycle  
repeats itself till you fulfill the criteria set for the project. This  
iteration is paramount as many things that depend on each other.

Now, the above may sound messy, but it is even messier than what it  
might seem. In a way it is a game of imperfect information - you  
simply don't have all the information you need when you need it. You  
may test and measure wrong things on wrong people. There may be  
technological obstacles or suddenly emerging enablers. Sometimes there  
are sudden changes in the landscape on which your thing operates. At  
times reports and documentations fail to deliver the most important  
findings from user test.

To mess up things more, things change again once you step outside  
usability and start to consider some buzz-words such as user  
experience. For the design it is important to understand that  
usability is just a part of a value proposition, and its weight...  
depends.

The above is in great length just an opinion, though, so don't take  
that too seriously. People do stuff in many ways, and different things  
work for different individuals, groups and situations. I guess "doing  
suability" can be considered just as an evaluations, but at some point  
the rubber needs to hit the road for anything to get done.


Best regards,

Janne Kaasalainen

* http://www.upassoc.org/usability_resources/about_usability/what_is_ucd.html


> For my understanding I'll try to summarize the general steps needed to
> "do usability". Please correct me with everything I got wrong:
>
> 1. creating information
> 2. categorizing / collecting the information
> 3. evaluating the information
> (4. implementing it)