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

This is a frequent topic after presentations: Do you recommend a book for topic A or B?

Before provide my favorite list, let me remind that I DO NOT receive anything from publishers or authors to recommend them. The list below is just a sample of books that helped me in past projects.

[Usability] Don’t Make Me Think from Steve Krug stills a classic. It is simple and very effective. You can read it in 1-2 hours and after that you will master the usability topic.

[Overall Design] Designing Web Sites That Sells from Shayne Bowman and Chris Willis. This one is hard to find now (really do not know why there is no more editions of it. It is beautiful and insightful even if you are not designing a commerce website.

[Interface] Designing Interfaces: Patters for Effective Interaction Design from Jenifer Tidwell. I have to admit I have never read it from cover to cover but it is a good companion when you need a reference about use or not a specific type of interface component.

[Project Management] Web ReDesign from Kelly Goto and Emily Cotler is a plus when you need to understand how to update a website, how to communicate well with your customer and also document your progresses.

[CSS] The Art and Science of CSS by Sitepoint Publishing. Quick reading, color samples and good tips on several topics like forms, menus, etc.

Can you share you list with me now?

Take care,

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

<<INSERT IMAGE>>

I know, you are probably thinking right now: “Alex is getting crazy! Of course I know my customer and my project audience!”.

No, I am not crazy. Fact is most user interfaces fail because they were not thought to be used for the right audience.

Customers tend to believe that their products have broader audiences than the reality. How many times have you asked your customer about their target website and have heard back “every person”? Sometimes your customers just don’t know about their real audience. In other situations, they are defining to you their dream customer instead of the real one.

Let me share a real case I had few years ago while I was teaching a user interface course in Brazil. One of my students came with a sample multimedia application and asked me to evaluate and provide him some reasons why the sales were not that good, although his product was very innovative.

Even before to load the cd in my notebook, I asked him about the project and his target audience. He briefly explained me that he was scanning top model (or girls trying to become top model, to be precise), shooting a video with them, and transforming the photos+video into a multimedia cd. Going further, I asked him the most simple question: who do you think is you target audience? He then promptly replied me: “models trying to sell their photo book in a digital way”.

Unfortunately, my student was wrong (as many of us are in several projects). He was thinking with his marketing side of brain. His potential buyers were the top models but, his product users were the agency owners/recruiters/beauty hunters which, sadly, didn’t use at the time (I don’t know if it change today) computer to view a photo or video book.

This simple example illustrates the importance of having a detailed persona page (or multiple persona pages if your application/website target is more than an unique kind of user), with the characteristics of a fictional target user.

Basically, the persona page has a profile with information about your real potential user. You can detail as much data as possible in this document. Things like gender, age, hobbies, equipment they use, etc. When built, this sheet must be shared and used by all team members, as a guidance during the development stages, helping you to keep focusing in the right people instead of bring unnecessary features to the end user (for example, maybe it will be not a good idea to have a multi-touch component, although it is brand new and cool, if your persona sheet tells you that your target user do not have a touch screen monitor).

Here go some tips on how to create your persona pages:

• Find your real user group first (in my student case, the main group was people related to the top model business);
• Separate potential buyers from potential users (using the same case above, top models were buyers, agency owners were users). Marketing strategies, and the overall user experience can contemplate a potential buyer persona, but it is another topic. For development, we will need only the user persona page;
• When you agree about the correct user, create his/her persona sheet with as much details as possible. The first ones will may sound strange (I had problems with my first ones also, as I thought they were unnecessary due the fact I was convinced I knew my user) but they will be a valuable resource for your team and specially to your project managers, when your developer or designer come with a “very cool” feature that can delay your project in two weeks. Just reply them: is it targeting the persona we have? If yes, lets discuss, otherwise, keep the idea for a future project;
• Deep down on the persona sheet. Try to answer questions like what is his/her equipment? how they use it? Is there any particularity in their work environment we should consider?
• Share the sheet and make it mandatory during development phases. Again, the more detailed it is, less chance of change your specifications.

This a persona page sample I used while helping a friend’s project few months ago (my entire participation in this project, from conception to designing the final interface will be covered in the next topics, in order to illustrate how small teams of designers and developers can work together without major issues).

Let me know your thoughts and experiences using personas. Do they work for you? What you like (and dislike)?

Next topic: A Real Case

As part of my presentation The Science Behind Great User Interfaces (see the previous posting), I take some time to discuss a little about the integration between developers and designers. For my surprise, this topic generates lots of questions and late emails asking me about further literature and/or training. As I am not an expert in the topic, I will give you my personal experiences (please jump in here and share your stories). Let’s go then!

Scenario 1 – The Ladder Integration Model (by the way, thanks Arturo Toledo for the beautiful diagrams, used in the slide, explaining the models)

So, you have your company and a new project in your hands. Like in many similar projects, you probably call your development team (1 or more developer), discussed the aim, defined the main features, and start to build the first prototypes. After that, you have another meeting with your customer, present the progresses and, oops! your clients did not get lots of things you built, and was confused with some interactions. “No problem Mr. Customer, our designers are working in the new user interface that will be great!”. You come back to your office thinking: “where in Earth am I going to find a designer to help me here?”. Luckily you hire a designer that will try to build a better user experience using the bones of your current application. Fortunately, some interactions can be solved. Sadly, others cannot without blowing your timelines or project costs. You go back to your customer and tell him that "some features are like this by design”, hoping that he/she accepts this explanation because, “at the end, it is working and doing the function my customer asked for”.

This is the ladder model. You define everything with your developer team (in some minor cases, the opposite, all the definitions come from designers), and involve designers just at the end phases, mainly during usability tests, hoping they can do miracles and solve technological and/or interaction problems found by customers and, even worse, in some cases discovered even early by the development team. In its defense, this model is the easiest one to implement, very predictable (for the good or the bad) and, in many but not all cases, cost effective (you do not have to hire a fulltime designer, hiring them on demand only).

Scenario 2 – The Piggyback Model

So, you have your company and a new project in your hands. Your project management team analyses the scope, define the main features, call the design (or the development) team (whichever is the most important in your company), and ask them to start the design (from now on I will use the design team as the strongest one just to exemplify the model). Every time the designer finish, let’s say, a button, he asks a developer to create to code. This way, piece by piece you start to have your app. You may say “what is the problem of this model, as every thing sounds perfect?”.

There are some problems with this model. Like the ladder, one team tends to have more power than the other, which can make decisions based not on real needs but people interests. Also, the time to market in general is longer than expected because, every time someone needs something, they have to start the process again. Add to that different work times from developers and designers to this equation, and you can see the size of the mess (you know this scene, right?):

9AM

[DEVELOPER on the phone]: Hey designer, I need to test a new build and I must have a new button right now!

[DESIGNER moaning] Dude, are you crazy? Is is 9AM in the morning? Don’t you sleep? I was in the office yesterday till 3AM! Can’t you use a previous version of my button?

3PM

[DESIGNER in the office checking the new build] Hey dev, are you crazy? You killed my interface with this ugly, jagged button!

[DEVELOPER] Man, take it easy! It is your previous button! I just resized it and change the color using my Paint! Don’t you liked it? Well, if you don’t like, build me a new one!

Scenario 3 – The Parallel Model

So, you have your company and a new project in your hands. Your team, with developer and designer participants, discuss and agrees on the concept. Some mockups are done and tested to guarantee the best user interactions are selected. Nobody writes a line of code or a high def prototype yet (more on prototypes in a future posting). With the agreed mockup, the team builds a naming convention document (basically a document describing all application/screen elements, giving them names, types, etc), and share it with all production components. In a small team, a shared folder is created (I suggest a Live Mesh project because you can work online no matter in the office or not) and people start to code in parallel (large teams probably use tools like Visual Studio Team System, or similar).

Besides a naming convention document made in Word, in later phases of planning, you can use also a more visual version of it:

“I want to be part of that!”, you main say aloud. Unfortunately this model has its drawbacks either. It requires structured teams, a project owner with good understanding of design and development (he/she is the bridge between the two teams, especially in conflict topics), and a good amount of planning before code (how many developers do you know that think first, code second? Don’t get me wrong here but, when I am coding, I would rather be in from of my editor! So are most of the developers I know!)

What is better for me?

To be honest, there is no right answer to this question. As mentioned above, every model (for sure there are others) has advantages and problems. My suggestions are, no matter the size of your company:

• First of all, organize yourself. If you do not have yet basic project management infrastructure, select one (it can be a file server with folders by project, or, like mentioned before, a project folder using Live Mesh), and implement it with your team.
• Try to spend more time on planning, instead of jumping to Visual Studio, Photoshop, or whatever is your development choice. Some experts suggests to dedicate at least 20% of the project time on planning.
• After agree in your mockups (I will cover the user experience planning in a future post), try to establish and share a naming convention document.
• If you have both design and dev team inside, involve them in the planning phase. Not only great ideas can come from them but, even more important, they can alert about things they are not able to do (due lack of training, experience, tools, etc) yet. It is better not present a fancy new 4D navigational idea to a customer, instead of having your project sold due this great idea and have no means to implement it.
• Have constant checkpoints with both designers and developers.
• Evaluate your team. Which model are they using currently? Are they ready for the parallel model? Be honest with you and them. Maybe it is better to fix small issues in your current way of doing things before to try a large next step.

Hope this topic was valuable. I am planning to cover a real case in the following posts (from concept to delivery) but I am open to your suggestions. Please feel free to use the new Contact page and send me your questions. Saying that, if not comes, check here next week: Do you REALLY know your customer?

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!