Así que puedo declarar que esta heurística es mía. Es la Heurística de Bustelo.

Principio: Las interfaces deben liberar al usuario de tareas repetitivas, aprovechando la capacidad de las computadoras para automatizar procesos. No hacerlo es desperdiciar el potencial del medio digital y castigar la eficiencia del usuario.

Ejemplo: La interfaz que muestro a continuación, que mi banco nos inflige a todos sus clientes, nos obliga a hacer un click por cada comprobante que necesitamos descargar.

A la hora de hacer el cierre fiscal, son 72 clicks que hay que hacer con cuidado de no saltearse nada: 2 tarjetas x 12, 3 cuentas x 12, y un año de Inversiones. Y eso, suponiendo que no tenés Préstamos, y sin contar los clicks que hay que hacer para pasar de una pestaña a la otra.

Todo ello, teniendo cuidado en cada click y haciendo scroll lentamente para no perder la guía (porque no hay distinción entre íconos cliqueados vs. aún sin cliquear).

El proceso puede llevar hasta una hora. Que se podría evitar con un enlace o botón de “descargar todo”. Es decir, aplicando la heurística de la naturaleza digital: el principio de que las computadoras están diseñadas para manejar tareas repetitivas de manera eficiente. Esta heurística enfatiza la importancia de aprovechar la tecnología para automatizar y simplificar procesos, asegurando que los sistemas e interfaces estén optimizados para acciones repetitivas, mejorando así la eficiencia del usuario y reduciendo la probabilidad de errores.

Santiago Bustelo
Mayo 2024

La entrada Heurística de la naturaleza digital: “las computadoras se inventaron para realizar tareas repetitivas”. se publicó primero en Kambrica.

Un prototipo no es una versión preliminar del diseño: es una herramienta económica para lograr respuestas. De qué estará hecho, cómo y con qué nivel de detalle, dependerá de las preguntas que tengan sentido en ese momento del proyecto.

Les comparto algunos ejemplos de cómo prototipando con código, podemos hacer y responder mejores preguntas de UX Research, tanto en procesos de evaluación interna, como con personas usuarias reales.

Prototipos HTML5: formularios, sacar selfies…

Por ejemplo, cuando las preguntas que necesitamos hacernos tienen que ver con la usabilidad de un formulario, no servirá de nada un “prototipo” estático en Figma, donde haciendo click mágicamente se completen los campos y los usuarios puedan avanzar manoteando el mouse y sin mirar la pantalla.

Para evaluar la usabilidad de un formulario, necesitaremos poner a prueba un prototipo operable del formulario.

Puede alcanzar con unas pocas líneas de HTML que nos permitan ver la experiencia de los usuarios completando los datos que les pedimos:

<label for="cuil">Número de CUIL:</label><br>
<input id="cuil" type="number" name="cuil" size="11" min="20000000000">
<br><br>
<input type="reset">
<input type="submit" value="Continuar">

Sólo así podremos hacer y contestar preguntas sobre los usuarios como:

• ¿Se saben el dato de memoria, o necesitan buscarlo?
• ¿Lo tipean, o lo copian y lo pegan?
• ¿Lo ingresan sin guiones, como quiere IT? ¿O podemos demostrar que esa restricción es innecesaria y perjudicial?
• ¿Hace sentido la validación que estamos usando?
• ¿Cuál teclado es mejor para completar este dato en móvil? ¿El que presenta INPUT type=”number”, o el de type=”tel”?
• ¿Tiene sentido el “stepper” que muestra el INPUT type=”number” en la versión desktop?
• ¿Es necesario el botón “restablecer” que insisten en poner los de sistemas? ¿O podemos demostrar al Negocio que es una pésima idea, y lograr que IT deje de opinar sobre este tema?

Con este enfoque, en Kambrica pudimos no sólo resolver casos de ingreso de información, sino también prototipar el uso de cámara en móvil – y así identificar los verdaderos problemas que tenían los usuarios para registrarse en una App financiera. Problemas que sólo se manifestaban al usar las cámaras del celular, una de las tantas cosas que se pueden hacer con HTML5:

<!--
// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

El elemento HTML5 para la cámara es INPUT:file. 
Como es MUY diferente al elemento que necesitamos mostrar en el prototipo,
y no podemos maquillarlo con CSS, usaremos un botón común para la acción.
Ese botón hará click en el INPUT:file invisible.
-->

<!-- Usar cámara para selfies -->
<button
 onclick="document.getElementById('camara-selfie').click()"
 >Sacar selfie</button>
<input
 style="visibility:hidden;"
 id="camara-selfie" 
 type="file" accept="image/*, video/*" capture="user">

<br><br>

<!-- Usar cámara para tomar fotos: -->
<button
 onclick="document.getElementById('camara-principal').click()"
 >Sacar foto al DNI</button>
<input
 style="visibility:hidden;"
 id="camara-principal" 
 type="file" accept="image/*, video/*" capture="environment">

Prototipando datos… un montón de datos

Cuando las preguntas que nos queremos hacer tienen que ver con cómo nuestros usuarios visualizan y manejan grandes volúmenes de datos, no podemos mostrarles un “lorem ipsum” repetido 100 veces.

Inventar un volumen de datos grande y variado no sólo resulta tedioso – es muy complicado mantenerlos de forma consistente en todas las pantallas que tengamos que prototipar. Y si necesitamos mostrar muchos datos distintos sobre una misma vista (por ejemplo, mostrar diversas combinaciones de datos sobre la plantilla “ficha del cliente”), crear las variantes a mano puede resultar absurdo.

Resulta mucho mejor generar estos datos de manera mecánica.

Por ejemplo, podemos crear números de teléfono (entre 1000–0000 y 5999–9999) como números aleatorios. En una planilla de cálculo, podrímos usar la fórmula RANDBETWEEN( mínimo, máximo ):

HTML no tiene esa funcionalidad. Pero sirviendo nuestro prototipo desde un entorno local como MAMP o un hosting Apache del montón, es bastante sencillo “inyectar” funcionalidad PHP en medio del código HTML:

<!-- HTML original: 100 filas y números a mano -->
<table>
 <tr><td>1</td><td>28828534</td></tr>
 <tr><td>2</td><td>46326679</td></tr>
 <tr><td>3</td><td>24144353</td></tr>
…
 <tr><td>100</td><td>24464010</td></tr>
</table>


<!-- Versión PHP, generando 100 filas y números de forma mecánica -->
<table>
<?php for ($i = 1; $i <= 100; $i++) { ?>
 <tr><td><?= $i ?></td><td><?= rand( 10000000, 59999999 ) ?></td></tr>
<?php } ?>
</table>

Con muy poco esfuerzo, habremos logrado 100 filas de “números de teléfono”… que nos deberían inspirar a ponerles un guión en el medio para hacerlos más legibles.

Aquí, antes y después:

Para crear el ejemplo de la derecha, generamos dos números aleatorios con un guión en el medio: <?= rand( 1000, 5999 ) ?>-<?= rand( 1000, 9999 ) ?>

Este enfoque aplica muy bien cuando los datos para prototipar son numéricos, y es verosímil que cambien cada vez que volvemos a cargar la página.

Pero… ¿Qué sucede cuando los datos que queremos prototipar no son numéricos? ¿Y qué pasa si necesitamos que sean siempre los mismos cada vez que se visita la misma pantalla?

Prototipando datos pseudo aleatorios

Vamos a empezar con la pseudo-aleatoriedad: generar los datos de una manera mecánica no predecible, y que sea siempre la misma. Es decir, en lugar de “1,2,3,4”, mostrar por ejemplo “21,6,89,53” cada vez que presentemos los primeros cuatro números de la lista.

En lugar de una función rand() que nos devuelva un número distinto cada vez que la llamamos, necesitamos una función noTanRand($i) que nos devuelva un valor “raro” para el $i que le pasamos, siendo $i el número de item: el que en el código de ejemplo anterior, usamos en for( $i… ).

Esa función que necesitamos, la podemos construir con un algoritmo de hash. Usando la función nativa de PHP, podemos tomar un string cualquiera, y devolver un número entre 0 y 1 (como haría rand() sin argumentos):

<?php

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function noTanRand($seed){
 $hash = md5($seed); //Obtenemos hash hexadecimal, ej. "cfcd208495d565ef66e7dff9f98764da">
 $result = hexdec(substr($hash, 0, 8)) //tomamos los primeros 8 caracteres, de string a número: 4 bytes (2 ^ 8 * 4 )
           / (pow(2, 32) - 1); //y dividimos por el máximo posible para obtener nuestro número entre 0 y 1
 return $result;
}

// Probamos la función:
for( $i = 0; $i <= 10; $i++) {
    echo ( noTanRand($i).", " );
}

