Kambrica nos aportó gran valor al ayudarnos a ponernos en el lugar de los clientes e incorporar la lógica de UX en la transformación de nuestra forma de dar servicio.

Gerente Propuesta de Valor

Compañía multinacional de seguros y servicios financieros

* Este proyecto se presenta de forma anonimizada, en el marco de acuerdos de confidencialidad corporativa.

Cuando el proyecto entra a una reunión y sale convertido en una máquina de quemar presupuesto

Cuando una organización corporativa inicia un proyecto digital, el problema entra a una reunión y sale convertido en una estructura enorme de recursos, plataformas y meses de desarrollo. No porque sea realmente necesario, sino porque los incentivos de la industria están puestos ahí.

Las software factories facturan crecimiento del proyecto: más equipos, más horas, más complejidad. Nunca menos. En este caso, la organización empezaba las reuniones con una conclusión tomada: “necesitamos una App”. Los usuarios llamaban para consultar información de sus productos financieros y no utilizaban el sitio web existente, que “había quedado viejo”.

Ante este pedido, los comerciales de las agencias se frotaban las manos: “¡Claro que necesitás una App!”. Y tiene que ser para iPhone, Android y tablets. Con un backend moderno, QA, DevOps, múltiples equipos y varios meses de ejecución. En minutos, una idea se había transformado en un equipo de 12–14 personas.

Nosotros hicimos algo distinto: redujimos el problema antes de escalar la estructura. Porque ejecutar rápido la primer interpretación que se tiene del problema, no es agilidad: es desperdicio a gran velocidad. Y evitarlo, nos llevó tan solo una hora.

Una sola reunión alcanza para desenredar el proyecto

Aplicando nuestra metodología XDM (Experience Decision Making), trabajamos separando tres capas que en la mayoría de los proyectos aparecen mezcladas desde el inicio: hechos, interpretaciones, y propuestas de solución.

Ese análisis reveló un dato que nadie había considerado: la frecuencia de consulta de los usuarios estaba entre seis meses y dos años. Eso invalidaba la hipótesis de desarrollar una App: los datos mostraban que a los usuarios se les “llenaba” el teléfono cada tres meses… proponiéndoles eliminar las Apps que no usaban.

El proyecto tenía que contemplar entonces una primer etapa de investigación UX estratégica para entender por qué los usuarios rechazaban el sitio existente y preferían llamar. Sin esa información, cualquier iniciativa era una apuesta a ciegas.

El cliente pensaba que el sitio era “viejo” y “feo”. Quizás tenía razón. Pero las verdaderas respuestas estaban delante de las pantallas.

Mientras que la interfaz (UI) vive dentro de las pantallas, lo que los usuarios experimentan (UX) es lo que sucede delante de ellas.

Ese fue el foco de la investigación estratégica que en tan sólo dos semanas, reveló el problema de fondo: el sitio mostraba menos de la mitad de la información que los usuarios necesitaban para sus procesos de toma de decisiones. Por eso los usuarios llamaban.

La interfaz no estaba fallando por cuestiones tecnológicas o estéticas.
Sino porque no respondía las preguntas que tenían los clientes.

Algo que ninguna agencia se había propuesto atender, perpetuando la trampa de todo RFP.
Después de 4 a 6 meses, el cliente habría recibido exactamente lo que pidió. Pero que no era lo que realmente necesitaba.

Reducir complejidad e incertidumbre antes empezar la ejecución

Nuestra metodología parte de un hecho: los grandes proyectos no fracasan por razones técnicas. Fracasan porque las complejidades se revelan y atienden recién cuando toda la estructura ya está en movimiento.

Por eso trabajamos despejando complejidades de UX, institucionales y tecnológicas desde el inicio del proyecto.

Porque verdadera agilidad no es ejecutar apurados el primer plan que parece tener sentido: es tener la cintura para cambiar dirección cuando aparece nueva evidencia.

1. Complejidades UX: la distancia entre el Negocio y las personas

Para identificar y reducir esta distancia, trabajamos relevando procesos reales de toma de decisiones, entendiendo qué información necesitan los usuarios, cómo la interpretan, y a qué procesos o herramientas de soporte terminan acudiendo.

Eso permite redefinir la arquitectura de información, los criterios de visualización y las prioridades del producto antes de cristalizar decisiones de diseño UI y desarrollo.

2. Complejidades institucionales y políticas

En proyectos corporativos, gran parte del desgaste aparece cuando la solución ya está avanzada y comienzan los rechazos internos: branding, marketing, compliance, stakeholders.

Por eso desde el primer día, realizamos un mapa político de todas las áreas afectadas. Las incorporamos tempranamente en el proyecto en tracks paralelos, despejando todos los riesgos (tales como inconsistencias entre manuales y criterios internos) antes de que impacten en el proyecto.

