Windows 8 UX – “first impressions”

Read the original article in spanish at UXSALAD Blog

One of the best things that Microsoft style guide emphasises to design Windows 8 applications is the importance to make a good “first impression” of our solution.

They suggest several ways to accomplish considering the concept and application architecture within its new visual metaphor (also known as Modern UI).

image

Tiles and Notifications

The tiles are the face of your application and highlights your brand identity. The relevant notifications will always return the user to your application.

If we consider that “a tile” must be distinguishable from a good list of tiles is important to keep it as simple and clear as possible. We do not know if the rumor of abandoning the current home screen of Windows 8  the tiles will lose strength. In any case, I hope never to retreat from the Live Tiles  surely his most original proposal.

Splash Screen

It expresses personality and should load as fast as possible.

There is some confusion between the resolution that recommended guidelines and the final result of the logo. The image used in the splash must have a resolution of 620×300 pixels, which is not to say that the logo must conform 100% to that resolution. In any case there is freedom to take advantage of every pixel as you like.

First launch

Give the user the contents of examples so that you know how to use the application.

Given that any toolbar could be hidden by default and send the contents, examples of contents are a good place to hitch.

But I’m not convinced that this can be applied to applications in which the user must generate content or, for example, in games. In this case, follow the pattern of instant gratification and for that we would have to get the user to do or interact with the application easily and quickly and be compensated for it, and not relegate it simply to see or be a spectator.

Home page

Use the content just to show what it’s made for your application.

If your application is fully oriented content this should be the place where offer that shows you belong to the first level of hierarchy of information architecture. Of course, do not forget that there is the Semantic Zoom and if the contents do not speak enough of your structure the user can always do “pinch” (zoom out) and see everything a little clearer (after labeling).

 

The combination of all these elements reinforce, as we said, the effort to generate a good impression and make it clear why your application is the best for the purpose it is designed. Although they are strongly linked to the mode of operation of an app for Windows 8 are extrapolated to any other standard, there is more to see how patterns have evolved on other platforms where the contents retrieved his reign.

Windows 8 UX – “Primeras impresiones”

Una de las mejores cosas que se enfatizan en las guías de estilo de Microsoft para diseñar aplicaciones Windows 8 es la importancia que se debe considerar con la “primera impresión” de nuestra solución.

Sugieren varias formas de conseguirlo teniendo en cuenta el concepto y arquitectura de las aplicaciones dentro de su nueva metáfora visual (conocida también como Modern UI).

image

Tiles y Notificaciones

Los tiles son la cara de tu aplicación y hace resaltar tu identidad de marca. Las notificaciones relevantes siempre devolverán al usuario a tu aplicación.

Si tenemos en cuenta que “tu tile” debe ser distinguible entre una buena lista de tiles es importante mantenerlo lo más simple y nítido posible. No sabemos si con el rumor de “abandonar” la actual pantalla de inicio de Windows 8, los tiles van a perder fuerza. En cualquier caso, espero que nunca se retracten de los Live Tiles, seguramente su propuesta más original.

Pantalla de bienvenida (Splash Screen)

Expresa la personalidad y debe cargar tan rápido como sea posible.

Existe cierta confusión entre la resolución que las guías recomienden y el resultado final del logo. La imagen usada en la splash debe tener una resolución 620×300 píxels, lo que no quiere decir que el logo deba ajustarse 100% a esa resolución. En cualquier caso existe total libertad para aprovechar cada pixel como se quiera.

Primer uso (first launch)

Darle al usuario contenidos de ejemplos para que sepa cómo usar la aplicación.

Teniendo en cuenta que cualquier barra de herramientas podría estar oculta por defecto y que los contenidos mandan, los ejemplos de contenidos son un buen punto de enganche.

Sin embargo no estoy muy convencida de que esto pueda aplicarse a aplicaciones en las que el usuario debe generar contenidos o, por ejemplo, en juegos. En este caso, seguiría el patrón de gratificación instantánea y para ello tendríamos que conseguir que el usuario hiciera o interactuara con la aplicación fácil y rápidamente y ser compensado por ello, y no relegarlo simplemente a que viera o fuese espectador.

Página de inicio (Home page)