// Resultado:
// 0.81172374002908, 0.76871122251468, 0.78171459161251, 0.92498448466067, 0.65820255727931, 0.8939549624673, 0.087784356458062, 0.5589125378893, 0.78883317620233, 0.27253036533308, 0.82753398474947,

?>

Eso está bastante bien. Aunque para prototipar, quizás nos vendría aún mejor una función que, desde PHP o JavaScript, nos devolviera el mismo resultado. A la que podamos pasarle un string, un número, o cualquier cosa. Y a la que podamos opcionalmente definirle un número mínimo y un máximo.

Como en JavaScript no disponemos de la misma función nativa que en PHP, necesitamos construir un algoritmo de hash para las dos versiones. Después de algunas pruebas, logramos el siguiente código adaptando el algoritmo ‘times 33’ de Daniel J. Bernstein implementado por Matt Barker. En honor a D.J., llamaramos a nuestra función… djash:

<?php
/* djash - Versión PHP: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djash($input,$desde=0,$hasta=1) {
    $salt = "Salt para darle gusto al hash";

    // Convierte el input a una cadena si no lo es
    if (!is_string($input)) {
        if (is_object($input)) {
            $input = json_encode($input);
        } else {
            $input = strval($input);
        }
    }

    // Agrega el salt al input
    $input .= $salt;

    $hashValue = 5381;
    for ($i = 0; $i < strlen($input); $i++) {
        $char = ord($input[$i]);
        $hashValue = ($hashValue * 33) ^ $char;       
  $hashValue = $hashValue & 0xFFFFFFFF; // Recorta el número a 32 bits
    }

   // Normalizamos el número al rango [0, 1] y aplicamos desde/hasta:
   $resultado = ( $hashValue / (pow(2, 32) - 1) ) * ($hasta - $desde) + $desde;
   if( $desde != 0 || $hasta != 1){ $resultado = floor ( $resultado ); }
   return $resultado;
}
?>

<script>
/* djash - Versión JavaScript: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djash(input, desde = 0, hasta = 1) {
  const salt = "Salt para darle gusto al hash";

  // Convierte el input a una cadena si no lo es
  if (typeof input !== "string") {
    if (typeof input === "object") {
      input = JSON.stringify(input);
    } else {
      input = input.toString();
    }
  }

  // Agrega el salt al input
  input += salt;

  let hashValue = 5381;
  for (let i = 0; i < input.length; i++) {
    const char = input.charCodeAt(i);
    hashValue = (hashValue * 33)  ^ char;
    hashValue = hashValue  >>> 0; // Convertir a 32 bits
  }

  // Normalizamos el número al rango [0, 1] y aplicamos desde/hasta:
    let resultado = (hashValue / (Math.pow(2, 32) - 1)) * (hasta - desde) + desde;
    if (desde !== 0 || hasta !== 1) { 
        resultado = Math.floor(resultado);
    }
    return resultado;
}
</script>

Después de algún que otro bug, comprobamos que –dígito más, dígito menos– las dos funciones nos dan el mismo valor para cada $i:

Bueno, ya tenemos nuestra función para armar datos numéricos. Podemos usarla para pedirle nos devuelva un elemento pseudo-aleatorio de un array:

<?php
/* djitem - Versión PHP: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djitem( $array, $ix ) {
 //$ix: admite un número entre 0 y 1; caso contrario obtenemos djash de $ix 
 if ($ix <= 0 || $ix >= 1) { $ix = djash($ix); }

 $totalItems = count($array);
 $weightedIndex = floor($ix * $totalItems);
 return $array[$weightedIndex];
}

/* djitem - Versión JavaScript: */

// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional

function djitem(array, ix) {
    // Si ix está fuera del rango [0, 1], calculamos djash de ix
    if (ix <= 0 || ix >= 1) { ix = djash(ix); }

    var totalItems = array.length;
    var weightedIndex = Math.floor(ix * totalItems);
    return array[weightedIndex];
}
?>

Ese array puede ser una lista de provincias, apellidos… Por ejemplo, si tomamos una lista de 100 apellidos, y usamos dos para cada item variando el $ix en el segundo (concatenándole algún texto cualquiera), podemos lograr 10.000 combinaciones:

Resultados para ( djitem($DB_apellidos, ($i)). “ “ . djitem( $DB_apellidos, ($i.” dos”)) );

Y usando doble nombre y apellido, podríamos generar millones de clientes ficticios para un sistema de gestión:

Y podemos hacer que el link nos lleve a la ficha del cliente, con más datos. Datos que generaremos en base al índice del cliente, por lo que serán siempre consistentes para el mismo link.

Como la dirección, que creamos con un apellido y un número, más piso y departamento. Y cuidando, para que sea bien verosímil, de llamar “PB” al piso “0”. Así como de usar letras para el departamento en el 70% de los casos, y números en el resto.

También podemos mostrar planes de pagos para los clientes con balance negativo. O hasta una serie de muestras de color basadas en el ID del cliente:

O sea, podemos hacer cualquier cosa que necesitemos, siguiendo la lógica de cada caso. Cosas como:

• Establecer diferentes condiciones según su probabilidad (ej. “Roaming activado” para el 63% de los clientes, “Sin 4G” para el 7.5%, etc.)
• Fechas de nacimiento, números de DNI y CUIL verosímiles para la demografía de nuestros usuarios,
• Productos en sus últimas compras (tomados de nuestro catálogo),
• Calcular series numéricas y balances financieros,
• Mostrar imágenes aleatorias de una lista,
• Poner un punto en el mapa con latitud y longitud (dentro de un rango definido, para evitar caer en el medio del mar),
• Mostrar textos (ej. mensajes enviados por el cliente) en base a una o más listas de modelos de frases… según probabilidad de las casuísticas de consulta / gestión / reclamo.

Aplicando estos criterios, en Kambrica logramos prototipar un sistema con más de 50.000 clientes y reglas de negocio sumamente complejas. Ajustando el prototipo de manera iterativa en base a las observaciones con usuarios, encontramos formas más claras de presentar la información y flujos de operación más eficientes – al punto de que los usuarios pudieron empezar a ver y resolver casos que llevaban meses sin haber detectado.

Demo y código PHP del ejemplo

Pueden ver este prototipo de ejemplo funcionando en: https://demos.kambrica.com/djash

Para que puedan incorporar este enfoque en sus proyectos, les dejo más abajo el código de estos últimos ejemplos.

Espero les resulte útil y no duden en escribirnos si necesitan apoyo o quieren llegar más lejos: en Kambrica llevamos más de 10 años trabajando procesos de capacitación, consultoría y mentoría con equipos de UX, IT y Producto para mejorar sus procesos y resultados :)

<?php
// *** _funciones.php ***

// Funciones para prototipar datos en gran volumen.
// Santiago Bustelo, Kambrica.com
// Publicado bajo licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional
// https://creativecommons.org/licenses/by-sa/4.0/deed.es


$DB_nombres = [
 "M" => [ /* Masculinos: primeros por frecuencia en Argentina según https://forebears.io/argentina/forename, corregidos (no tenían acentos)s */
  "Juan","José","Carlos","Jorge","Luis","Miguel","Héctor","Ramón","Roberto","Oscar","Daniel","Mario","Pedro","Ricardo","Raúl","Pablo","Eduardo","Sergio","Marcelo","Julio","Hugo","Alberto","Rubén","Gustavo","Antonio","Víctor","Francisco","Diego","Ángel","Alejandro","Claudio","Walter","Fernando","Néstor","Guillermo","Manuel","Cristian","Martín","Alfredo","Enrique","Osvaldo","Javier","Gabriel","Horacio","César","Rodolfo","Omar","Andrés","Ariel","Ernesto","Leonardo","Domingo","Marcos","Nicolás","Sebastián","Adrián","Norberto","Mariano","Esteban","Darío","Fabián","Edgardo","Rafael","Vicente","Orlando","Gerardo","Jesús","Hernán","Federico","Félix","Aldo","Armando","Adolfo","David","Emilio","Germán","Aníbal","Lucas","Mauricio","Humberto","Ignacio","Agustín","Felipe","Leandro","Tomás","Abel","Gregorio","Luciano","Segundo","Rolando","Gastón","Nelson","Maximiliano","Salvador","Lorenzo","Christian","Silvio","Arturo","Rodrigo","Mauro","Dante","Bernardo","Gonzalo","Rogelio","Julián","Eugenio","Ismael","Marcelino","Santiago"
  ],
 "F" => [ /* Femeninos, primeros por frecuencia en Argentina según https://forebears.io/argentina/forenames, corregidos (no tenían acentos) */
  "María","Ana","Silvia","Rosa","Norma","Marta","Claudia","Graciela","Mónica","Susana","Mirta","Alicia","Patricia","Nélida","Juana","Liliana","Sandra","Laura","Olga","Andrea","Elsa","Ramona","Adriana","Marcela","Carmen","Lidia","Teresa","Gabriela","Gladys","Verónica","Blanca","Natalia","Margarita","Irma","Beatriz","Mercedes","Alejandra","Dora","Elena","Ángela","Cristina","Lorena","Delia","Isabel","Stella","Mariana","Mariela","Nilda","Estela","Nancy","Sara","Nora","Viviana","Lucía","Analía","Julia","Luisa","Miriam","Karina","Antonia","Paola","Carolina","Cecilia","Sonia","Hilda","Mabel","Elba","Valeria","Rosana","Silvana","Silvina","Paula","Carina","Yolanda","Francisca","Noemí","Elvira","Romina","Celia","Marisa","Gloria","Clara","Angélica","Inés","Daniela","Josefa","Catalina","Eva","Raquel","Martha","Marina","Élida","Rita","Roxana","Griselda","Haidé","Vanesa","Esther","Amalia","Elisa","Amelia","Victoria","Zulema"
  ]
 ];

