Design Lessons Learned Example

February 27, 2010 1 Comment

One of our top posts so far this year is our post about design lessons learned in 2009.  We provided suggestions that might help you successfully complete your design project along with examples of our work.  The key tips we presented were as follows:

  1. Start from a creative brief
  2. Use multiple visuals
  3. Plan to start over at least once

At the end of the post, we showed a hint of a work in progress.  We now can say the mock-ups were from our new product hinventory.com.  You can learn more about our launch in the hinventory.com blog.  We thought we’d go through the design steps in more detail to help illustrate the tips presented above.

hinventory.com started from a real need in my own life.  I had previously gone through the painful process of cataloging everything I owned in excruciating detail. The process was time-consuming and I soon gave up maintaining the list as do most people.  Late last year, I was thinking about the simplest way to get this done when it hit me that all I really wanted was take photos and mark the significant items in the photo.

First, we wrote some specs and did a creative brief to better define the product.  I can honestly say I am addicted to the creative brief at this point.  There’s nothing like collecting your thoughts to focus what you are trying to do.  I may even start doing them for house projects or working in the garden!  The graphic below is our proof of concept piece that went with the creative brief to help define the product.

Once we understood the direction, we set about developing the product.  The first version was intended to be a working prototype or beta that we hoped to get some users testing.  The interface is presented below.  Feedback on the product confirmed the market opportunity. But…

… the interface faced some challenges.  When developing functionality you sometimes make design compromises in the name of productivity you later regret.  This interface looks like it belongs on the TV show Romper Room for those of you who remember that.  The logo and banner are straight from a 3 year old’s bedroom.  It doesn’t work, I know.

Lesson learned.  Start over.  Get some fresh eyes.  Maybe hire a graphic artist.  We did.  We used one of our favorite artists in Costa Rica and she didn’t disappoint us.

The above interface is the one we selected over the examples in our lessons learned post.  The interface is clean, intuitive and aesthetically pleasing.  Putting the content inside boxes though can lead to problems later on.  If I had to list a fourth lesson learned from last year, it would be to design for functional expansion and page growth.  We did another round of mock-ups using less restrictions on the actual page content.

We selected number 3 as the final design and then moved on to the logo.  Here are the samples we created before sending a few select ideas to our artist.  Using multiple visuals proved key for illustrating to our artist what we liked and what we did not.

We ran into one final design issue during the course of development.   Take a look at our iPhone application mock-up below and see if you notice the issue.  We created the mock-up ourselves.  We’re launching the app next month so keep your eyes and ears open.

Do you see the issue?  The problem was the markers.  They are barely visible.  The same issue existed in the Web version, but we hadn’t noticed it as much until we saw the photos on the iPhone.  Marking items is essential to both applications.  We moved to a red marker inspired by what you see on a map.  The final interface markers and all is displayed on our product page.

You can see the product yourself by signing up on hinventory.com and using the product.  We hope you do.

Cheers.

Filed under Development Management Tagged with , ,

Apple Likely To Overtake Microsoft

April 18, 2009 2 Comments

I am convinced it is just a matter of time before Apple will over take Windows as the dominant operating system on personal computers.  Let’s look at the facts:

- I am doing my taxes on my Mac this year for the first time.  I have years and years of Windows Turbo Tax data files from at least 3 generations of computers.  Having the history helps me get through the experience each year.  Installing Turbo Tax this year, however, has rendered my Windows system useless.  I can only boot safe mode to access my files.  Big thanks to Intuit for giving me the Mac version to complete my taxes.

- We have a family laptop that is stuck with Windows Vista.  The machine is slow and cumbersome.  We constantly lose the wireless connection and are forced to re-boot often to get Blackberry active sync working.  My iPhone works with my iTunes as if they were developed by the same company.

- We use Google docs and other online tools at work for 80% of our document creation.  Graphics work is most of the remaining 20%.  We do this work offline but guess what, Photoshop, Fireworks, and the lot, run equally on Mac and Windows.