Usa el contenido justo para mostrar para qué está hecha tu aplicación.

Si tu aplicación está totalmente orientada a contenidos éste debe ser el punto donde ofrecer esa muestra que pertenecería al primer nivel de jerarquía de la arquitectura de la información. Por supuesto, no os olvidéis de que existe el Semantic Zoom y si los contenidos no hablan suficiente de vuestra estructura el usuario siempre podrá hacer “pinch” (zoom out) y verlo todo un poco más claro (a partir de su etiquetado).

La combinación de todos estos elementos refuerzan, como decíamos, el empeño en generar una buena impresión y dejar claro por qué tu aplicación es la mejor para el propósito que se diseña. Aunque están fuertemente ligados al modo de funcionamiento de una app para Windows 8 son extrapolables a cualquier otro estándar, no hay más que ver cómo han evolucionado los patrones en otras plataformas en los que los contenidos recuperan su reinado.

Using Google Keep for need finding

Many (mean) words have been said since the launch of Google Keep, but rather to analyse the next Google failure I’d like to consider this as an opportunity and share with you how do I professionally use Google Keep.

As you already know, need finding is an approach used by designers of different fields to research and understand better people’s needs. There are two basic kinds of need findings: observations and interviews.

Observing people, your potential users, and their behavior require spending time patiently watching, and waiting for something interesting to happen.  However there are multiple occasions that nothing happens or we are simply not in the right place on the right moment.

For those situations is when Google Keep can be helpful. Either if you suddenly start watching an unusual scene, or there’s something that catch your attention, Google Keep could be used to

  • Capture the scene by adding a picture
  • Repeating people’s comments by transcribing  them
  • Grouping and relating notes by using different colours

You don’t need to plan it neither to know what you’re looking for. For me it’s not something I’d like to mix with any other note-taking tool just because I don’t expect to classify it or organize it. I don’t even think they have any value in the future but it’s my reminder that something surprised me, and a problem – again, an opportunity – may emerge for those notes.

It has passed just few days since I’m using it in this way, every time I see something related with the topic I’m researching I just capture the moment expecting to find the needs.

Google Keep keeps it simple, and its lacks of functionality is not a lack of utility, actually it is a motivation to try to behave as a real user experience observer/designer.

Of course, if you’re using it for a different professional purpose, I’d love to know it 🙂

Propuestas para UXSpain

La segunda edición del UXSpain, encuentro de profesionales de la Experiencia de Usuario, está en marcha y nos piden colaboración. Hace unas semanas les envié brevemente mi sugerencia, pero me gustaría aprovechar este espacio público y más extenso para exponer mejor mis propuestas.

Interfaces de Usuario

El año pasado pudimos ver excelentes charlas y ponentes que hablaron sobre diseño, testing, tecnología, metodologías, etc. todo ello muy orientado al desarrollo de páginas y aplicaciones web (diría que casi un 90% de los contenidos del evento).

Si bien es cierto que la web es un origen común de muchos de nosotros, las interfaces de usuario y, por tanto, la experiencia de usuario puede encontrarse en muchos otros paradigmas, a saber, aplicaciones de escritorio, móviles, gestuales, videojuegos, etc. 

Mi propuesta sería incluir más ponentes que nos hablasen de ese otro tipo de interfaces en las que la interacción hombre-máquina no se realiza necesariamente a través de un navegador web.  

La pregunta ahora es ¿quién se apunta?

Ponentes y temáticas

Recomendar ponentes para el UX Spain debería ser fácil, sin embargo, tengo la impresión de que al igual que el año pasado, habrá más críticas hacia cualquiera de los ponentes que admiración por su trabajo. La verdad sea dicha: no todo el mundo sabe hablar en público aunque tenga algo genial que contar, pero no todos los que creen que saben comunicar tienen algo interesante que decir.

Creo que sería positivo que entre las charlas y los ponentes se pudiera ver con facilidad quién pertenece a la vieja y a la nueva escuela, gente con proyectos recientes prometedores (startups) y otros con una buena trayectoria a sus espaladas (seniors). 