$DB_apellidos = [ /* primeros por frecuencia en Argentina según https://forebears.io/argentina/surnames, corregidos (no tenían acentos) */
"González","Rodríguez","Gómez","Fernández","López","Díaz","Martínez","Pérez","García","Sánchez","Romero","Sosa","Torres","Álvarez","Ruiz","Ramírez","Flores","Benítez","Acosta","Medina","Herrera","Suárez","Aguirre","Giménez","Gutiérrez","Pereyra","Rojas","Molina","Castro","Ortiz","Silva","Núñez","Luna","Juárez","Cabrera","Ríos","Morales","Godoy","Moreno","Ferreyra","Domínguez","Carrizo","Peralta","Castillo","Ledesma","Quiroga","Vega","Vera","Muñoz","Ojeda","Ponce","Villalba","Cardozo","Navarro","Coronel","Vázquez","Ramos","Vargas","Cáceres","Arias","Figueroa","Córdoba","Correa","Maldonado","Paz","Rivero","Miranda","Mansilla","Farías","Roldán","Méndez","Guzmán","Agüero","Hernández","Lucero","Cruz","Páez","Escobar","Mendoza","Barrios","Bustos","Ávila","Ayala","Blanco","Soria","Maidana","Acuña","Leiva","Duarte","Moyano","Campos","Soto","Martín","Valdez","Bravo","Chávez","Velázquez","Olivera","Toledo","Franco","Ibañez","Leguizamón","Montenegro","Delgado","Arce","Ibarra","Gallardo","Santillán"
];


// Aprovecharemos función nativa PHP para mostrar currency
$formatUSD = new NumberFormatter('en_US', NumberFormatter::CURRENCY);



function djash($input) { 
// Devuelve un número entre 0 y 1, siempre el mismo para el mismo $input.

    // Salt hardcodeado
    $salt = "Salt para darle gusto al hash";

    if (!is_string($input)) {
        if (is_object($input)) {
            $input = json_encode($input);
        } else {
            $input = strval($input);
        }
    }

    // Agrega el salt al input
    $input .= $salt;

    // Función de hash básica basada en el algoritmo 'times 33' de Daniel J. Bernstein.
    $hashValue = 5381;
    for ($i = 0; $i < strlen($input); $i++) {
        $char = ord($input[$i]);
        $hashValue = ($hashValue * 33) ^ $char;       
  $hashValue = $hashValue & 0xFFFFFFFF; // Recorta el número a 32 bits
    }

 // Normalizamos el número al rango [0, 1]
   return $hashValue / (pow(2, 32) - 1);
}



function djitem( $array, $ix ) {
// Devuelve un item ($ix: djash) de un $array.
// $ix puede ser: djash entre 0 y 1, o un string/número/objeto del cual obtener un djash.

 //$ix: admite un número entre 0 y 1; caso contrario obtenemos djash de $ix
 if ( !is_numeric($ix) || ( $ix <= 0 || $ix >= 1) ) { $ix = djash($ix); }
 
    $totalItems = count($array);
    $weightedIndex = floor($ix * $totalItems);
    return $array[$weightedIndex];
}



function djnombre( $seed, $what = "N A" ){
// Devuelve un string según djash $seed, siguiendo instrucciones de $what
// Ejemplo de uso: djnombre( "0", "[s] n n a a: (11) dddd-dddd" );

// $seed = string para alimentar djash.
// $what =  cada caracter codifica un térmono a devolver:
//  D: dígito.
//  M: nombre masculino.
//  F: nombre femenino.
//  N: nombre masculino o femenino (50% de probabilidad inicial; siguientes usos en $what tendrán mismo género).
//  A: apellido.
//  S: devuelve literalmente "m" o "f" (50% de probabilidad cada opción, ), para uso en funciones.
//  Cualquier otro caracter se devuelve como se recibió.
//  Default: "n a" (nombre, espacio, apellido).

 global $DB_nombres ;
 global $DB_apellidos ;

 $result = "";
 $what = str_split( $what );
 $whatix = 0;
 $sexo = djash($seed) > .5 ? "M" : "F" ; //Calculamos M/F al azar 50/50 chances.


 foreach( $what as $whatChar ){
  $pr = djash( $seed . $whatix . $result ); //Para cada caracter usaremos un seed distinto.

  switch ( $whatChar ) {
  
   case "D": //digito entre 0 y 9
    $result .= floor( $pr * 10 );
    $whatix++;
    break;

   case "S": //imprimimos el $sexo generado por djash (con break)
   case "N": //…o solo lo usamos para continuar en los casos m/f: (no hacemos break)
    if(  $whatChar == "s" ){
     $result .= $sexo;
     break;
     }
       
     case "M":
     case "F":
    //nombre masculino o femenino
    //estos dos casos toman $sexo de $whatChar:
    if( $whatChar == "M" || $whatChar == "F" ){
     $sexo = $whatChar;
     }
    $result .= djitem( $DB_nombres[ $sexo ], $pr);
    $whatix++;
    break;

     case "A":
    //apellido
    $result .= djitem( $DB_apellidos, $pr);
    $whatix++;
    break;
   
     default:
    //si no es un caracter codificado, lo concatenamos en output como vino.
    $result .= $whatChar ;
    //no afectamos $whatix
      
    };

 };

 return ( $result );
}

?>

<?php // *** clientes.php ***

include_once('_funciones.php');

?><!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title></title>
 <meta name="viewport" content="width=360, initial-scale=1" />

<style>
BODY{
 font-family: arial,sans-serif;
 font-size:14pt;
 line-height:140%
 }
</style>

</head>


<body>


<ol>

<?php
 
 // Loop
 for ($i = 0; $i <= 1000; $i++) {
 
  //calculamos balance del cliente, puede ser negativo:
  $balance =  ( djash($i)*100000 ) - 30000;
  $balanceColor = $balance < 0 ? "red" : "#999";
 ?>

 <li style="float:left; width:380px" id="cliente-<?= $i ?>">
  <!-- Pasamos el $i como id del cliente por URL (variable $_GET de PHP) -->
  <a href="cliente.php?id=<?= $i ?>"><?= djnombre( $i, "N&nbsp;N A&nbsp;A"  ) ?></a><br>
  <?= djnombre( $i, "11 DDDD-DDDD"  ) ?><br>
  <span style="color:<?= $balanceColor ?>"><?=  $formatUSD->formatCurrency( $balance , 'USD' ) ?></span><br>
  &nbsp;
 </li>

<?php
 } // Fin loop
 ?>

</ol>


</body>
</html>

<?php //*** cliente.php ***

include_once('_funciones.php');

// Tomamos $id del URL (variable de $_GET):
$id = $_GET['id'] ?? 0;


?><!DOCTYPE html>
<html>
<head>
 <meta charset="utf-8">
 <title></title>
 <meta name="viewport" content="width=360, initial-scale=1" />

<style>
BODY{
 font-family: arial,sans-serif;
 font-size:14pt;
 line-height:140%
 }
</style>
</head>

<body>


<?php

 //calculamos balance del cliente, puede ser negativo:
 $balance =  ( djash($id)*100000 ) - 30000;
 $balanceColor = $balance < 0 ? "red" : "#999";
 
 //calculamos piso y departamento para la dirección. 
 $direccion_depto = //el depto puede ser numerico (30% de los casos) o una letra (resto) 
  djash( $id." salt-piso-numerico" ) < 0.3 ?
   floor( djash($id." salt-piso")*9 * 3 + 1 ) //hasta 3 deptos por piso
   :
   djitem( [ "A","B","C","D" ] , ( $id . " salt-piso") )
   ;
 
 $direccion_piso = floor( djash($id." salt-piso")*9 );
 
 //creamos el string de Piso y depto:
 $direccion_pisodepto = "Piso " . $direccion_piso . " Depto. " . $direccion_depto;
 // … excepto en casos de Planta Baja.
 if( $direccion_piso == 0 ){
  $direccion_pisodepto = "PB Depto. " . $direccion_depto;
  }

