Tuesday, July 12, 2005
Company Information Model Vs. Users Information Model
In another posting, I mentioned the difference between building an application around user's conceptual models and around the information architecture adopted inside the company. I believe a real-world example can be useful here. This time it's not from one of the applications I've been working on, but from something I use quite often: internet banking.
The [web] application provided by my bank is entirely built around the company information model. After a login screen, you get a top bar with entries like trading, banking, credit, planning, etc. On the left, there is another bar, with "shortcuts" to the most common services, like wire transfer. The rest of the page is wasted advertising products (does anybody ever read that stuff?).
My routine goes like this: I click on "Statement" on the left. I get into another screen where I can see my Balance (good :-) and I can choose the contents of the statement: all the transactions in the current month, in the latest 3 months, or within 2 dates (= 6 combo boxes) . I normally choose current month. And I get (guess what?) a list :-), although usually not a very long list.
Occasionally I check my credit card (more or less the same workflow as above), or I pay for something (a slightly different road).
Again, this is so commonplace that you may think it's fine. Unfortunately, it's not. This is not the way I (among many others :-) look at my banking account. Consider a different approach. I log in and I immediately get a useful screen: it tells me when I've been there the last time; my previous balance; my current balance; the difference (don't make me think :-); how much money went in and how much went out (this is not the same as the difference between balances!). Everything is an hyperlink, so if I'm interested in the (short!) details of the money that went in, it's just one click away.
Of course, this is just the tip of the iceberg. We can redesign the whole user interaction according to what is useful for the majority of users, while leaving "advanced" features available (with a few more clicks).
The problem (just like with grids) is that it's much easier to build the interface the way they built it. Because in that way, you don't have to know the user. You only have to provide information, using the company information model, which is well understood (internally). Of course, when we don't really know the user, we have no choice but to create a generic application that "leaves the user in control". To add insult to injury, this sense of control it's something most developers like, so they're quite happy to build applications this way. That's why they like grids too :-). They can see all the information there, and feel somewhat "in control". And they may honestly believe that users want that too. Unfortunately (for us all) this is not true. More on this another time :-).
I'll be away for a few days, so unless I get some friendly WiFi hotspot on the road, I'll not be posting for a short while. See you soon!
The [web] application provided by my bank is entirely built around the company information model. After a login screen, you get a top bar with entries like trading, banking, credit, planning, etc. On the left, there is another bar, with "shortcuts" to the most common services, like wire transfer. The rest of the page is wasted advertising products (does anybody ever read that stuff?).
My routine goes like this: I click on "Statement" on the left. I get into another screen where I can see my Balance (good :-) and I can choose the contents of the statement: all the transactions in the current month, in the latest 3 months, or within 2 dates (= 6 combo boxes) . I normally choose current month. And I get (guess what?) a list :-), although usually not a very long list.
Occasionally I check my credit card (more or less the same workflow as above), or I pay for something (a slightly different road).
Again, this is so commonplace that you may think it's fine. Unfortunately, it's not. This is not the way I (among many others :-) look at my banking account. Consider a different approach. I log in and I immediately get a useful screen: it tells me when I've been there the last time; my previous balance; my current balance; the difference (don't make me think :-); how much money went in and how much went out (this is not the same as the difference between balances!). Everything is an hyperlink, so if I'm interested in the (short!) details of the money that went in, it's just one click away.
Of course, this is just the tip of the iceberg. We can redesign the whole user interaction according to what is useful for the majority of users, while leaving "advanced" features available (with a few more clicks).
The problem (just like with grids) is that it's much easier to build the interface the way they built it. Because in that way, you don't have to know the user. You only have to provide information, using the company information model, which is well understood (internally). Of course, when we don't really know the user, we have no choice but to create a generic application that "leaves the user in control". To add insult to injury, this sense of control it's something most developers like, so they're quite happy to build applications this way. That's why they like grids too :-). They can see all the information there, and feel somewhat "in control". And they may honestly believe that users want that too. Unfortunately (for us all) this is not true. More on this another time :-).
I'll be away for a few days, so unless I get some friendly WiFi hotspot on the road, I'll not be posting for a short while. See you soon!
Comments:
<< Home
Innanzitutto buon lavoro o buona vacanza anche se ti auguro che il motivo dell'assenza sia il secondo. La domanda sorge spontanea. Hai provato a sottoporre le tue idee alla tua banca, magari prima come cliente (Pare che il cliente conti, ma forse solo in quanto ha un conto ;-) e poi come professionista in grado di fornire un prodotto di internet-banking migliore?
Credo però che il lavoro non ti manchi anche se non dispiace a nessuno allungare la lista dei propri movimenti (In avere, ovviamente).
Credo però che il lavoro non ti manchi anche se non dispiace a nessuno allungare la lista dei propri movimenti (In avere, ovviamente).
# posted by 
: 9:48 AM
: 9:48 AM
Non è che io abbia molta esperienza in questo campo, però stavo pensando: ottenere il modo di pensare di un utente non è certo facile, bisognerebbe fargli usare il programma e sapere che ne pensa, ma se lo stiamo progettando, come si fa? Come facciamo a capire quali sono le informazioni rilevanti da quelle che non lo sono senza far provare il prodotto? Capisco che un po' di esperienza ci si può arrivare, ma esiste un metodo alterativo?
# posted by : 11:06 AM
: 11:06 AM
Per Romano: in effetti non ho fatto alcuna avance :-) alla mia banca. Comunque lavoro per diverse banche ed avevo un conto presso una banca mia cliente, che non era messa particolarmente meglio come internet banking. Un classico esempio delle organizzazioni troppo conservative che citavo in un precedente posting. In queste organizzazioni, alcune cose carine a livello di interaction design si riescono a fare, ma ci sono anche resistenze molto difficili da vincere per andare un po' oltre. Non impossibili da vincere, ma sicuramente molto molto difficili...
Per Fulvio: come si dice in questi casi, "bella domanda!" :-). Ti rispondo in un posting dedicato, magari domani se altre cose non prendono il sopravvento. La risposta breve ovviamente e' che esistono molti metodi alternativi (per fortuna :-). La progettazione dell'interazione e' proprio quello: progettazione. Cosi' come esistono metodi ed approcci per progettare la struttura interna del software prima di scriverlo, cosi' esistono metodi ed approcci per progettare una buona interazione senza dover attendere uno usability test (che poi rivela comunque cose utili, se si sanno interpretare correttamente i risultati).
Post a Comment
<< Home