Nuestro resultado son proyectos sin retrabajos políticos ni ciclos interminables de aprobación.

3. Complejidades IT: factibilidad técnica

En la industria de Banca, Finanzas y Seguros, existe una capa tecnológica crítica de sistemas legados, cuyos responsables deben estar involucrados desde el primer momento. En este caso, la cantidad de información financiera involucrada generaba esperas incompatibles con la experiencia que el producto necesitaba entregar.

Nuestra solución fue construir un motor de front-end inteligente y agnóstico, capaz de reutilizar información ya obtenida, reducir roundtrips innecesarios y realizar carga progresiva de datos sin bloquear la navegación y uso del sistema.

Eso permitió resolver performance sin degradar experiencia, ni sumar más arquitecturas a un stack de por sí sumamente complejo.

Resultados

Mientras las agencias proponían estructuras enormes y costosas para “cumplir con el pedido”, Kambrica superó los objetivos con un equipo reducido, foco estratégico y dirección clara.

Porque nuestros incentivos no están puestos en colocar gente ni vender horas, sino en resolver el problema correcto.

En este caso, el proyecto no necesitaba una App, ni una plataforma tecnológica de punta. Necesitaba entender qué estaba fallando entre la organización y sus clientes.

Sin diagnóstico y dirección, la velocidad solo escala el error.

La mayoría de las organizaciones no necesita más velocidad.
Necesita mejores diagnósticos antes de escalar estructuras, presupuesto y complejidad. Eso es lo que hacemos.

Si sos responsable del éxito de productos o proyectos y sospechás que el problema que tienen entre manos está siendo interpretado de forma incorrecta, hablemos.

Podemos ayudarte a verlo antes de que el costo, la complejidad y el riesgo político sigan creciendo.

La entrada Banca, Finanzas & Seguros 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.

Ejercicio: mini editor de bitmaps HTML/CSS/jQuery

El propósito de este ejercicio es ayudarnos a ver cómo pensás problemas de desarrollo.

Requerimiento:

• Presentar una grilla de 8 x 8, donde cada casillero cuadrado (de 30 x 30 px. aprox.) representa un “pixel” ampliado.
• Cada “pixel” puede estar prendido (gris) o apagado (blanco). Siendo cada “pixel” un bit, cada fila de 8 “pixels” forma un byte.
• Debajo de la grilla, un INPUT TEXT presenta los valores en hexadecimal para esos 8 bytes.  Al hacer click en un casillero, se invierte el estado de ese “pixel” y se actualiza el INPUT TEXT.
• Presentar un menú (SELECT) permitiendo cargar sobre la grilla imágenes predefinidas en un archivo JSON:
  [ {name:"Imagen 1", src:"0102030405060708"} , {name:"Imagen 2", src:"ff00ff00ff00ff00"}, {name:"Carita", src:"3C42A9A985B9423C" } ]

Entrega:

• Archivo .zip o .rar conteniendo archivo index.htm, así como todos los archivos referenciados (incluyendo librería jquery) a work@nullkambrica.com . Título del mail: “Ejercicio Front-end”.
• El ejercicio debe poder ejecutarse correctamente abriendo index.htm en Chrome (desktop).
• En el mail, adjuntá o linkeá también tu CV, con links a ejemplos de maquetación HTML/CSS que hayas desarrollado.

La entrada ¿Querés trabajar con nosotros en desarrollo front-end? 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.

Mercado Libre había desarrollado y documentado una plataforma tan valiosa como compleja.

La documentación técnica producida era necesaria, pero no suficiente, para lograr adopción de parte de quienes desarrollaban, diseñaban e implementaban soluciones de e-commerce, parte vital de su ecosistema.

Era necesaria otra mirada.

Aplicamos técnicas de investigación cualitativa y cuantitativa para comprender los perfiles actitudinales involucrados, sus intereses y procesos de toma de decisiones, y estrategias apropiadas de comunicación.

Rediseñamos y validamos con usuarios reales la oferta de valor, landing pages, comunicación y navegación. Tomamos el diseño final y desarrollo front-end, siguiendo las definiciones de marca para asegurar que el producto final formara parte consistente de la plataforma.

Antes y Después

Áreas de trabajo

• Consultoría de UX, marketing y comunicación
• Entrevistas cualitativas
• Perfiles actitudinales (Personas)
• Diseño de propuesta de valor
• Arquitectura de información
• Redacción publicitaria
• Diseño de prototipos (Wireframes)
• Pruebas con usuarios
• Diseño visual
• Diseño Responsive
• Desarrollo front-end
• Metodología Lean UX

Resultados

• Mejoras de conversión.
• Reducción de los procesos explicativos sobre las herramientas disponibles.
• Mercado Libre obtuvo más leads que los proyectados.

La entrada Mercado Shops 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.

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.

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.

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.