An Eye On Design

Hello world!

Yesterday Microsoft announced its new search website:

Bing (formally know as Kumo) is a huge improvement in Microsoft in the search capability area, specially if compared to Live.com.

I have tested Kumo (I need to reset my brain to the new name) a lot in the past months, as we used it internally for any kind of search. And I have to say that the experience was pretty good, although I have never spent a minute thinking to compare it to Google or write a post about it. At the end, does the world need another search engine? For my surprise, yesterday when I asked for some ideas for this post via Twitter, a good friend of mine, working in Russia at this moment, replied me back asking to talk about Bing. So, Bing will be!

My review will be under the optics of the user experience. I am not an expert in search engines, neither is my intention to compare Bing against Google or Yahoo! technicalities in this post. If you want to find out more about these topics, bing them and you will see lots of articles about it.

The Name Bing

Let start this review discussing the name choice. According Steve Balmer, "We chose Bing because it’s short, memorable, and symbolic of the moment when information and opportunity come together and a simple search becomes an engine for taking action.". I agree that is easier to transform the word in a verb (as I sampled above, I will bing and see what it returns, like you google something) than the word Live. Particularly, I didn’t like the marketing strategy behind it. Remember, we are still going to have Live Messenger, Live Spaces, and so on but, our new search engine is Bing! The competitor has Google Search, Google Apps, and so on. Much smart, I think. But, I know Microsoft. Maybe the products names are going to change in a near future either (we are good renaming things .

My rating:

The Logo

I have mixed feelings about the logo. The color choice was an easy decision to the designers as blue and orange are complimentary colors, fitting always, no matter the logo design decision. What I didn’t absorbed yet was the font choice. Maybe they selected a “circular/oval” design to facilitate to play with the logo in special occasions like Google does during Christmas and other holidays.

My rating:

The Interface Design

I think Microsoft excelled here. The original Live interface was beautiful. The tweaks for Bing worked even more than the original. The daily updated pictures are gorgeous, specially now that you can see the previous ones, using the arrow buttons at the bottom right part of the screen. I know some people that come back everyday to Bing (Live and Kumo in the past) just to check the pictures. The new feature of find some information spots in the picture is a blast! Sometimes I forgot what I was looking for because I played a lot trying to find the image spots. Believe me, it is addictive!

It is complicate to evaluate a search interface, considering function will always be more important than the form. People goes to a search page to find something not to see pictures or anything else. But, my kudos to the new interface (not only the categories menu but mostly due the bottom bar with some interested suggestions and information).

The drawback of this interface (I couldn’t test it in a smartphone or iPhone) seems to be the time to download the images. I am looking forward to see how is the experience in a small screen.

I will cover the results page later on this post because I really think it is not only a result page but a good piece of interaction design.

My rating:

The Interaction Design

Ok, supposing you have success and stopped to play with the image spots, you did you search. What about the results? Take a look at this result page (in this case I search for American Idol. No, I am not Adam Lambert’s fan. I vote for Danny.):

The development team did a great job here in my honest opinion. Besides the Best match the really beauty comes from the category menu in the left side. What a great way to classify the information to the show fans! You can see it by episode, cast, quotes, and the list goes on! Try the News category and the update will surprise you!

My favorite kind of result is when you look for something close to you (a shop, movie, show, etc). See the results for the movie UP, from Pixar:

Very nice to see the best movie theaters near me but also the session times. Cool! Take a look also to the SEARCH HISTORY on the bottom part of the category menu. Really sweet have them at hands? I don’t know you but, many times I see myself looking for things I have searched few days ago.

Compare the same results from Google and you will see the interaction design of Bing is far better than the competitor (*the image below is an updated search done in June, 23. Google has done a good job updating the info although the showtimes are for a place I have no idea it is. Originally, the result did not show any showtime recomendation, which probably means Google had not recognized UP as a movie name):

My rating:

Overall

As I mentioned in the beginning of this posting, I am not capable to evaluate search algorithms or quality of results from any search engine. What I can talk about are the aspects of visual and interaction design, and for me it is clear that Microsoft spent much more labor hours in to improve the way people search and digest information than Google. Does it mean people will leave Google and Bing everywhere? Of course not! Google has established standards that are difficult to beat, they are integrated with almost every browser in the world besides Internet Explorer, and have a consistent history on search (how many search engines Microsoft brought in the past: MSN search, Search service, Search Server, SharePoint Server, Fast, Live, etc).

What I applaud in Bing is the tentative to establish a connection with the user. While Google is just about function: search, find and leave, Bing is about decrease barriers to users: search, find, digest, find more, enjoy, come back. This is a huge step forward to the search experience, and for me, this is great. I will bing more, will you? Let me know.

Alex

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!