B.G. Sloan <bgsloan2_at_yahoo.com> wrote:
> In short, how do we design systems that help users find
> what they really need, rather than designing systems
> where we librarians assume we know what users need?
There's an approach that is rarely used but that I have some
experience in doing :
Ask them.
Ok, you can also call it User-centered design, where after asking them
you integrate direction into your designs, go back ask for more, test
what you've got, integrate that into your design, go back, ask for
more, test what you've got, rinse, repeat. :)
You'd be amazed at how many decisions are made for others that they
never wanted, no matter the walks of life. This is a human being
thing, though, and got nothing to do with libraries specifically. It's
how the experts stay experts. It's how the commercial world tries to
get that business advantage that will bring in the cash ; *guess* what
they want, and if you get it right, you win. If not, guess some more.
User-centered design has gained some traction in systems design, and
some entities are better than others. Do you remember the first
generation of government online services? Yup, that's how bad it can
get. But there's risk in asking your users, some actual, some not, but
most importantly are the mythical parts to the conundrum ;
1. You're showing weakness (that you don't know what you're doing)
2. You're telling your competition what you're up to
3. Your people aren't flexible enough (or too big ego's) to handle the dynamics
4. You know better because you're the expert
5. We've always done it this way
These are just some of the hurdles that gets in the way, an no wonder
; we're humans, we build up our knowledge over time, we take pride in
what we do, and we want to keep us in a position of advantage.
User-centered design throws a lot of this upside-down.
If you truly asked your patrons (layman as well as specialists) what
they wanted, it may also not fit into policy, domain or budget. This
one turns political quite quickly, but certainly shouldn't be ignored
(which is easy to do; why 'deal' with a problem you can't deal with?)
but should at least be used for future planning.
I know a lot of people have done this at various libraries, but I
doubt anyone has thought about their ILS in that way. OPAC maybe, or
bits of one. It would be an interesting exercise. There's librarian
needs and patron needs, and probably a lot of hidden needs for both
that aren't current. And then there are the needs that are long gone,
needs that are coming. You need a team of people to work on these
things all the time, but I doubt any library do this (it can be a
scary process), but this is certainly something I've been talking
about a lot ; a concentrated and ongoing effort in shaping the future.
Libraries love committees, and this one would be one with an amazing
value.
Kind regards,
Alex
--
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---
Received on Sat Apr 24 2010 - 18:57:36 EDT