- My Windows machine was turned off for a week.  A whole week!  This is a big one.  I use a computer more than anyone I know for many things such as contributing to community sites, writing this blog, and developing software.  A week for me is like a year for everyone else.  Monday morning the other week I turned on my Mac and started working.  By Friday, we were both looking forward to the weekend while my Windows desktop was cold to the touch.  I still can’t believe I never had cause to turn it on.

- My office TV is Windows Media server using the second monitor as the display, but I rarely use it anymore.  All my favorite shows play episodes on the Web after the initial TV run.  NetFlix offers movies online.  I don’t even have to DV-R Heroes.  YouTube and FunnyOrDie are great distractions if I want something new.

- I am totally addicted to Spaces on my Mac.  I have multiple work spaces running all the time that I flip through so quickly people watching me get motion sickness.  There is no chance of getting motion sickness with Windows.

Let me summarize.

The Mac OS is easier to use and more reliable than the Windows.  It’s fast and fun.  The applications I depend on are no longer OS specific.  Rich content is readily available online.  The files I created on Windows over the last 10 years are in my Mac documents folder.  I really don’t need the Window machine much for anything anymore.

All the strangleholds and monopolistic software plays that made Windows what is it today are gone.  For example, MS Office was once required at work.  Now, if it doesn’t come with the machine, people don’t need to buy this expensive software.  I am struggling to find just one example of something I must have Windows for.  The fact is I am several hours into my Monday as of now and I still have not started Windows (to be honest, that’s because the first thing I know I have to do is fix the problem I am ignoring).

Windows continues to go head-to-head with Mac and people are taking a good hard look at the merits of each.  Most of the people I know are going Mac.  The transition happened over the last 5 years to the point where I don’t know anyone raving about the Windows laptop they just bought.  Did I mention I am doing my taxes on my Mac for the first time this year?

Filed under Development Management Tagged with , , ,

Facebook Should Use Feedback Loops During Development

March 23, 2009 4 Comments

Many facebook users are unhappy with the new interface that launched recently.  A poll of facebook users showed 94% of users do not like the changes.   Just search for “facebook interface” on the site and you will see what people are talking about.   Finally, we can all see the benefit of online software with the possibility of immediate feedback!

How do you end up making changes to a site that so many of your users don’t like?  This question is hard to answer without more insight into the organization.  One way to reduce the chance of producing unwanted changes is to create healthy feedback loops during development.  Users love to give feedback if you provide the opportunity as we can see through the numerous responses to the new interface.

How to gather feedback

Here are some ways developers can gather feedback on their ideas and proposed changes.  I must say up front that I am not connected to facebook and have no idea if any of these processes were used:

Do usability testing – Usability testing is simple and effective.  Put your new site in a protected location online that users with permission can see.  Ask your approved users to do a series of actions on the new site.  Most importantly, ask them to speak their reactions out loud even if the reaction is negative.   You will hear and see first hand what changes you are making are good and what changes are perhaps not so good.  Here’s an online service to do usability testing that some of our clients have used.

Use focus groups – Find users who live within driving distance of corporate HQ, bring them in for pizza and project the new interface on the wall.  Start asking questions.  Take a lot of notes.  Repeat.  There is actually a methodology around focus groups, but an unstructured approach can also be very effective.

Prototype – Long before you code anything, create simple graphic mockups and email them to prominent users, bloggers (provided they are willing to hold their posts until launch), family members and employees.  Ask participants to email you their reactions along with any suggestions they might have.

Have a REAL beta! – Create a group of a thousand or so users who are willing to actively participate in a beta.  By “real” beta, I don’t mean putting out incomplete software for all users to play around on (gmail, your beta period is over!).  Let your beta users directly access the new site for a few weeks so they can get a feel for the workflows and functionality.  Provide a simple form for them to email you feedback.  Make sure you find users willing to try new features who will make the effort to email their comments to the team.

After reading about these various processes for gathering feedback, do you think that the developers at facebook might have been able to determine that users might have issues with the new interface?

If you want to avoid making similar mistakes, make sure that gathering and responding to feedback is an integral part of your development process.  Leave time in the schedule to make product changes.  One of the top reasons feedback loops fail is development teams don’t have time to address highlighted issues.

Let’s talk brass tacks