?> 

<p>
 <span style="float:right">
  Cliente #<?= $id ?>
  <a href="?id=<?= intval($id) -1 ?>">&laquo; anterior</a>
  |
  <a href="?id=<?= intval($id) +1 ?>">siguiente &raquo;</a>
 </span>
 <span><a href="clientes.php#cliente-<?=$id?>">&laquo; volver</a></span>
</p>

<hr>

<h1 style="width:480px;line-height:100%"><?= djnombre( $id, "N&nbsp;N A&nbsp;A"  ) ?></h1>

<p>
 <b>Balance:</b> <span style="color:<?= $balanceColor ?>"><?=  $formatUSD->formatCurrency( $balance , 'USD' ) ?></span>
</p>

<?php //si el balance es negativo, planteamos planes de pagos de 3, 6 o 12 cuotas, con 10%, 20% o 30% de recargo
 if( $balance <0){
  $cuota3 = $balance * -1 / 3 * 1.1;
  $cuota6 = $balance * -1 / 6 * 1.2;
  $cuota12 = $balance * -1 / 12 * 1.3;
 ?>
 <h4>Plan de pagos:</h4>
 <ul>
  <li>
   <?= $formatUSD->formatCurrency( $cuota3, 'USD' ) ?>
   x 3 cuotas =
   <?= $formatUSD->formatCurrency( $cuota3 * 3, 'USD' ) ?>
  </li>
   
  <li>
   <?= $formatUSD->formatCurrency( $cuota6, 'USD' ) ?>
   x 6 cuotas =
   <?= $formatUSD->formatCurrency( $cuota6 * 6, 'USD' ) ?>
  </li>
  
  <li>
   <?= $formatUSD->formatCurrency( $cuota12, 'USD' ) ?>
   x 12 cuotas =
   <?= $formatUSD->formatCurrency( $cuota12 * 12, 'USD' )  ?>
  </li>
  
 </ul>
<?php
 } //endif balance negativo
 ?>


<h2>Datos del Cliente</h2>
<ul>
 <li><b>Teléfono:</b> <?= djnombre( $id, "11 DDDD-DDDD"  ) ?></li>
 <li><b>Dirección:</b> <?=
  djnombre( $id." salt-calle" , "A " ) .
  floor( djash($id)*5000 ) . " " .
  $direccion_pisodepto 
  ?></li>
</ul>


<h2>Muestras de color:</h2>

<?php
 for ($i = 1; $i <= 5; $i++) {
  // Creamos un color hex basado en $id y $i:
  $djcolor = dechex( intval( djash( $id . " color " . $i) * hexdec( "ffffff") ) ); // intval() hace la conversión implícita para evitar Warning "PHP Deprecated: Implicit conversion from float to int loses precision"
 ?><div style="display:inline-block; width:80px; height:80px; border:1px solid #ccc; margin:0 5px 5px 0; background-color: #<?= $djcolor ?>"></div><?php
 } //end for
 ?>

</body>
</html>

La entrada Prototipando con código para pruebas con usuarios se publicó primero en Kambrica.

Clase online para diseñadores en el marco del curso “Seniority UX“.

Una clase que los ayudará a aprender sobre una de las habilidades distintivas que debe tener un diseñador, saber presentar su trabajo frente a un cliente.

Veremos algunos tips sobre cómo prepararte antes, durante y después de una reunión. Cómo fundamentar tus decisiones, hacia donde enfocar la presentación y como comunicarte de manera efectiva con la audiencia.

A quién esta dirigido

Para diseñadores de todos los niveles y para leaders que quieran motivar e impulsar este skills para su equipo.

Te irás sabiendo

• Cómo prepararte para una reunión.
• Cómo comunicarte con tu cliente (ya sea interno o externo).
• Qué formatos usar en una presentación.
• Cómo presentar opciones de diseño.
• Cómo manejar las objeciones de la audiencia.
• Cómo recibir feedback.
• Cómo cerrar una presentación.

Al finalizar

Recibirás por mail el material de la charla. La presentación en PDF que se mostrará durante la misma y el video de los oradores presentando.

Oradores

Román Paparella, Product Designer en Kambrica.
Pamela Vanni, UX Lead en Kambrica.

¡Próximamente! Apertura de inscripciones

Si querés enterarte cuando esté abierta la convocatoria de inscripciones como parte del curso “Seniority UX“, escribinos un mensaje y te avisamos!

Gran charla sobre una temática que los diseñadores vivimos a diario y pocas veces, nos detenemos a analizar para encarar de una mejor manera. Muy interesante el enfoque, con ejemplos claros para una fácil comprensión. El modo de llevar adelante la charla, habla de una gran experiencia en el campo. ¡Espero ansioso nuevas charlas! Lucas de Recarga Pay.

La entrada Cómo presentar diseño se publicó primero en Kambrica.

Desde 2012 trabajamos junto a los equipos de Producto Digital del Grupo Telefónica diseñando y mejorando las experiencias de usuario web y móvil con las que interactúan millones de personas.

Ayudamos a mejorar la usabilidad de los procesos de compra de telefonía fija, móvil e internet para incrementar ventas, reducir llamados al call center y optimizar procesos. 

Trabajamos en el desarrollo de landings promocionales, mejoras en los procesos de atención al cliente y comunicación de productos y ofertas, mejorando la comprensión y captación de la propuesta de valor.

• Disminuimos los costos de soporte y redujimos la frustración de los usuarios.
• Ayudamos a mejorar la madurez en UX de los equipos de producto digital, con impacto en otras áreas de la compañía.

Cómo ayudamos

• Rediseñamos la home de telefonía fija y móvil.
• Mejoramos los flujos de navegación del sitio.
• Rediseñamos el flujo de compra de planes de telefonía móvil.
• Rediseñamos el flujo de compra de planes de Internet.
• Rediseñamos el flujo de compra de fibra y planes de TV.
• Diseñamos y mejoramos el impacto de landings promocionales: portabilidad, Hotsale, Multiplicate, día de la madre, del padre, etc.
• Mejoramos los procesos de descubrimiento, adquisición y upselling de líneas telefónicas, Internet y líneas móviles.
• Mejoramos los procesos de autogestión de grandes clientes.
• Mejoramos la calidad de la información de la sección Atención al Cliente.
• Análisis de usabilidad y necesidades de comunicación para el lanzamiento del rediseño de la app de Movistar.
• Análisis de usabilidad y propuestas de mejora accionables para procesos críticos de negocio.
• Análisis cualitativo y cuantitativo de la performance de páginas y flujos específicos.
• Creamos el primer manual de usabilidad para la compañía, permitiendo alinear a todas las áreas.
• Creamos herramientas para reducir costos y tiempos en procesos de toma de decisiones, diseño y desarrollo.
• Desarrollo de workshops con stakeholders para definir visión de producto, facilitar la toma de decisiones de producto y diseño.
• Capacitaciones sobre metodología Lean UX, diseño centrado en el usuario, Design Thinking.

La entrada Movistar se publicó primero en Kambrica.

Además de desafíos técnicos particulares, el desarrollo de software para dispositivos táctiles y móviles requiere satisfacer necesidades y contextos de uso muy diferentes a las que se dan en entornos de escritorio.

Conocer estas dimensiones es esencial para lograr software que los usuarios finales puedan realmente aprovechar y valorar. Las guías oficiales de diseño de interfaces para cada plataforma son un paso indispensable, y a la vez son sólo la punta del iceberg.

Esta presentación muestra el proceso de diseño y desarrollo centrado en el usuario necesario para lograr buenos resultados.

La entrada UX Touch vs. Ouch! User Experience para dispositivos móviles se publicó primero en Kambrica.

Presentado en:

• Artmedia 2016: Universidad Maimónides / CCGSM, Jueves 10 de noviembre 2016
• Interaction South America 2016: IxDA / Universidad Católica de Chile, Jueves 3 de noviembre, 2016
• XI Encuentro Latinoamericano de Diseño: Universidad de Palermo, Martes 26 de julio, 2016

El software se está comiendo al mundo: no sólo hoy resulta omnipresente, sino que sus prácticas y metodologías están cambiando la forma misma de planear y hacer las demás cosas. El Diseño de Experiencias (UX), surgido en el contexto del software, está empezando a abarcar e impactar a las demás disciplinas de diseño, marcando su futuro.

En esta presentación haremos un breve repaso de los hitos de los últimos 15 años en el Diseño de Experiencias, y proyectando la dirección que tendrán en los próximos 15 todas las disciplinas de diseño.

La entrada El futuro del Diseño y UX: los 15 años que se vienen se publicó primero en Kambrica.

En 2010 el banco Santander Río necesitaba migrar la solicitud de sus productos del canal físico al online. Hasta ese momento el pedido de tarjetas de crédito era un trámite que muy pocos clientes estaban dispuestos a realizar de forma online.