Respecto a las temáticas, a lo mejor podrían ofrecerse charlas paralelas de diferentes temáticas: diseño, estrategia, testing, etc; incluyendo más variedad. Me encantaría conocer a UX Developers contar cómo se integra el desarrollo en los procesos de diseño y no a la inversa, y a analistas contar cómo se puede hacer investigación de necesidades de usuario de bajo coste.

No obstante, no quiero perder la oportunidad de apuntar al menos dos nombres propios a los que me gustaría que la organización invitara para el próximo UXSP:

Organización

Entiendo que UXSP es un encuentro, no es un máster ni un taller, sin embargo animaría a los organizadores a proponer charlas, independientemente de los ponentes, con un carácter más didáctico. A este encuentro me gustaría ir a aprender o a inspirarme y ya en los pasillos a encontrarme con la gente que quiero conocer. No me gustaría ver charlas del tipo “este soy yo y esto es lo que hace mi estudio”. Me aburren muchísimo los porfolios no así las historias sobre casos de éxito y fracaso. 

Tras el evento de 2012, una gran cantidad de participantes del evento que compartimos nuestras conclusiones. Una de las consecuencias más interesantes que ha derivado de este evento es que ahora se comparte incluso más. Hay nuevos eventos, más encuentros y más ganas de mover la máquina (a mí personalmente, me ha animado a escribir más sobre mis propia experiencia).

Lo que realmente espero de este año no es solamente que eso no se pierda, sino que se transforme en una nueva aspiración: ¿existen ahora mejores profesionales de la Experiencia de Usuario?

Facebook-like EMR (Part I)

Facebook-like EMR (Part II)

In 2008, Bob Watcher wrote an article called “Why the medical record needs to become more like Facebook” where lay down the idea of having the social network as the mirror for a new Electronic Medical Record (EMR) User Experience (UX). A collaboration and social framework to provide better care to patients while keeping useful information between physicians and nurses.

He was not the only one; already in 2007, Robert Nadler established a high-level model remarking out the core functionalities that it could have EMR software. However, it was not intended to get only a Facebook-like UI but a real social site to connect Patients and Doctors.

The idea is not new; many authors – doctors and software engineers – have continued talking about this idea with no final proposal.

After the latest Facebook re-design I don’t know if those authors would still maintain the same opinion about this topic, anyway I do think it’s a very very interesting approach even assuming any usability issue that Facebook could have. So here are my two cents.

A Design Proposal

Users & Profiles

If a clinical solution would need to completely work like Facebook, every user (physician, nurse, etc.) would have their own user porfile. However, the analysis of having a EMR looking like Facebook timeline suggests that the profile page is planned to show only patient data. Why would we need to see a nurse profile, then?

Following this idea, the Home page would be reserved for (primary) users and the Profile pages for showing the electronic medical records of patients (secondary users).

A possible extension would be allowing the access to the EMRz by Patients, so they could also check their own EMR online by themselves. In this case, we could consider them as secondary users not as part of the network community, but just to contribute to their own medical history and keep a direct communication between them and they’re care providers.

Social network

Social activity will be generated by clinicians considering patient-centred documentation based on Profiles. As suggested before, there are two main social groups: the one created by clinical staff only, and the one where patients and clinicians would interact.

Social interaction is the key point of this proposal and it underpins the main usaibility goals:

Profiles: Patient Timeline

Facebook profile pages have been re-design to look more like a real timeline where any important event is chronologically displayed. In this example, right side will be used to show a summary of the most important event types associated to the patient medical history like Health issues, Allergies, Diagnosis, Requests and Results, Progress Notes, Prescriptions and any other clinical subject. On the left side, any user (doctor, nurse and the patient) could add comments anytime.

Privacy

Privacy should have a strong presence here, since having restricted-access data is a valuable feature that doctors, nurses and patients. They all will need to control the visibility of the data they entered in a fashionable way. Although setting permission in Facebook is pretty hard and unclear to get control about which type of users see which type of patient data or personal comments is still a requirement. This could be done seeing users by their role, applications as domains, and groups as teams. Still, patients are a special kind of user which will have direct access to his own record.

Utility

There’s a weak line which separates the Facebook familiarity advantage into the most confusing UI for a productivity tool and it’s called “enjoyment”. The idea of this Facebook-like EMR was to promote some typical behavioural patter of users when interacting with a social network like:

  • Safe Exploration
  • Microbreaks
  • Habituation
  • News Stream
  • Other people’s advice
  • Personal Recommendations