One of the top complaints about the new interface is that users are confused and often have to hunt around to find areas that should be easier to locate.  Some basic user interface elements might improve usability and decrease this confusion.  I have listed a few ideas below.  After all,  what good is pointing out issues if you are not going to offer solutions:

- Provide a consistent site wide bread crumb trail to help users see exactly where they are.   For example, how about showing something like Home > Photos > Albums > Napa Fall 2008 > Photo 2 of 18  on the page?  With a bread crumb trial , users can see exactly where they are and how to navigate back.  Some areas on facebook have a bread crumb trail and some don’t.  To be effective, this needs to be consistent and present everywhere.

- Provide site wide navigation that is always available.  Would it be so bad to have a menu bar or left side navigation or some other common control to access the entire site?

- Use labels and hints to help users understand what they are looking at.  For example, take the word “Highlights” on the home page.  How about a little helper text like popular updates from friends or something like that?  Labels with hints set the context for users and help reduce confusion.  I suggest reading Don’t Make Me Think by Steve Krug.  I had my own don’t make me think moment a few months back.

A real example – Events

Let me provide an example of what I am talking about using the Events feature.

I see more and more people putting birthdays into facebook.  Current birthdays shows up in the upper right corner of the home page.  I’ve never used the Events feature before and had thought these were just notifications.

On the current site, you have to click twice in that corner to get to Events.  That seems to be the only way to get there as Events don’t seem to belong anywhere.  I don’t see them in the menus or as links in other places.  These next changes would help users navigate Events, which would hopefully increase site usage as well as improve user satisfaction:

1) Put the label Events on the home page above the daily events.  This tells me this is an actual area of the product.  Heck, go crazy, even put small hint text like where you see birthdays or create your own events.

2) Provide general navigation to get to the Events area.  If you put them under your Profile, which may or may not be the best place, then have a sub-navigation under Profiles that lists Events and the other sub-areas that are part of Profiles.   This needs to always be available to users through the primary navigation I suggest above.

3) Show Home > Profile > Events when users go to the main Events page.

These changes reinforce Events is a feature and that it is located under Profiles.  Overall, users won’t feel as lost when they come to understand the layout of the site.

With a little bit of development process to support integrated user feedback, developers can determine the changes users want to see, which should in turn lead to a happier and more productive user base.

Filed under Development Management Tagged with , , , ,

Is 2 Months Reasonable to Launch? Or even Doable?

January 19, 2009 3 Comments

We see a very interesting pattern for launch dates in requests for proposals (RFP) that we receive. Nearly everyone who starts development from April to August wants to launch in October. The trends makes sense when you consider seasonality. The difference between April and August is obviously significant. Yet, companies seem to want the same amount of functionality regardless if development starts in April or August:

“Why can’t this be done 2 months? How hard can this be? Can’t you just use some open source products and customize them? We don’t need to start from scratch here. My expert says…”

Customers bring up many salient points during these discussions. Can the team work longer hours or can they work smarter? If a set of features requires 6 months to reasonably develop, can it also be done in 2 months with about the same size team? In this previous post, we point out that coding is physics and that we can’t simply reduce the schedule to meet a deadline.

Have you seen those home improvement shows where the contractor blows the schedule and the budget because of some unforeseen factor or change in the plan by the home owner? The home owner looks at a set of materials, imagines in his head the work to put them together, but never quite understands that it is never that simple. With software development, it’s the same principle. People look at a set of features and think in their heads, sure, this is doable in 2 months. They rarely consider that the implementation may not be as simple as they think, or that they might see the product and decide what they wanted is not what they thought.

Let’s look at a simple feature example of implementing sign-up and login. You can’t do much in a product if a user can’t create an account. An experienced developer using PHP or Java could do these features in a few hours by creating an HTML form and writing some SQL to add or look up a record. If features are that easy, why do we even need 2 months?

A good team thinks about the best way to implement a feature above and beyond the mechanics needed to create a form or put a record in a database. The developer must define a user object that has properties like email and password and functions like saveUser and validatePassword. The team must define objects smartly, otherwise you may have longer term problems maintaining your code base.

