An Eye On Design

Few months ago I received an email from a Microsoft partner asking me to write about the future of interaction. What is next in this field considering the innovations that came with Microsoft Surface and Apple iPhone? was his question.

First of all, let’s remind that this blog is just a space for my personal opinions, not Microsoft. Also, being a personal space it allows me to talk about not only Microsoft products but ANY other products and interfaces I admire.

Touch interactions

Like everybody, I was amazed with when I first saw the iPhone and Surface. I had seen several projects using this kind of interaction in the past but, all of them restricted to an specific environment, many times requiring hard setups to operate. The beauty of Microsoft and Apple’s products is the fact they are, for the first time, spreading the technology to the world. Now, it is a commodity. Today, almost every cellphone has a touch interface, Windows 7 will embrace the technology (in fact HP has already a multi-touch screen computer running Windows Vista), Apple brought this to their MacBook touchpad, and the list goes on. As you already know, the concept is pretty simple. Touch whatever you want. Your fingers are in control.

This kind of interaction however is not the answer for every problem. Are you happing filling out long forms using the screen keyboard? Can you play your favorite but complex games using just 1 or 2 fingers? I am not, although I recognize the great job some game developers are doing with the multi-touch SDKs available.

What about voice recognition?

An older but very effective way to interact with machines is voice recognition. Have you seen how many progresses we had in this area? It is present everywhere, from your supermarket kiosk to every call center. Use your voice to command your intentions. To be honest, this is a technology I expect to see developers and designers using more in a near future, specially when the voice recognition engines become more friendly to other languages than English. Don’t you think it would be nice to talk naturally, as we do in real life, and have your results back?

Motion capture

The progresses in motion capture technology have changed the motion picture industry and they are close to do the same in the game industry. Can you image to animate Gollum or a dinosaur using stop motion animation? No way!

The concept is simple: 1) define some control points in the object to be animated, 2) using a camera, capture the object, 3) with a software, discover the control points in the image and 4) process the results.

A great example is the Wii Remote, although they use a different kind of motion capture (some accelerometer controls send the position of the control to the console that triangulates the positions and replicates it into the games). No more 515 buttons in your joystick! Move your remote and you are done!

Although I like the Wii concept, I am not a fan of their games (I think they lack in graphic quality), neither of the model (ok, I am against the world, you may say) of interaction. I never like the idea to use special glass to be immersive in a virtual reality game, or any other kind of device. They are simply not natural and for me, the Wii remote is very similar to this model as you have to wear the remote (the Wii Board is cool thou!).

One thing that brought my attention lately is Project Natal, from Microsoft (to be honest, I know as many as you about this project). The idea (using the basic principle I mentioned above) is to capture player movements using a camera attached to XBOX 360. No need to wear any kind of device. Do your moves and the software does the rest. Are you curious about that? See the first public presentation at http://www.joystiq.com/2009/06/11/video-project-natal-invades-late-night-with-jimmy-fallon/

So, are these technologies the future?

Fact is we use all our 5 senses to interact with the real world. No current technology alone is providing yet the full immersion we would like to have. Touch is not the answer for every problem, neither is the Wii remote or even Project Natal but we have to agree they are great steps for the future of interaction.

With these public technologies we are already covered in touch, vision, audio. Now it is time to see what is coming for smelling and flavor detection. Wouldn’t you like to taste some food and maybe have all the ingredients detect by your tongue? Can you imagine being at home, tasting a good cheese or wine and have their name or brand automatically detected? Or just say to your computer: Please buy me the cologne I am smelling now.

Futurology apart, the advances in interaction technologies are amazing. Expect to see in a near future deep interaction like the ones you have visiting installations in several museums, where you can not only see, hear and touch things but also smell the environment. Imagine to play a game where you can smell the fear? It would be nice, no?

Stop imagine! Download the available SDKs and start to change the world!

As I mentioned in my last week posting, I would like to share some experiences I had supporting a friend’s project few months ago. I will focus only on how we worked together as a small team and I will also illustrate the way I designed the product from concept to reality.

The Project Goal

Create an innovative software to support dentists to pre-sale whitening treatments. It must be easy to use, not expensive, with features that excite patients to pay for whitening treatment.