Los motivos: escasa confianza en el canal online y formularios que requerían datos que los usuarios no comprendían o no estaban dispuestos a completar.

Áreas de trabajo

Rediseñamos todos los formularios de contratación siguiendo buenas prácticas de usabilidad y accesibilidad.

• UX Research para evaluar los procesos existentes, motivaciones e intereses de los usuarios, oportunidades y áreas de mejora.
• Rediseño del proceso de contratación de tarjetas y paquetes bancarios siguiendo mejores prácticas de persuasión, usabilidad, accesibilidad y diseño responsive.
• Rediseño de sistemas internos de Gestión del Conocimiento
• Realizamos entrevistas con el Call Center para conocer mejores prácticas de venta, aplicadas a procesos de upselling.

La entrada Santander Río se publicó primero en Kambrica.

Realizamos un trabajo de rediseño y consultoría estratégica que tuvo como objetivos mejorar la interacción y el engagement de los usuarios y generar nuevos modelos de negocios.

Gracias a los insights logrados, se pudieron explotar nuevas fuentes de monetización: anuncios, descuentos, categorías y formas de pago sponsoreadas.

El proyecto es hoy caso de ejemplo en la incorporación de metodologías ágiles al proceso de diseño.

Problemática inicial

• El sitio había crecido de forma desorganizada a lo largo del tiempo: inconsistencia, problemas de mantenibilidad.
• Como producto de diseño autoreferencial, no se conocía el impacto real de muchas decisiones sobre la interfaz.
• Muchas ideas de mejora sin priorizar, de difícil aplicación dada la falta de consistencia y solidez del sitio.
• Nuevas amenazas en el mercado.

Antes y después

Plan general

Diseño y desarrollo en sprints

Se inició el proyecto con un sprint inicial (Sprint 0) de relevamiento del sitio, modelo mental de los usuarios, entendimiento del modelo de negocio, áreas de mejora y oportunidades.

Áreas de trabajo Sprint 0

• Análisis FODA y de analíticas.
• Revisión experta de usabilidad.
• Entrevistas cualitativas con usuarios.
• Proyección a futuro: brainstorming y exploración de hipótesis.

Las conclusiones del Sprint 0 alimentaron un plan de 3 sprints para trabajar –respectivamente– sobre lo urgente, lo importante y lo deseable.

Áreas de trabajo Sprints 1, 2 y 3

• Diseño de prototipos.
• Diseño visual.
• Pruebas de usabilidad.
• Ajustes luego de las pruebas.
• Desarrollo front-end.
• Cada sprint genera entregables.

El trabajo que hicieron es excelente. Estoy feliz!

Esteban Brenman, Fundador Guía Óleo

La entrada Guía Óleo se publicó primero en Kambrica.

Entre muchas otras cosas, este modelo me ha ayudado a entender cómo enfocar mi propia carrera. Cuando me encontraba en la facultad, parecía ser mejor diseñador quien dominara mayor cantidad de recursos estéticos impactantes… o al menos, ésa era la persona que recibía las mejores calificaciones. ¿Era ésa la única vara posible para medir el Diseño? ¿Era eso a lo que yo quería dedicarme? ¿O había otra búsqueda posible para mí?

En menor escala, este modelo me ha servido para identificar qué función debería primar en una pieza, y en dónde dedicar mayor esfuerzo. Por ejemplo, el problema… ¿es que la pieza es aburrida? ¿O tal vez el problema será otro?

Para poder entender cada función, veámoslas primero por separado:

• Cuando sólo está presente la función Información, tenemos datos en crudo.
• La función Presentación refiere a la expresión estética. En estado puro (sin transmisión de información ni permitir el uso), resulta en figuras, colores y movimiento que provocan una experiencia estética.
• La función Uso refiere a la posibilidad de interpretación y operación que la pieza permite a quien accede a ella. Un caso de la función uso en estado puro (sin transmisión de información ni expresión propia de la pieza), es un papel en blanco.

Como verán, ninguno de los ejemplos de cada función aislada, es un diseño. 

Eso es porque en este modelo, el Diseño resulta del encuentro de estas tres funciones, en mayor o menor proporción. Si sólo están presentes una o dos funciones, no es una pieza de diseño.

Veamos cómo agregando funciones, paso a paso, nos lleva a una pieza de Diseño, y a entender mejor el carácter que debe tener.

Agregando funciones, paso a paso: del dato al Diseño

Tomemos como punto de partida las siguientes series numéricas (el cuarteto de Anscombe):

( 10.0/8.04; 8.0/6.95; 13.0/7.58; 9.0/8.81; 11.0/8.33; 14.0/9.96; 6.0/7.24; 4.0/4.26; 12.0/10.84; 7.0/4.82; 5.0/5.68 ), ( 10.0/9.14; 8.0/8.14; 13.0/8.74; 9.0/8.77; 11.0/9.26; 14.0/8.10; 6.0/6.13; 4.0/3.10; 12.0/9.13; 7.0/7.26; 5.0/4.74 ), ( 10.0/7.46; 8.0/6.77; 13.0/12.74; 9.0/7.11; 11.0/7.81; 14.0/8.84; 6.0/6.08; 4.0/5.39; 12.0/8.15; 7.0/6.42; 5.0/5.73 ), ( 8.0/6.58; 8.0/5.76; 8.0/7.71; 8.0/8.84; 8.0/8.47; 8.0/7.04; 8.0/5.25; 19.0/12.50; 8.0/5.56; 8.0/7.91; 8.0/6.89 )

En este caso, acabamos de mostrar datos en crudo: sólo está presente la función información. Si presentamos estos datos en una tabla, permitimos cierta lectura de los datos, incrementando la función uso:

Y por último, la presentación visual de esta información, incrementa la función Presentación:

El empleo del formato correcto, nos permite ahora ofrecer conclusiones al usuario. No sólo es posible distinguir rápidamente que estas series son distintas: a primera vista, también se puede reconocer el carácter de cada una (dispersión, progresión lineal, etc).

Como contaba antes, es por el encuentro de las tres funciones que llegamos a una pieza de diseño. En este caso, por el balance de las funciones, se trata de una pieza de diseño de información.

El balance de funciones hace a una disciplina de Diseño

Cada disciplina de diseño se caracteriza por un balance y priorización particular de estas funciones. Por ejemplo, en el diseño publicitario prevalece la función de presentación, en el diseño editorial la información, y en el Diseño de Interacción y de Experiencia de Usuario (UX), el uso.

Es por esto que muchas veces, el diseño centrado en el usuario puede ser percibido como “aburrido” por quienes entienden al diseño como sinónimo de publicidad. Y es por esto que los esfuerzos de volver a UX más “visual”, más “disruptiva”, más… publicitaria, en definitiva, suelen partir de ignorar a la usabilidad como foco de UX, con los resultados esperables: la degradación final de la experiencia del usuario.

Este modelo nos permite entender que el espacio de diseño es limitado, y que no es posible “agregarle impacto” a una pieza de diseño: sólo es posible cambiar su carácter. La cuestión, entonces, es cuál es el carácter que el diseñador o el cliente buscan… y si ése es realmente el carácter que esa pieza debería tener para resolverle un problema real a sus usuarios reales.

Santiago Bustelo

La entrada Las tres funciones del diseño se publicó primero en Kambrica.

El acelerado acceso a la tecnología a través de PCs, notebooks, tablets y smartphones, entre otros dispositivos, ha dado origen a una nueva disciplina de gran importancia y no siempre explorada por los profesionales de la web: el diseño de interacción (IxD, por sus siglas en inglés).

En la charla se presenta un caso hipotético de creación de una aplicación en la que se repiten algunos de los problemas comunes a los que enfrentan diseñadores, programadores y emprendedores.

Se muestra cómo se resolvería el mismo encargo desde el diseño de interacción y tomando en cuenta la experiencia de usuario, exponiendo las diferencias de criterio y proceso, y la aplicación de un modelo cuantificado para comparar los resultados y lograr calidad.

La entrada Diseño Centrado en el Usuario: UX, IxD, usabilidad aplicada se publicó primero en Kambrica.

UX (Diseño de Experiencia de Usuario) y Diseño de Interacción, son nuevas disciplinas de diseño relacionadas con Diseño Industrial, Diseño Gráfico, Usabilidad e Ingeniería de Software.

En la charla se presentó diferencias y puntos en común del Diseño de Interacción con el Diseño Gráfico y Diseño Industrial. Además, de las nuevas habilidades que requieren los profesionales del diseño para desempeñarse dentro de estas disciplinas, y sobre técnicas y metodologías de trabajo específicas.

Se mostró cómo un programador, un diseñador visual y un diseñador de interacción resolverían el mismo caso de ejemplo, exponiendo las diferencias de criterio y proceso, y aplicando un modelo cuantificado para comparar los resultados.