However, there are some other existing activities that the clinical staff usually does and this UI is not oriented to

  • Changes in Midstream
  • Keyboard only
  • Streamlined repetition activities

Nevertheless, the app integration approach of Facebook suggest me to become a good exercise to imitate outside the UX field.

Content

The content is not about what people think or feels, but what physicians and nurses make, diagnose, treat or provide to patients. The language of the user interface should be adapted to the purpose in order to ease the kind of content expected to be entered.

Data entry is one of the most challenging features in healthcare apps. The smarter the application, the quicker the data is entered. The whole phylosiphy of Facebook puttin atention into every single details should be adopted also to create content such as vital signs, prescriptions, a soap note, or a discharge letter. As an example, below there’s a list of content with different natures which depends on the context of use, the user role and the business model.

  • Task Oriented
    • Notifications
    • Lists of patients
    • Lists of tasks
    • Scheduled activities
    • Events
  • Content Oriented
    • Patient history summary
    • Patient evolution
    • Patient current health status and diagnosis
    • Clinical decisions
    • Procedures
  • Process Oriented
    • Treatments
    • Protocol based care planning
    • Admissions and discharge
    • Scheduling
    • Follow-up

What’s next

This is only the first part of the exercise. For the second part I’ll try more mock-ups and the high-fidelity prototype adding more details also in the content used in this sketch to get a better idea about how crazy (or not) is the proposal of being inspired by Facebook to create an electronic medical record.

There’s also an important gap where Facebook has no direct answer: clinical safety and episode-related information. We’ll talk about it also for the next post.

By now, how realistic do you think it is?

Sketches or Wireframes 

Balsamiq 2.2 has been released with a stylish look & feel, some bug fixing and a new feature to choice how your mock-up will look-like either as an sketch or as a wireframe. But, is it the skin the only thing that matters?

There are some differences between these three terms commonly wrongly used between designers, although it’s also true that there are some overlap which may be the reason of such confusion.

Sketches

In the context of design, sketching is rapid, freehand drawing that we do with no intention of its becoming a finished product.

… sketching is a tool that supports the process of making, not the actual design itself.

via @uxmatters

Wireframes

A wireframe’s purpose is to communicate and explore the concepts that come out of sketching

via @uxmatters

So what’s the difference? Probably there’s no difference except the fidelity degree or the formalism of the idea. Anyhow, I think it’s a good practice really making a distinction and below I’ve listed some thoughts about it:

  1. While wireframes is a tool to think, communicate and explore, sketches are a tool to expose hypothesis, to let ideas born quickly and easily.
  2. As Balsamiq suggests, sketches look more hand-made suggesting also that the level of details is less than when using wireframes – I know you’re a great drawer but I mean with details not a fashion of art but a specification.
  3. Sketches suggests ideas to oneself, wireframes propose ideas to others.
  4. Sketches doesn’t need to specify concepts, interactions or navigation very strictly, but wireframes requires a good presentation of the visual language – ui elements, alignment, content design, navigation, and workflows.
  5. Sketches are forced to die after the exploration, wireframes could be our first deliverable in the design process.

What about prototypes?

Prototypes doesn’t need to be the evolution of a wireframe but a proof of concept of one of the many proposals designed it as wireframes. The goal is to test and validate an idea, and as sketches and wireframes, it will require to be polish up.

 

This is only a brief about the differences about sketches, wireframes and prototypes, if you are interested in this topic I suggest you to read the article  “Sketches and Wireframes and Prototypes! Oh My! Creating Your Own Magical Wizard Experience” as an starting point.

Other recommended links:

Let’s be there…

…UX designers can do more. Learn about the problematic healthcare cultural characteristics that dominate and that need to change… Don’t limit yourself to incremental innovation and work that is narrowly focused on UIs.

Richard Anderson

It is, with no doubt, a designer commitment, to go beyond the line that limits the user interface, the software and contribute to transform the healthcare industry by improving processes, patient care, and services.

It’s even more crucial nowadays, when there’s an uncertain investment in healthcare from public sectors.