The Team

Besides me (interactive/interface designer), a developer (of course writing the code) and a dentist (responsible for the whitening probability matrix). After one “in person” meeting, all other interactions were done via email or phone, with live checkpoints after finishing important milestones (I will cover them later).

Making things work

Although it was such a small team, it is important to highlight that three different backgrounds means different approaches to present and agree in things (for example, be prepared to work with more than one way of presenting things –the developer can understand some small sketches and thumbnails, the dentist will need a high definition mockup to perceive the same information), saying that, keep in mind the advice I gave in the first posting about users not being like you:

• They do not have the same equipment you have;
• They do not have the same education/specialization you have;
• They are not interested in technical details as you do;

With the agreement of sharing info via email or instant messaging as need, the developer and I mixed the piggyback and parallel integration model. This mix is easy to implement in a small team (by the way this is one of the advantages of teams with such few members), although should be complicate to be implemented in the case of several designers and/or developers working together.

After the live meeting with the dentist, the decision was to create a product targeting whitening features. With this information, the decision was to lock the basic features as:

• Create/Open Patient: allowing the creation of treatments based on new or previous patients;
• Import of pictures: to be manipulated in front of the customer;
• Matrix of whitening: a table with customer data that helps to estimate the rate of success of the treatment;
• Teeth selection: tool to select the teeth area for image manipulation;
• Pictures comparison: a list of patient pictures showing before/after results;

The Design Process

The development world is limited to the IDE they most use (my friend in this project was in front of Visual Studio for the entire project). Designers have much more tools to work with. We can sketch on paper, we have several graphic tools like Photoshop, Fireworks, Expression Design, etc, and recently, a bunch of prototyping tools like Balsamiq, iRise, GUI Design Studio (this is the one I have used most) and, in a few months, Expression Blend with SketchFlow (more on that in the future postings).

With the data that I had, plus the basic persona document I covered in the last posting, I started with my favorite tool: paper thumbnail sketching! This is the part of designing I love much. It is easy, free (in costs and responsibilities) and it clarifies any idea you have. Below you can see some of the thumbs I have used in different projects I have worked or will work a day, when I win over laziness. I couldn’t find any thumb from this particular project but it is ok, as thumbs should be disposable.

Basic pencil and paper, just to block interface spaces.

A little bit more of details, again in pencil and paper.

Another interface blocking example.

Several studies in pen and paper.

Working with measurements.

Another great advantage of thumbnails is the fact they are understandable by developers too. In this particular project, I used them to defined the basics of the interface. With this info, the developer was able to start the design of the forms of the application (in this case the decision was to use Windows Forms instead of WPF due the fact most of our target customers are using some older machines), blocking interface spaces, being able to keep his focus on the image manipulation area, for example.

As mentioned before, our friend the dentist was not that “visionary” as the developer. Thumbnails and mockups (static image files) are good tools for designers and project members but, unfortunately experience shows that they are not good enough for overall users. To them, the best way to show something is thru prototypes.

Prototypes can be seen in several forms (search Wikipedia for example and you will see several different types). In order to keep this post not enormous, I will mention only LOW, MEDIUM and HIGH definition types.

A low def prototype can be done using only paper or PowerPoint. You sketch the interface in a paper (or in a slide), draw some buttons placing them on top of the first sheet you drew the interface and start your tests. Low def prototypes are good for testing basic interactions (by the way, conventional things like Login, Go Back, etc don’t need to be prototyped as users are already familiar with that –of course this not applies if you are building a new kind of login) although many designers are questioning the efficacy of this method as many end users are not able to fully understand them. Also, with the number of tools we have today to simulate interactions (PowerPoint included), it is worthy to spend a few more hours and build a medium or high definition prototype.

Some people disagree with the idea of medium def prototype. To them, anything more detailed than a low def version is a high def by definition. To me, high definition prototypes should be done only in more advanced phases of your project (you will read my real example in a minute or two). The concept of medium definition I use is something that has interactivity with a known interface that allows the user to navigate without further instruction (although in most case the interface graphics are far from the final).