Temario

UX y Diseño: definir cómo es, cómo funciona y cómo luce un producto digital

Disciplinas de diseño, entre lo abstracto y lo concreto: Diseño de Experiencias (UX), Diseño de Interacción (IxD): Define el modelo de operación de productos interactivos para lograr mejores experiencias para más usuarios.

Diseño de Interfaces: define los elementos concretos empleados en la interacción.

Diseño visual: Define lenguaje, carácter e identidad visual del producto.

Funciones del diseño: presentación, información, uso

Usabilidad: forma y función. La usabilidad de una interfaz es una medida de la efectividad, eficiencia y satisfacción con la cual determinados usuarios pueden alcanzar determinados objetivos en un entorno particular con dicha interfaz. (ISO 9241, Requerimientos ergonómicos para trabajo de oficina con terminales visuales, Parte 11 – 1997).

Un ejemplo de proceso de diseño aplicado a un caso

Producto: Software de administración de un videoclub. Nuestros personajes: Programador, diseñador, emprendedor.

• Enfoque del Programador
  Tres entidades: Películas: Datos; Clientes: Datos; Alquileres: Relaciones. Operaciones: Alta, baja, modificación y consulta para cada entidad.

• Enfoque del Diseñador
  Metáforas. Películas: DVDs; Clientes: Fichas; Alquileres: Ficha + DVD.
  Representación, Experiencia inmersiva, Fotorealismo.

• Enfoque del Emprendedor

Relevamiento competitivo, Definición del mercado, Especificación, Recursos y plan de trabajo

Problemas comunes a estos enfoques: diseño sin intención / autoreferencial. El usuario final no participa del proceso. Proceso lineal. Falta de metodología. Falta de política de calidad.

Diseño y Usabilidad: siempre ocurren. A un producto no le “falta” diseño o usabilidad; en todo caso, su diseño o usabilidad son malos. Son atributos cualitativos intrínsecos al producto: Como la performance, no se pueden “agregar”. Son definidos por el elemento más débil y afectados por todos los que construyen el producto. Proceso lineal vs. Proceso convergente.

Incorporando UX a nuestro ejemplo

Filosofía de Diseño Centrado en el Usuario: Creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible con el mínimo esfuerzo de su parte.

Proceso de Diseño Centrado en el Usuario: Conocer a fondo a los usuarios finales reales. Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades, expectativas y motivaciones. Poner a prueba lo diseñado.

Caso Centrado en el Usuario: Proceso de diseño y desarrollo convergente e iterativo. Evaluación competitiva, identificación de oportunidades. Definición preliminar del modelo. Validación y ajuste del modelo con usuarios. Priorización y estrategia de versiones. Prototipado de la interfaz. Pruebas con usuarios y ajuste de prototipos. Metodología ágil. Pruebas de usabilidad y QA antes de cada lanzamiento.

Calidad y cuantificación. Modelo KLM-GOMS. Comparación de los ejemplos previos. Desarrollo de la solución desde principios racionales de diseño y criterio de aceptación. Proceso de exploración y puesta a prueba.

Conclusiones: No hay Experiencia de Usuario sin usuarios.

Proceso iterativo de análisis y diseño centrado en la operación del usuario.

Bases racionales, cuantificación, calidad.

Obtener producto como resultado de un proceso, y satisfaciendo metas.

Charla presentada en:

• Microsoft Regional Architect Forum 2008
• Microsoft MIX 2008
• Día de la Usabilidad – Bogotá, Colombia, 2011
• UTN Tucumán, 2012
• Universidad de la Cuenca del Plata, 2013

Video (Día de la Usabilidad – Bogotá, Colombia 2011)

La entrada Charla “UX y Diseño de Interacción: Usabilidad aplicada” se publicó primero en Kambrica.

UX (Diseño de Experiencia de Usuario) y Diseño de Interacción, son nuevas disciplinas de diseño relacionadas con Diseño Industrial, Diseño Gráfico, Usabilidad e Ingeniería de Software.

En la charla se presentaron diferencias y puntos en común del Diseño de Interacción con el Diseño Gráfico y Diseño Industrial. Además, qué nuevas habilidades requieren los profesionales del diseño para desempeñarse dentro de estas disciplinas, técnicas y metodologías de trabajo específicas.

La presentación desarrolla cómo un programador, un diseñador visual y un diseñador de interacción resolverían el mismo caso de ejemplo, exponiendo las diferencias de criterio y proceso, y aplicando un modelo cuantificado para comparar los resultados.

Temario

UX y Diseño: definir cómo es, cómo funciona y cómo luce un producto digital

Disciplinas de diseño, entre lo abstracto y lo concreto: Diseño de Experiencias (UX), Diseño de Interacción (IxD): Define el modelo de operación de productos interactivos para lograr mejores experiencias para más usuarios.

Diseño de Interfaces: define los elementos concretos empleados en la interacción.

Diseño visual: Define lenguaje, carácter e identidad visual del producto.

Funciones del diseño: presentación, información, uso

Usabilidad: forma y función. La usabilidad de una interfaz es una medida de la efectividad, eficiencia y satisfacción con la cual determinados usuarios pueden alcanzar determinados objetivos en un entorno particular con dicha interfaz.
 (ISO 9241, Requerimientos ergonómicos para trabajo de oficina con terminales visuales, Parte 11 – 1997)

Un ejemplo de proceso de diseño aplicado a un caso

Producto: Software de administración de un videoclub. Nuestros personajes: Programador, diseñador, emprendedor.

• Enfoque del Programador:
  Tres entidades: Películas: Datos; Clientes: Datos; Alquileres: Relaciones. Operaciones: Alta, baja, modificación y consulta para cada entidad.
  
• Enfoque del Diseñador:
  Metáforas. Películas: DVDs; Clientes: Fichas; Alquileres: Ficha + DVD.
  Representación, Experiencia inmersiva, Fotorealismo.
  
• Enfoque del Emprendedor:
  Relevamiento competitivo, Definición del mercado, Especificación, Recursos y plan de trabajo.

Problemas comunes a estos enfoques: diseño sin intención / autoreferencial. El usuario final no participa del proceso. Proceso lineal. Falta de metodología. Falta de política de calidad.

Diseño y Usabilidad: siempre ocurren. A un producto no le “falta” diseño o usabilidad; en todo caso, su diseño o usabilidad son malos. Son atributos cualitativos intrínsecos al producto: Como la performance, no se pueden “agregar”. Son definidos por el elemento más débil y afectados por todos los que construyen el producto. Proceso lineal vs. Proceso convergente.

Incorporando UX a nuestro ejemplo

Filosofía de Diseño Centrado en el Usuario: Creación de productos que resuelvan necesidades concretas de sus usuarios finales, consiguiendo la mayor satisfacción y mejor experiencia de uso posible con el mínimo esfuerzo de su parte.

Proceso de Diseño Centrado en el Usuario: Conocer a fondo a los usuarios finales reales. Diseñar un producto que resuelva sus necesidades y se ajuste a sus capacidades, expectativas y motivaciones. Poner a prueba lo diseñado.

Caso Centrado en el Usuario: Proceso de diseño y desarrollo convergente e iterativo. Evaluación competitiva, identificación de oportunidades. Definición preliminar del modelo. Validación y ajuste del modelo con usuarios. Priorización y estrategia de versiones. Prototipado de la interfaz. Pruebas con usuarios y ajuste de prototipos. Metodología ágil. Pruebas de usabilidad y QA antes de cada lanzamiento.

Calidad y cuantificación. Modelo KLM-GOMS. Comparación de los ejemplos previos. Desarrollo de la solución desde principios racionales de diseño y criterio de aceptación. Proceso de exploración y puesta a prueba.

Conclusiones: No hay Experiencia de Usuario sin usuarios

No hay Experiencia de Usuario sin usuarios

Proceso iterativo de análisis y diseño centrado en la operación del usuario

Bases racionales, cuantificación, calidad

Obtener producto como resultado de un proceso, y satisfaciendo metas.

Charla presentada en:

• Microsoft Regional Architect Forum 2008
• Microsoft MIX 2008
• Día de la Usabilidad – Bogotá, Colombia, 2011
• UTN Tucumán, 2012
• Universidad de la Cuenca del Plata, 2013

Video (Día de la Usabilidad – Bogotá, Colombia 2011):

La entrada UX y Diseño de Interacción: Usabilidad aplicada se publicó primero en Kambrica.

Transcipción de la entrevista publicada por TN

SB: Cuando ponemos afip.gov.ar nos encontramos con… una página de error [“El URL solicitado no se puede conseguir”]. Y esa página de error sucede porque el sitio no está preparado para recibir la dirección sin “www” adelante. Antes de recibirte, el sitio ya te está declarando que está hecho de alguna manera y es tu problema resolverlo, no por una intencionalidad sino porque no se ha observado que eso podía suceder y se podía prever.