The page must be properly formated to match the mock-ups and overall aesthetic of the site. Color and font attributes are centralized in CSS files. If these are the first two features of the site, then the login and sign-up pages created will be the ones that define the styles for the rest of the site. Usually, the team needs a graphic or two from the designer as well.

The developer must also understand the client’s login and sign-up business rules. Do users login with email, login name or both? Must users validate their email before accessing the site? Should the developer check to make sure the email address is valid on input? We had 3 customers launch or hit beta in fall 2008 and each one had subtle differences in their business logic for sign-up and login.

You can now see how something as simple as sign-up and login might take a day to implement and another to test and validate.

With a new code base, the team must define the infrastructure of the code. Developers consider scalability, security, exception handling and a host of other services to make your product secure, robust and scalable. The best teams use existing technologies or frameworks to solve the infrastructure problems, but they still need to customize the code to meet specific needs. We no longer have to cut down trees or mill wood when adding on to your house, but we still need to cut the wood to size.

The good news about objects and infrastructure is that they both solidify over time and the effort to implement new features reduces. Economies of scale start to kick in once you have your solid foundation. You can hook into existing pipes when adding a bathroom on the second floor so to speak.

When you consider how much design work, object definition, and infrastructure is needed to create a scalable product, you just may find that 2 months is only enough time to get a small collection of features working. I told one client recently that after 2 months, the product will look like an unfinished house. Showing the product to their customers would be like walking on to a job site and imagining where the living room will be. After 3 months, you’ll see walls and after 4 months you’re painting them.

We suggest avoiding the 2 month launch for the simple fact that the best product comes from gathering feedback and re-thinking core problems, which is hard to do when the people providing feedback have to imagine where the walls of your hypothetical house will be. A development cycle of 6 months provides enough time to implement a robust feature set for launch, and to make improvements based on real feedback. This seems like a good idea to us. You’ll see this theme along with our predictions for trends in 2009.

My final point is this. If you launch with something that took you only 2 months to build, how defensible can that be if you happen to uncover the next new market like blogging, social networking, software-as-a-service or some new island in the Pacific? In 6 months, you can have something better, with more ingenuity and functionality, that has validation from your target market, and is not something a competitor could replicate in time to rain on your parade.

So back to the original question. Is 2 months doable? Maybe it is. Maybe, if we all stay focused and implement a minimal feature set, and if we don’t seek any feedback on what we created, it’s doable. But is it a good idea?

Filed under Development Management Tagged with , , , ,

Important Principles of Interface Design and Usability

November 12, 2008 1 Comment

When we design products with our clients, we seem to spend a lot of time talking about usability and intuition along with user interface aesthetics. You might be surprised at how many people focus primarily on look of their product and less on what the user is doing on the site.

My favorite example of usability gone bad is Amazon.com. Try finding your wish list or creating a new one. Try adding something to your shopping cart and then wanting to continue shopping in the same area you were at before. The only thing that says them is the usability of product search. But even then, the link to log in doesn’t even say log in. There’s simply too much focus on what they want me to do and not on what I am trying to do.

Take a look at these 3 legal Web sites quickly (10 seconds or less): Site 1, Site 2, Site 3. Waiting… Now, ask yourself, what do you remember? Don’t forget, you knew going in that they were Web sites having to do with law. I found one of these in particular that was clear and effective at communicating what was the focus of the site (do you know which one?). We often ask clients to send us links to sites they like to get a feel for their aesthetic values and design priorities. In the case of the law Web sites, the client walked in the door with one of these as an example of what they liked.

Web sites seem to be moving away from the crowded page like you might find on Amazon.com and moving toward the simple concept of “let’s get started.” This is a great trend. It worked pretty well for Google, if you compare Google to other early search engine sites.

Product interfaces should help the user answer 3 simple questions to be effective:

  1. Do I know what to do?
  2. Do I know what is going to happen when I do it?
  3. Do I like what I am looking at?

If your users are able to answer these 3 questions with a “Yes”, then you’ve done a great job. Let’s look at some examples.

Question 1: Do I know what to do?

If you compare www.avvo.com to www.nolo.com, you will see the difference between a site where the user knows what to do and a site where the user does not. Although, I think both of these sites could use a more informative name. Avvo has a search box in a prime location. The title says “Find lawyer”. I have no doubt than when I enter the name or location and click the button, I will get a list of lawyers.