When I had to show my concept to our dentist, I created a “medium” definition prototype using GUI Design. If you install the player they provide for free, you can see the first interaction I built (to see better, after open my project, right click and disable Annotation Tool Tips). You can also see the documentation file the product generates, which helps a lot the development process.

After seeing the prototype, our friend the dentist was convinced that some features were not making sense, like the idea of having a gallery with different pictures of the patient. According him this process occurs only one time. This info was very interested and supported me in the decision to move the original patient data menu from the right to the bottom of the interface.

The next step was to build the first mockup of the interface, as you can see below.

As you probably notice (the dentist did) the interface is totally different than the ones he was familiar with (almost all dentistry software have a Windows Form like interface). Being a designer, I explained him the decisions on the colors (gray is a neutral color that do not compete with the photo colors. If I had use white as background, patients would not be that impressed with the new white color in their teeth, for example), and the bottom position of the menu (my studies showed me that patients seat in the dentist chair look for a monitor positioned on top of their heads, making the top part of the interface the most important to them). Positioning the menu on the bottom (not the standard pattern) allowed the dentist to work freely with the menus without having to trail the mouse over the patient picture, which would cause a distraction to them. The way it was designed allows the patient to be focused only in their mouth).

A few reviews helped me to select the final color palette and menu positioning. With this mockup, the developer was ready to implement the code and build our first high definition prototype.

The decision to make a high definition prototype varies from each project. In our case, we decided to make it as our intention was to validate if this kind of software would have acceptance or not from potential customers. Basically we would like to validate the concept with real dentists and collect their perceptions. Would they buy it? Our high def proto had only the main feature done (the teeth selection and the whitening results according the Patient Data selection), optimized for a single photo. Also, in order to make things quickly, I used free icons available in the web to build the interface (to be honest, I am not a good illustrator and to draw icons for me is painful).

With this prototype we collected good feedback from our users and my friends decided to GO with their product. I did some tweaks in the interface, making it able for our first usability test.

The results of the usability session were interesting as several things we judged “cool” (remember the importance of having a good persona document and keep your development always thinking in her/his?) were considering distractions. Also, things that we thought were not that important appeared as a must have to the potential customers. Another round of improvements (now I had to draw every icon…) and the software was ready for the last usability test.

As you can see, the final interface was pretty close to the original mockups.

The total project time (from the first meeting to my last sent icon file) was around 3 months, which I think was a nice time considering my, and also my friend’s, part time involvement, 1 medium, 1 high definition prototype, plus 2 usability sessions.

Some learning includes:

• More time dedicated to your persona definition means less re-work in further development phases;
• Sketch as many thumbs as possible. They are like visual brainstorms (there are no right or wrong). Thumbs helped me to position the main menu in the bottom, making the interface very unique;
• Establish a formal way of model integration (define file names, shared folders, feature sheet, etc) before to start your project;
• Do NOT spend much time in Photoshop or Visual Studio (or whatever is your favorite graphic/IDE tool) in the initial phases of your project! Agree in features first, plan, mockup than prototype!
• Approach end users with high definition (or at least medium def) prototypes. Low fidelity prototypes are great for the development team only;
• Involve designers and developers since the begin. It would be very difficult to me to fix the interface flaw I mentioned early, if the developer had locked by code all the elements of the UI.

I hope this posting have brought some good ideas and concepts to you. Let me know your comments!

Alex

Welcome to the first blog of Alex Souza An Eye On Design! I hope you enjoy the reading and provided feedback on topics you would like to see and discuss here. So, let’s start my first one!

Last year I was invited to give a talk at Microsoft TechEd Brazil. This annual event brings together developers and IT professionals around the country to a full 3 days conference, with sessions from 8AM to 7PM. In 2008, the number of attendees was around 2,000. My session was the last one of the first day, and I thought it would be empty due the fact the theme is not that technical, several other good sessions were scheduled at the same time and, most important, just a few designers attend the event. For my positive surprise, my session was packed with people! I finish the slides around 6:20PM, giving the audience the opportunity to ask questions up to 6:45PM, the official end of the day. It was amazing to answer questions to 7:15PM, with the last person walking with me to my car in the parking lot, around 7:30PM. It proves to me that the user experience theme is something that is very relevant not only to designers but also to our fellow colleagues developers and IT professionals. In fact, I replicate this session in Argentina and Uruguay with the same excellent results.

