Checking the “Feel” of Your UI with an Interaction Audit – Web 2.0 Expo Berlin

The author presented the process that in Ebay leads to interaction audit. But, first of all, what is “feel” and why should i matter?

It’s the feel in look and feel, while many times we just consider the look of the interface. The feel can be considered how you operate the user interface with your own hands.

Feel affects:

  • learning curve
  • mental bandwiith needed to operate the user interface
  • user success (or errors)
  • site personality
  • brand promise
  • adoption (or abandonment)

While developing the Ebay interaction audit the team created a flash demo of the different pages and sections of the Ebay sites. What is interesting to note is that by playing this series of screenshots a little fast it’s possible to highlight several inconsistencies, especially in the structure (eg. headers, logos of different size and in different positions). Creating this sort of animations is very valuable but it’s not expensible or complex to do. They use such animation as a sort of benchmark.

Developing an interaction audit was not like following a strict blueprint. It happened that, based on new findings, they noticed how to improve the process.

Project phases

  • strategy
  • data collection
  • analisisy
  • recommentdations

Strategy

Improvement of user experience on ebay: they made a compelling artifact. They wanted to collect data around the flows. So they imagined flows based on their user behaviour, such as “new users finds an item, bids for it, register as a member”, “new seller lists item for sale, create sellers account”.

They eventually put all on a spreadsheet to see with tasks were common to several flows

Data collection

They used a simple db (filemaker pro). They also captured graphical data.

Database fields used:

  • task and subtask
  • step description
  • page and url
  • action (syntacrtic)
  • screen shot close up
  • instructional text
  • click/keystroke record

Analysis

They printed each record (flows as storyboards) so they could made comparisons. It was like storyboarding in the comics industry.

Ideas for presenting the findings

  • Radial charts to track feel metrics
  • Emotional flow to track feel effects

Recommendations

Here is a list of some of the analysis results

Affordance: a visual cue that some interaction is offered
Affordance inconsistencies
: inconsistencies: hyperlink, tab

Task: a path to accomplish an immediate goal
Task Inconsistencies: a simple goal is accomplished via multiple path: filtering data, enable/disable section of a form

Data objects: a representation of a data record or other piece of data
Data objects inconsistencies
: a single data tye object representede multiple ways: ebay member

Interaction audit goals:

  • low learning curves
  • consistent clues for actions
  • predictable behavior of affordances
  • instant recognition of interface elements
  • allow ebay member content to shine

After being presented the results, the design team was divided in several group (clean-up teams) based on the inconsistencies found:

  • The clickers: links and buttons
  • The swappers : tabbs and toggles
  • the submitters: forms
  • shufflers: sorting
  • disclosers

They work of “cleaning-up” ended creating reusable components thanks to patterns

Clean-up process

  • find problem area
  • recommend simpler set of interactions
  • document design patterns

Feel metrics

objective: page dimension, number of elements, density….
semi-objective: number of syntactic actions, reloadiness, number of tools switches (keyboard, mouse), popup,
subjective: number of different interaction styles, simplicity, flatness, cognitive load

What we’ve learned:

  • it’s important to check feel
  • an interaction audit can be compelling, actionable and part of a real environment
  • audit should focus on flows and be representative of real experience
  • simple tools work
  • audit for inconsistencies in afforfance, task, and data object
  • clena up objects
  • harder problems require site specific values

Pattern e ricerca

Di pattern nel design web ho già parlato in altre occasioni. I pattern sono soluzioni a problematiche ricorrenti, raggruppati in categorie per facilitare la consultazione.

Peter Morville ha raccolto un buon numero di pattern relativi alle ricerche e ai risultati, attingendo da siti più o meno famosi, e li ha pubblicati nel proprio account Flickr, commentando ogni schermata.

Un lavoro certosino che offre una dettagliata panoramica dello stato dell’arte a disposizione di chi si occupa della progettazione e sviluppo di ricerche.

E’ sempre comodo avere qualche riferimento a cui ritornare in caso di necessità. Qualche anno fa ho avuto modo di parlare di The Design of Sites, un manuale che non posso dire di lasciare per più di qualche giorno sullo scaffale.

Progettare e sviluppare per dispositivi mobile

Per lavoro mi sono trovato a dover studiare i principi base dello sviluppo di applicazioni per dispositivi mobili. Ma più che la tecnica, il linguaggio di programmazione, l’aspetto più complesso per chi proviene dal mondo “desktop” è sicuramente la definizione e progettazione dell’interfaccia grafica.

Nelle mie ricerche ho avuto la fortuna di imbattermi in alcuni risorse che mi sento senza dubbio di consigliare.

La prima è il manuale “Designing the Mobile User Experience“, pubblicato da Wiley, che è un’ottima introduzione a questi temi. Secondo l’autrice, Barbara Ballard, il termine “mobile” si riferisce, più che al dispositivo o al software, all’utente e alle situazioni in cui si trova a interagire con queste periferiche.

Questo testo contiene anche utili indicazioni delle differenze con cui i dispositivi mobili vengono usati in Europa, in America e in Asia. Non si tratta semplicemente di variazioni di standard o di protocollo, ma anche di impiego. In America, ad esempio, gli SMS hanno storicamente riscosso minore fortuna che in Europa, a causa di eccessivi prezzi fissati dagli operatori, ma anche per la capillare diffusione della posta elettronica.

La cosa bella di questo manuale è che il capitolo più interessante, il sesto, è in buona parte disponibile anche online sottoforma di wiki. Il capitolo prende in considerazione alcuni pattern di progettazione per i dispositivi mobile, suddivisi in macrocategorie:

  • progettazione dello schermo
  • navigazione all’interno delle applicazioni
  • gestione delle applicazioni
  • pubblicità

Avendo a che fare con dispositivi dalle funzionalità eterogenee, questi sono statti suddivisi in classi di appartenenza. Ciascun pattern fa quindi riferimento a una o più classi, così che sia immediato capire se un pattern è applicabile o meno a una determinata periferica.

Un’altra interessante risorsa, questa volta liberamente scaricabile in formato Pdf, è il documento “Mobile Web Developer’s Guide” scritto da Brian Fling, e si rivolge a chi si proccupi di realizzare siti web che siano accessibili anche ai telefoni cellulari, e in generale alle ultime generazione di dispositivi mobile. Questo testo integra in qualche modo quanto presentato dal manuale della Ballard, avvicinandosi più alle problematiche di sviluppo.