SB: A través de la web vemos “clave fiscal: ingrese aquí”. OK. Bien. Y si no sé lo que es “clave fiscal”? Solicite clave. OK… “clave fiscal”, además, es un nombre como… Oh… Parece que no anda.

SD: Sí, y acá se ve que fue a blanco.

SB: Todo blanco.

SD: Bueno esto es lo que le pasa todos los días a todo el mundo.

SB: Yo creo que cuando suceden estas situaciones es porque justamente no se conocen alternativas, porque no se conocen posibilidades. Recién conociendo posibilidades uno puede reconocer un problema.

SD: Hay una ley que dice que la accesibilidad web es la posibilidad efectiva de que el mayor número de personas accedan de manera satisfactoria una web y hagan uso de sus contenidos. Algo que evidentemente no pasa con la AFIP. Entonces, ¿por qué no se hace? ¿Por desidia, por dejar un sitio diseñado como si fuera en el 1990?

SB: Yo creo que es por falta de conocimiento. Yo creo que es por falta de ver alternativas. Tienen problemas tales que hacen que la gente termine acudiendo a terceros: contadores, hijos que lo ayuden a usar el sitio, nietos, lo que sea. O, terminan haciendo cola, volviendo al canal tradicional y a veces se encuentran, para peor, que el canal tradicional le dicen: “Tiene que entrar al sitio”. Entonces, entramos en un círculo donde el servicio no está ofrecido como servicio y no hay solución. Creo que todo organismo público tiene una responsabilidad hacia los ciudadanos. El estado somos todos, y si el organismo a cada persona que entra a hacer un trámite la obliga a pasar por una serie de situaciones que no son necesarias, que son confusas, que puede dar lugar a problemas y lo esté haciendo con todos los ciudadanos está efectivamente haciendo que el país invierta su tiempo en algo que no es productivo.

Clarín: expertos afirman que la web de AFIP es “poco amigable”

El diario Clarín hizo eco de la entrevista realizada por TN, su canal de noticias. En el artículo disponible en clarin.com sobre los problemas de usabilidad del sitio de la Administración Federal de Ingresos Públicos, recoge algunas partes de la entrevista que no llegaron al aire.

“Santiago Bustelo, consultor en experiencia de usuarios, afirma a Clarín que “la cultura del organismo recaudador se refleja en su sitio, porque está enfocado en brindar un sistema para operar y en menor medida en dar ayuda”.

“Y plantea algunos ejemplos: “El sitio tiene una forma de llamar a las cosas que al normal de la gente no le resulta razonable. Por ejemplo, ‘siradig’ es el nombre del trámite para desgravar ganancias; en vez de factura electrónica se llama ‘comprobante en línea’; el sitio entrega comprobantes de cuil o cuit con guiones pero después pide que se ingresen sin guiones”.

“Planteado como está ahora –dice Bustelo– resulta necesario recurrir a un experto. Porque la gente no logra cumplir con lo que se exige, en un tiempo razonable y sin errores. Y en vez de sentirse orgulloso de haber cumplido un deber ciudadano, cuando logra concluirlo, el usuario siente que por fin se terminó un calvario”.

La entrada ¿Por qué se cae la web de la AFIP? se publicó primero en Kambrica.

Wayra es la aceleradora de proyectos tecnológicos del grupo Telefónica, con presencia en 12 países de América Latina y Europa. Todos los años, selecciona un grupo reducido de startups a las que brinda financiamiento, espacio de trabajo y acceso a una red global de mentores, expertos e inversores.  

Dentro de su programa de aceleración, brindamos consultoría, mentoría y capacitación a las startups sobre metodología Lean UX, diseño UX, diseño centrado en el usuario, pruebas de usabilidad, entrevistas cualitativas, tests A/B, priorización de tareas, identificación de oportunidades de negocio y evaluación de la escalabilidad de las soluciones, entre otras.

Áreas de trabajo

• Brindamos consultoría a más de 35 startups que participaron de nuestro programa de formación en técnicas de UX y metodologías ágiles para el desarrollo de productos digitales.
• Trabajamos con startups de diferentes sectores, incluyendo fin-tech, med-tech, agro-tech, entretenimiento, marketplaces, apps, e-commerce, IoT y smart-cities entre otras.
• Mediante el programa “Lean UX” ayudamos a startups de diferentes industrias a identificar/refinar su propuesta de valor, entender a sus usuarios para ajustar el producto acorde a sus necesidades, mejorar la usabilidad de sus productos para captar más clientes, crecer de forma más consistente y reducir costos.
• Desarrollamos un proceso de trabajo iterativo mediante el cual cada startup pudo ir refinando su producto en cada iteración, agregando más valor para el negocio, sus usuarios finales y sus inversores

Su programa Lean UX ayudó a los emprendedores a testear en ambientes reales sus productos, generando servicios de calidad con menor tiempo de salida al mercado.

Lorena Suárez, Business Development Manager Wayra

La entrada Wayra se publicó primero en Kambrica.

De ese estudio, una de las conclusiones que surgieron es que no alcanza con poseer habilidades técnicas en el manejo de herramientas de diseño, y tampoco de conocer a la perfección todos los patrones y heurísticas de diseño de interfaces. Los dos insights más importantes revelan que las habilidades más requeridas no tienen que ver con capacidades técnicas o metodológicas, sino con la capacidad de incorporar conceptos de negocio y poder comunicar las decisiones de diseño a otros equipos.

Conocimiento del negocio

Uno de los consultados dijo que en su experiencia, una de las habilidades que le resulta muy difícil de encontrar es la capacidad de los diseñadores de incorporar los requerimientos del negocio a los criterios técnicos y estéticos. Es decir, la mayoría de los diseñadores se preocupa por la interfaz y pierde de vista los objetivos de negocio o los considera como restricciones en lugar de verlos como el propósito principal de su trabajo. 

En este sentido, surge la necesidad de propiciar una comunicación frecuente en la que tanto las áreas de Negocio como las de Diseño puedan conversar planteando sus necesidades y limitaciones.

Comunicación

Por otro lado, los diseñadores tampoco suelen tener habilidad para comunicarse con otras áreas y de entender cómo el diseño forma parte del contexto general en el que se inserta su trabajo.

Junto con la capacidad de incorporar los objetivos de negocio a su trabajo, también es importante que los diseñadores puedan hablar el lenguaje del negocio y del producto para poder influenciar los resultados del proyecto y lograr que la visión de UX sea incorporada y además valorada.

En este sentido, la capacidad de los diseñadores de explicar sus decisiones en función de los objetivos de negocio y no sólo en términos estéticos tiene no solamente un gran impacto en el éxito o fracaso de un proyecto, sino que también elimina el criterio subjetivo, y por lo tanto cierra la puerta a interminables discusiones basadas en “me gusta” o “me parece”. Un ejemplo, es la capacidad de defender la decisión de despojar a la página de elementos decorativos innecesarios, que confunden al usuario y le impiden concretar una tarea crítica como por ejemplo, finalizar una compra o registración. 

Así, presentar y defender el diseño es una habilidad no “deseable” sino imprescindible. Una de las cualidades que se otorgaba a Steve Jobs era su capacidad para comunicar los beneficios de sus decisiones de diseño a los principales stakeholders y a los consumidores, lo cual fue uno de los factores que impulsó el crecimiento exponencial de Apple y del nivel de lealtad hacia la marca.

Fuentes utilizadas:

Why your ux designer won’t be the next Steve Jobs
Designers must attend to business

La entrada Dos habilidades clave para los diseñadores de interacción se publicó primero en Kambrica.

El hipermercado Jumbo, perteneciente a la cadena Cencosud, necesitaba agilizar el proceso de compra online para aumentar las conversiones del sitio.

Diseñamos un nuevo proceso compra online que permitía presentar una mayor cantidad de productos de manera más atractiva y reconocible, facilitando la compra de múltiples artículos. Esto generó impacto positivo en la cantidad de artículos por compra y el ticket promedio.

Antes y después

Áreas de trabajo:

• Siguiendo una metodología de diseño centrado en el usuario, realizamos entrevistas contextuales para observar a los usuarios realizar la compra en su entorno habitual. Esto nos permitió identificar diferentes factores que generaban fricción durante el proceso de compra.
• En función de lo observado, realizamos un prototipo funcional, sobre el cual realizamos pruebas de usabilidad, para validar que el nuevo diseño satisfacía las necesidades de los usuarios

La entrada Jumbo a Casa se publicó primero en Kambrica.

Áreas de trabajo

• Análisis del Negocio
• Diseño de reporte
• Desarrollo de lenguaje visual
• Diseño de Información
• Diseño de Interacción
• Diseño de interfaz
• Evaluación de Usabilidad

En una primera instancia ayudamos a Keepcon en el rediseño de la plataforma de moderación. Trabajamos en el relevamiento de modelos mentales, análisis y mejora de procesos y operaciones.

