[Sigia-l] check boxes versus multi-select lists

[Donna Maurer]

Actually, in many cases (if not most), users do not know what they want, what they 
need or what would help them to work better. They may know how they work right now 
(or they may not), but they can rarely project well into the future. Direct suggestions 
from users are limited to what they think would be possible, based on what they may 
have seen elsewhere or what developers have told them is possible (hah!). The 
suggestions are usually extremely limited.  I have many, many times had discussions 
with users about what they think they want, then said "but what if we did xxx". They'll 
say "wow, that sounds good, can you really do that".

This is what *Design* is. Looking at the entire context (business, users, information, 
constraints) etc, identifying the conflicting needs, and designing something that fits 
that whole context. This is why there is a creative step in design. Just taking what 
users want will give you nothing but a list of (usually conflicting, messy) requirements.

Imagine if you were talking to real users about this situation and asking them how they 
would prefer to make the choices. Say your user group has only experienced multi-
select or checkboxes - they will state a preference for one of these. They will not 
suggest anything different like:

* the solution where you put items from one side to another (I don't know what this is 
called)

* some type of filter (choose a broad category, then shorter detailed list)

* a multi-select list that shows selected tems with a tick next to them and doesn't 
require ctrl to select

* a multi-select list that lists out the selected items on screen as they are selected

* a drag and drop list (drag from options to choices)

* or any number of other possibly better solutions

Sure you should talk to users, but you have to listen beneath what they are suggesting 
to determine underlying needs, then *design*.

Donna
 

On 14 Jan 2005 at 17:51, T. Karsjens wrote:

> I completely disagree.
> 
> Your users are *all* of your context.  If you have access to them, of
> course.
> 
> There is *no* best solution, except what the users want.  If they want a
> list of 50 check boxes, then guess what the best solution is.  If they want
> multiple multi-select boxes where the next choices are delimited by their
> previous choices, then that is the best solution.  
> 
> You cannot carry around a bag of tricks that you pull the same solution out
> of on different projects.  You have to do what works, and if you have access
> to the actual users of the system, then the entire context of that system is
> based on the interaction you have with those users.
> 
> Now the challenge is, and this is where a lot of us fail, is getting those
> users to sit in a room and come to an agreement.  Another challenge is
> picking up on how a user actually uses the system, versus what they are
> saying.
> 
> The majority of my work in the last four years has been going in after
> "creative professionals" and cleaning up the messes that they have left
> behind after thinking that they knew what is best.
> 
> The major caveat to this is if you do not have access to the users, to get
> real time, quality feedback, you *do* have to make assumptions as to what is
> best.  Having the experience from working with real users makes this a lot
> easier, but you can also pull valuable information from others.
> 
> --timk
> 
-- 
Donna Maurer
blog: http://maadmob.net/donna/blog/
work: http://steptwo.com.au/
AOL IM: maadmob