Question 2: Do I know what is going to happen when I do it?

Have you ever really looked at the buttons on the Google home page under the text input field? You probably have not since hitting Enter works fine. Take a look and then ask yourself what does “I’m Feeling Lucky” mean. If you are not sure, click the button with an empty search field and you get a nice little explanation, “The “I’m Feeling LuckyTM” button automatically takes you to the first web page returned for your query.” How about naming the button something like “See first page” or “View first page found?”

Keep in mind that your users are generally trying to achieve something when using your product. They will feel more productive if they are focussed on that goal rather than clicking around to just see what happens. Use clear text for buttons that explains what will happen. Use text under icons to explain what the feature does just in case the user does not recognize the image.

Here is something you can try. Print your site, hand the copy to a friend who knows nothing about it, and ask them what the buttons do. You just may be surprised at what your friend is able infer from the image. We recommend of course that you fix anything they didn’t understand.

Question 3: Do I like what I am looking at?

Aesthetics still do matter. Function is more important. But after that, people tend to use products and Web sites that are pleasing to them in some way. I know that this is common sense. Surprisingly, from my own personal observation, companies that are really good at the first two points tend to fall down on the third. Which brings me back to our new partnership! Our teams work with clients to create intuitive work flows. And our friends at Luma are here to make sure the interface “pops”.

In addition to asking ourselves these questions, we also have some good tips to help with usability. Here are two of our best suggestions.

A great deal of research has been done with eye tracking to understand how people evaluate Web pages. Take a look at the blog by Eye Tools, Inc. The heat maps are very interesting. Another study to look at is done by the Poynter Institute in Florida. Click this link and scroll down to the section At the core: Homepage layout. We quote this information often when discussing design approaches with clients.

Eye tracking tells you where the user is most likely to look first. We suggest to clients that they put the primary focus of the page where users look first. You also use this to then determine where to put navigation, additional links, related information, etc.

We also own and reference several books by Edward R. Tufte. I recommend buying as many of these as you can, but be prepared for ideas that are part aesthetics and part design with hints of philosophy and history in between. What impressed me most was the power of data when presented in a way such that the images draw the conclusions. I am sure you will walk away with your own insights after perusing a few of his books.

Filed under Development Management Tagged with , , , ,

SMS vs. Pen and Paper

October 19, 2008 1 Comment

I realized something recently that using SMS for capturing quick notes might actually work better than pen and paper. To me, pen and paper is the most effective interface ever created. It is easy to use, intuitive, and the results of user actions are completely predictable. All these points are key to a good user experience. The notion that SMS could compete with the almighty pen was an interesting revelation that was worth noting.

I came to this realization while visiting my sister in New York. I was impressed with her latest life improvement campaign. Her focus and progress have been amazing, if typical of her. You see, my sister is the oldest in the family and the classic over-achiever. She was a stats major at Berkeley and became a senior partner in the actuarial practice (read mathematician on steroids) at KPMG. Therefore, I was not surprised by her driving progress, but what I found interesting was the key to her success. Her “coach” presented her campaign as a mathematical problem.

Can you say math geek?

My sister tracks her progress every day in a journal including the aforementioned mathematical process which she hand calculates. Can you see where a Web site would start to help? You leave your journal at home and need to record an entry. You do the same calculation every day which could lead to a mistake. You are tracking progress over time and that is something computers are made for. No brainer. Fire up Ruby on Rails and let’s create a startup.

But then, I noticed the true challenge in this scenario. Her journal uses the most intuitive user interface on the planet, pen and paper. So simple to use. Free from power supplies and foreign oil.

Damn you pen and paper! Mocking me as you sit open faced on the kitchen table. Damn you!

How many times have you read in my posts that I love simple and intuitive technology. GPS systems. Door knobs. And now, pen and paper. I was about to tell my sis that she was better off with the system she had when her husband pointed out something very interesting. My sister texts all the time. She has her Blackberry out at my nephew’s t-ball games. She reads email during meetings. She has her device open more than anything else.

Ah ha, the crackberry is mightier than the pen!

