[Sigia-l] (no subject)

[Juan Lanus]

Richard_Dalton at Vanguard.com wrote:

>Could you be more specific?

I can try ... my English is not as good as I need.

You said that the user's complains are about not being able to find, not being able to use.
These are like small fire focus: firemen point at them with a hose (solve each single problem) and they are done.

The non-design approach is to do any design, put it live and then hurry up to extinguish all those fire focus that pop around.
This is what's argued against user-testing laboratories, like for instance what Denise Smith said E Tufte said in a former thread in this NG some days ago (see http://www.info-arch.org/lists/sigia-l/0302/0208.html ).

Tufte said something like "design well and no need at all to test".
In the mathematic limit he might be right, but this doesn't seem to be possible, let alone practical.
This is the all-design approach.

None of both approaches are good, as all extreme positions. But if forced to choose I'd design.

But: how does one make such a good design that doesn't need testing? No way.
But a design that's fine except for some details ...
How many details?
Well, this is the point: the professional quality of the participants is at stake here.

My theoretical approach is 
 1- define requirements
 2- define UI
 3- implement

Define requirements: the solution might be the "use cases" technique, as described in Alistair Cockburn's book "Writing effective use cases".
This book is a tutorial, non-technical, excellent. It has nothing to see with diagrams and those stick figures. It's about writing. After doing the homework you have captured the set of user tasks at an appropriate level and below it if you want to. This is what the system (site) should do seem from outside, seen as a black box.
This is a user-oriented or usage-oriented (as Larry Constantine calls it). It's defined by professionals with users in mind, not by the users themselves.
Always when I think of this I recall a chapter of "The Simpsons" where Homer has a succesfull brother that builds cars. The brother, thinkig that Homer is the paradigm of the average national consumer builds a car on Homer's specs and files for chapter 11. The car is a mongrel of all the contradictory features available.
Jakob Nielsen must have seen it because he recommends to listen users but not to do whay they say   :-)

Define UI: from the user´s standpoint the interface is the site/program, right? The "manifest model". 
In this stage somehow you deduce from the data mentioned in the use cases and from the user goals and from the domain knowledge floating in the air, what a UI could be.
Here when I say "UI" I mean more the navigation schema and the associated data than the surface design of colors and forms. As Larry Constantine defines in their abstract propotypes, with content but void of actual appearance design tokens (see http://www.foruse.com/articles/whatusers.htm http://www.foruse.com/articles/webapplications.htm ).

This step implies a leap: you start not having a design and end up with one. But it's not automatic, and the outcome migght be quite different if different pros would do it. Different correct solutions are possible, as well as infinite bad solutions with different degrees of "horribleness". We all have seen them and ocassionally participated in one such project.
This is what the insurance cannot cover. There is no guarantees that a solution will be a good one, not 100 percent. The better the designers, the better the chances to get a better solution.

Having captured the user requirements into quality use cases might help a lot to drive the designers thru a correct way (not "the" but "a"). Note that the users involved in the use case gathering might well be "personas" as of Alan Cooper. These "personas" want to perform tasks and that's what the use cases capture. Again, the talent of the team will influence the outcome when profiling the personas.

Implement: UI design is over. Now is the time for technology.

--
Well, that's it. 
These are, in fact, the same steps required to perform any IT development, which is the case.
Now, depending on the type of project, the need for the users to gather information in their way to their goals might be of paramount importance and the role of the IA grows relative to the other pros'.

My perception, without having participate in such projects, is that as the users move forward in the quest for performing their goals (which is all about, remember) they need/want data of the sort the site (now it's a site) kind.
So in the context of the ongoing goal seek, the data must be served in a fashion that's integrated with the task. 
What I'm trying to say is that the design of the information interface must be perfectly coupled and subordinate to that of the user's tasks. The user is king. The user ruleZ.  :-)
As when you are in Amazon looking for books: not only you feel empowered to find the data you want (or to easily notice if it's not available) but also you notice with ease what data is offered. Without notice you are moving freely into the mesh: this is how it should be. Like the elevator: you use it without noticing the underlying technology, whth no need to commit to it's design. 

I think that once the user goals are clearly stated and understood then all other pieces fall into their places making a soft click noise.

Richard, sorry if I cant explain myself better. You can't imagine the effort I have to do for such a writing!
Of cource, the issue on what is IA remains open. Curiously enough, I joined this NG because I want to know what's IA about!

Let me recall the first postings, when IA was compared to BA (building A).
When you are in a finely architected house then everything happens with greater ease in a fashion you can't explain. While working in the kitchen then the tools and materials you need are always handy, when you have visits all seems to happen around the living room, when the teenagers have a party the parents can survive and eventually sleep, when in the garden etc ... 
Good architecture helps you live in a way you don't notice. You YES notice when something is wrong, don't you? 




>Richard_Dalton at vanguard.com wrote:
>
>> i've suggested that for our 
>> organization Information Architecture is defined as "finding stuff" and 
>> I/D as "using stuff".
>
>You *must* try "designing stuff" for both. Otherwise you are firemen!
>
>-- 
>Juan Lanus
>TECNOSOL
>Argentina


-- 
Juan Lanus
TECNOSOL
Argentina


__________________________________________________________________
Try AOL and get 1045 hours FREE for 45 days!
http://free.aol.com/tryaolfree/index.adp?375380

Get AOL Instant Messenger 5.1 for FREE! Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promos=380455