En una segunda instancia, Keepcon desarrolló una plataforma de reportes estadísticos para sitios. El valor diferencial a comunicar, pocos datos requeridos para obtener información de los sitios y rapidez en el procesamiento de los datos.

El mayor desafío en este caso fue ayudarlos a definir y comunicar una oferta de valor sólida. Lograr la atención, reflejar confianza, credibilidad y efectividad de la herramienta. Generamos una solución para la landing de venta incorporando técnicas de Cold Reading. 

La entrada Keepcon se publicó primero en Kambrica.

Ante los excelentes resultados obtenidos para la nueva versión 3.0, el Consorcio SIU emprendió una versión intermedia 2.5 con menores requerimientos técnicos para facilitar la adopción.

Áreas de trabajo

• Realizamos entrevistas cualitativas con estudiantes usuarios del sistema para relevar problemas con la herramienta existente, necesidades y expectativas.
• En función de lo relevado rediseñamos el sitio, incluyendo: 
  • Arquitectura de Información
  • Diseño de Interacción
  • Diseño de interfaz
  • Pruebas con Usuarios.

La entrada SIU Guaraní se publicó primero en Kambrica.

¿Qué es el Diseño de Interacción? ¿De dónde venimos? ¿A dónde vamos?

En un principio, fue el bit:

Después, toda esa energía se compactó y surgió la interfaz.

Una aplicación, un sitio, se compone necesariamente de estos dos elementos. Aunque la interfaz no la haya hecho un diseñador, o el desarrollo no lo haya hecho un programador.

Esto al usuario no le importa. Al menos, no directamente.

La relación del usuario con la interfaz y el desarrollo, ocurre en un plano superior: la experiencia.

La experiencia, esta atmósfera que rodea la aplicación, tiene que tener la composición y densidad adecuadas. Sino, al usuario que aterriza sobre nuestra aplicación, le puede explotar la cabeza. El Diseño de Interacción busca lograr mejores experiencias para la mayor cantidad de usuarios, definiendo el modelo de operación de nuestros sitios y aplicaciones.

¿De dónde venimos?

El diseño de interacción tiene una larga pre-historia.

En 1968, Douglas Engelbart hace una demostración de tecnologías experimentales…

…el mouse, edición de texto, hipertexto, email y hasta videoconferencia.

Todas ellas, surgidas de su visión del futuro:la computadora potenciando la capacidad intelectual humana para lograr un mundo mejor.

Sobre esa visión, pioneros fueron construyendo paso a paso un modelo de interacción simple y coherente.

Un modeloen el que todas las aplicaciones usaban el mismo lenguaje de ventanas y menúes desplegables. Y se operaban bajo los mismos principios, compartiendo una serie de operaciones básicas, como copiar, pegar, deshacer.

Las aplicaciones de escritorio fueron montándose sobre este modelo unificado, y de a poco extendiéndolo.

Pero este modelo fue opacado y quedó una nebulosa…

…por la aparición de una nueva constelación en la que el usuario necesita bastante más esfuerzo en unir los puntos: las aplicaciones web.

En 1994, aparece la primer versión de Netscape. Las aplicaciones web surgieron sin poder tomar el modelo de las aplicaciones de escritorio, ni tampoco se había planteado un modelo alternativo. Se fue avanzando en esta conquista del espacio por prueba y error.

En el 2004, aparece Gmail, se establece AJAX y aparecen nuevas fronteras. Y en otro orden de cosas, se populariza el término “web 2.0”, signifique lo que signifique.

En todo este tiempo, en esta conquista del espacio, surgió la necesidad de diseñar el modelo de operación de las aplicaciones. Algo que antes sólo hacían unos pocos como Apple, Microsoft, Adobe… cada vez más gente lo estaba haciendo.

2003: se establece consenso sobre el nombre de la disciplina, “Diseño de Interacción”, y se forma la IxDA.Una asociación sin fines de lucro ni costo de membresía, dedicada a impulsar el profesionalismo, evangelismo, educación e innovación en el campo del Diseño de Interacción.

En febrero de 2009 organizamos la primer reunión del capítulo local, IxDA BA. Desde entonces estamos creciendo y tomando los desafíos que encontramos en la región.

¿Dónde estamos hoy? ¿Qué aprendimos en estos 40 años?

De la prueba y error, pasamos a la sistematización, en donde vemos qué funcionó y, lo más importante, por qué funcionó.

Y con eso, sabemos cómo condensar la nebulosa para generar nuevas aplicaciones con las experiencias que buscamos.

Hoy sabemos que conseguir el compromiso del usuario, el engagement, no depende de un atributo particular del diseño, el desarrollo o el modelo de negocios. Sino, de balancear en la interacción los desafíos con las habilidades del usuario, de manera de evitar la frustración (alto desafío, baja habilidad) y el aburrimiento (bajo desafío, alta habilidad). Y permitir al usuario transitar por esa franja del medio…

…que en inglés se llama “flow” y que podríamos traducir como “¡qué copado!”.

Ése es el mayor cumplido que podemos recibir emprendedores, programadores, diseñadores. No que la aplicación esté bien diseñada, bien programada, ni que tenga un buen modelo de negocios. Que está copada.

¿A dónde vamos?

El futuro del diseño, el desarrollo, los negocios en la web, ya está empezando a suceder.

Los desarrolladores (que empiezan del bit) y los diseñadores (que parten de la interfaz) estamos encontrando los conceptos y metodologías para dejar de chocar en el medio…

…y poder trabajar de manera coordinada, mejorando la experiencia en cada iteración.

En una escala mayor, nuestras aplicaciones van a ir formando un sistema con las demás. Miles de experiencias coordinadas por los mismos principios, mejorando la vida de las personas.

Ese es el futuro que tenemos por construir: diseño, desarrollo y negocios centrados en el usuario.

Los invito a sumarse a IxDA, ixda.com.ar.
¡Muchas gracias!

Santiago Bustelo

La entrada Hasta la web 2.0 y más allá se publicó primero en Kambrica.

La Oficina de Asuntos Judiciales de esta Universidad nos eligió por nuestra capacidad de proveer diseño y desarrollo que cumpliera con los estándares de la Sección 508: que fuera accesible a todas las personas, independientemente de sus capacidades técnicas, cognitivas o físicas. Esto le valió el reconocimiento del panel de expertos en el prestigioso Festival South by Southwest (SXSW) en el año 2004.

La arquitectura de información y recomendaciones para el enfoque de contenidos fueron realizadas considerando los casos de uso en que docentes y estudiantes deben consultar el site: temas delicados relacionados con infracciones al código de honor de la universidad, tales como plagio, abuso de sustancias o acoso sexual.

El desarrollo HTML/CSS no sólo permitió resolver con el mismo código situaciones de accesibilidad, sino que también fueron contemplados estilos especiales para diferentes resoluciones y para impresión, de selección automática al imprimir la página o generar PDFs.

Gracias a este enfoque responsive, la página se convirtió en el repositorio único de información oficial para todos los formatos, eliminando los problemas de mantenimiento de la información en múltiples formatos y requiriendo el personal responsable documentación y capacitación sobre una única plataforma.

Áreas de trabajo

• Consultoría
• Accesibilidad
• Arquitectura de Información
• Diseño de interfaces
• Desarrollo front-end
• Validación con usuarios con discapacidad

Declaración oficial de la Universidad de Stanford

Accessibility Design Recognition, SXSW Interactive 2004, Austin, Texas

At the SXSW Interactive 2004 Accessibility Shoot-Out, Judicial Affairs was selected for its commitment to ensure that people of all abilities using any Internet device can access this site.

Accessibility experts attending the panel included:

• John Slatin, Director – Accessibility Institute at the University of Texas
• Jim Allan, Webmaster – Texas School for the Blind and Visually Impaired
• Sharron Rush, Executive Director – Knowbility.org
• Giorgio Brajnik, Asst. Professor – University of Udine, Italy, Usablenet
• Rashmi Bhat, Business Manager – SBC

Each Stanford University website is required to meet the definition of a generally accessible Internet site, and ensure that web pages transform gracefully and remain accessible despite any physical, sensory, or environmental constraints or technological barriers.

To meet these accessibility objectives, the Judicial Affairs site was designed, monitored and tested for compliance with Web Content Accessibility Guidelines (WCAG 1.0), as published by the Web Accessibility Initiative of the W3C. The Judicial Affairs site also complied with the accessibility requirements of Section 508 of the federal Rehabilitation Act Amendments of 1998 (29 U.S.C. § 794d). See 36 C.F.R. Part 1194.

As with most assistive technology, changes made to accommodate those with a disability end up benefiting everyone. A web page that is designed with accessibility in mind will be better structured and more user-friendly.

La entrada Universidad de Stanford se publicó primero en Kambrica.