We quickly surmised that if my sister could capture her journal entries via SMS, she would have a more effective way to track her progress. Then, she would get the other benefits Web sites offer like historic tracking, search, automatic calculation, email reminders, and many other features we brainstormed that day in the kitchen in front of the demoralized pad no less.

Give that man a ribbon!

I am still mulling over developing the site. But truthfully, SMS to me creates a better user experience and provides a more effective tool for tracking then pen and paper. Writing a message is as simple as taking a note. Carrying a Blackberry now happens as frequently as keeping a pad in your bag. Capturing data via the Internet enables the many benefits of using computers to store data and manage processes.

Hurdle overcome, now what’s next? Oh yeah, if I could just capture some of her drive, I might have built the thing already ;)

Filed under Development Management Tagged with , , , ,

Users Really Don’t Want To Think, So Don’t Make Them

October 9, 2008 Leave a Comment

I am reading Don’t Make Me Think by Steve Krug. His book discusses an interesting philosophy for creating simple and effective interfaces for users. The basic premise is making users think too much is a bad thing. Makes sense to me. I recently had my own encounter with being made to think which helped me appreciate the salient points of the book. And from there, I had a better understanding for how to make my own projects more intuitive. This is something you should think about too!

In reading the book, I was struck by how much of a simpleton the author thinks the average user must be. If the user can’t reach a conclusion quickly, the book presents, he is more likely to move on than continue looking. Users won’t read a paragraph of content. Count yourself lucky if they read to the end of the first sentence.

I am a big fan of creating interfaces that don’t require the user to hunt or guess what will happen. But should I really design a site the does not force the user to think? Isn’t it insulting to users to assume their attention span is that short? That users are that impatient? Will I truly draw active users to my site if I target the lowest common denominator so to speak?

Boy was I surprised to find out I was in this very category of user. Here is my sad tale.

I live in Napa where I belong to a number of wine clubs. I agree to buy a predefined shipment of wine every other month in exchange for discounts and other benefits. I got the following email from one such club a few months back:

Your July Wine Club shipment is set to ship or is available for pick up on July 14th. For those of you scheduled to pick up your wine, please note that we will also send an email and post card to let you know that it is available at the winery.

I read the email and drove to the winery the next weekend, on July 6th, to pick up my wine. What do you think happened when I got there? They told me that my wine was not ready for pickup. How can that be, I asked, I got the email saying it was time. We brought up the above email. Any ideas where the mistake was made?

You see, once I read “is available for pickup”, I didn’t read any more. I assumed the rest of the email was filled with marketing fluff or up sell or something else unworthy of my valuable time. I didn’t THINK to read anymore.

OMG, I am one of those users who doesn’t think!

The real issue here is the email. The tense is all wrong. If they simply had changed the words “is available” to the words “will be available“, then I would have kept reading to see when. I get hundreds of emails a week that I have to process while doing real work. Once I know what the email is about, a conclusion I am forced to draw rather quickly, I take whatever action is needed and move on. Plus, sending me an email in advance is useless as I am not likely to create an Outlook reminder for something like this. Would you?

I spoke to people at the winery about the issue after realizing that I would not get my shipment. They indicated I was not the only one who had done this. They did not give me my shipment early while I was there, which to me is just plain bad customer service. You see, it was my fault not theirs, right? I misread the email.

What I can tell you is that Steve Krug, the author if this book, is right on the money. We are all potentially users who do not think. You should keep that in mind as you develop your software. I’d recommend you get the book and then see how your work measures up. You just may be surprised.

UPDATE: After publishing this post, I received the follow up email from the wine club that my shipment was ready. This email was received on July 9. Here’s the email:

Your June club order has been processed and will be ready for pick up on June 30th at the winery.

Once again the tense is wrong. How can they say my pickup will be ready when the date referenced is in the past? Plus, if it was ready on June 30th, how come they didn’t give me my wine when I was there on July 6th? Truthfully, this is the downside of making users think. If your force them to really think about it, maybe they will conclude something other than you expected. I think I will email them and tell them to just email me when I should come over. Think they will listen to me?

Filed under Development Management Tagged with , ,

Follow

Get every new post delivered to your Inbox.