As usual, the organizers get topics and content from the best presentations of TechEd USA and adapt the subjects to local needs. In my case, they asked me to build on top of the session present by Mark Miller (he is is Chief Architect of the IDE Tools division at Developer Express at Microsoft – more on his blog). After see Mark’s presentation, I decided to “spice” a little bit some topics covered. Don’t get me wrong here, Mark’s job was great but do not forget he is a DEVELOPER, not a designer.

Basically my presentation was built with the idea of answering 3 excuses some developers may have about the lack (or bad) design in their products:

1) “User interface is subjective” (so, let’s spend a minimal time here);

2) “I am not an artist” (so, forgive my horrible color and font selection, just to name a few problems on the user experience);

3) “We can’t fix the user interface” (so, no matter how bad it is, use it like this!);

As you can see in the presentation (unfortunately the PowerPoint file was too big to upload, so, take a look at the PDF file attached. I changed all the backgrounds to white in order to minimize file size.), I tried to answer the statements using some of Mark’s suggestions but also my own experience as designer. Here goes the replies:

1) “User interface is subjective”

UIs can be measured using basic tips, like Mark’s Cost of Pressing Keys table, or real methodologies, like GOMS, on how to improve the cost of interaction. It means that we can track (and solve) pretty much all user interactions using the keyboard, the mouse, or even gestures.

My main contribution in this topic was to remind the audience about the importance of understand the differences between the several user models. Interfaces close to the implementation model (the way a device works) are worse than the ones close to the mental model (the way users understand how a device works). Here goes a quick example: what is closer to the mental model?

2) “I am not an artist”

I have to say this is my favorite topic from all of them. With all the resources that the web provides today, there is no excuses to keep the development or maintenance of horrible applications (in my design scale, horrible means the lack of use of best documented practices like, how to create color palettes, or how to select fonts, for example).

Again, I kept Mark’s suggestions, amplifying some topics he briefly introduced. For example, talking about colors, he suggests the use of HSL (Hue, Saturation and Luminance) instead of RGB (Red, Green, Blue), without any mention to basic color theory. Here, I talked about rules on how to build a good palette, according your needs and knowledge. Colors, alone, can (and may) be a completed posting, what shows the importance of this element in the user experience.

Here a simple “bad example”:

Take a minute a try to figure out how many designs flaws you can find here. I can name some to you (of course this is an amplified bad example but, think twice and remember how many UIs like that you have seen):

• Too many colors, no rules applied;
• Too many fonts! Too many bold;
• Drop shadows in the “Comic Sans” title;
• Horizontal bar not necessary in the first text area;
• Button Close, secondary trigger here, is much BIGGER than the Send button, the most common trigger.

Take a look now at the same application, with just minor adjustments (no need of a “super hyper” designer here):

Some improvements done:

• As the developer wanted to use colors instead of the plain components, a simple color palette (shades of blue only, plus white and grey, neutral colors that match everything) was selected;
• The Tekton Pro font is easier to read and much more sophisticated, but also fun, than the Comic Sans. Also, the same Windows default font was used for the rest of the interface;
• The secondary action (Close) button was resized and moved to the left. The Send button was increased a little to reinforce its importance in the navigation;
• Drop shadow was not necessary in this case!

3) “We can’t fix the user interface”

The last topic is basically a junction of the first 2 ones. In the moment you know how to improve the interactions and learn how to control the user mood with the use of fonts and colors, it is easier to discover and fix basic interfaces problems.

To finish this first part, remember these basic rules to not be graded in my scale as horrible:

• Do not use more that 2 fonts families in your projects (1 for titles and 1 for body). Ah, NEVER use the “famous” Comic Sans in professional applications (except only if you are coding an app for kids);
• Avoid the use of several colors. Select a rule (monochromatic, triad, etc) and keep it to the end;
• Simplify the amount of information presented in each screen;
• Users are not like you:
  • They do not have the same equipment you have;
  • They do not have the same education/specialization you have;
  • They are not interested in technical details as you do;

A great user experience is worth the effort!

Next week: Integrating developers and designers

Take care!