Engadget Uses A Visual Scatter Gram To Display Articles by Comment Posts

To begin with study the image to left or visit engadget.com. If you notice “the daily roundup” consists of  a dot representation by hour and volume of comments per article. In this interesting approach a large volume of data is depicted with minimal space. To an avid reader of the site it may not be of much use, but to a casual reader it can help them quickly pinpoint hot topics of the day. And for us multi-tasking tech geeks that is a time saver.

As your move your mouse over the dots a hover tool tip displays revealing  the article name, date, and number of comments.  As it is difficult to pinpoint a single dot on the screen a larger transparent circle displays around an area if the mouse pointer is on top of dot. This is important because a large cluster of data points can really cause usability issues with data overlapping.

Are there problems with this experience?

B. My design revision: includes a further display that gives each post a popularity index rating.

Based upon my own experience this type of interactive info-graphic can be misleading if you are using it solely to gauge what topics are the most important. Certainly there is something to say that the more a topic is commented upon the more people that have seen / will see the topic.

As my mind is constantly analyzing and investigating anything UI related  I started conjuring up a different  solution that could balance both popularity of comments versus the actual views to better depict important stories.  One possible implementation I arrived at involves adding some more visual data representations to the mouse-over event to form another type of chart. [ See my design idea illustration B.] In this design thee comments of an article are correlated with the page views to arrive at a popularity index. This could further be refined by defining page views as the click + total duration greater than 1:00 minute on a page.  This way we can eliminate any false data due to users visiting and leaving the page quick.

There are a lot of different ways this could be designed and developed and expanded. Most of the decision is going to depend on the audience your design is aimed at. When we look at this designing a complex UI to be simple  you really have to ask yourself  ”Is this just neat or is it providing benefit to my user base.?”  Neat is great and cool if your audience appreciates the cool factor,  but don’t get carried away or you might end up loosing users as opposed to gaining them.

Related articles:

1. UI Design Challenge: Redesign A Filter Widget
2. Book Review: “The Visual Miscellaneum” – Explore The Design World of Infographics In Only A Few Moments
3. UI Design Challenge: A Table or Grid With Too Much Information

Even today UI designers hear the word AGILE and there mind is flooded with demon visualizations straight out of Dante’s Inferno.  Why has this methodology caused so many headaches to UI Designers world wide? Why are they terrified? Can we beat them, or should we join them?

Generally speaking 90% of what a UI designer hears about AGILE comes from an AGILE practicing programmer that has succumbed to the second circle of hell and revels in the fact that you must join them.  Let’s face it as UI, Usability Specialists, Graphic Designers, etc.. we work in a different creative zone. A zone hard for many developers to understand – Even if they want to understand.

Well, that’s about to change as I finally delve into some secrets of success. Rapid UI Design is not easy, it’s usually far from a “done” state, and even in a perfect world, the time to refine and refactor both your code, interactions, and design is hard to come by. In order to survive and thrive you need to look at practical solutions and solve real problems with the process itself. In order to truly excel you need to replace perfectionism with iterative perfection.  You need to find a way to be a time traveler amongst all the chaos. You need to turn hell into paradise.

Cue flashbacks…..

Imagine it’s your first day on as a UI designer in a company.  You are super excited to work in this vast field only to have your boss tell you.

Boss  ”We work in a 1 week iteration agile development environment. ”

At first you may panic, you may want to quit. You may not even have a clue what Agile means . All you know is that you were hired on your UX skills and your damn awesome portfolio. You are still a bit light in the experience department, but are self-motivated and driven by a passion to create memorable, exciting user experiences. You have spent hundreds of hours refining small personal projects, none of them were quite near finished and you always had more time. Even fresh your college professors gave you a generous amount of time to come up with the perfect solution.

You  turn towards your new boss and ask the simple question. “What does being an Agile UX designer mean to me?”

Boss “We try to build something quick and let our 200 users test it in the field, we then iterate and make refinement to the functional and design elements of an application. And by quick, I mean rapid development & rapid design.”

Now the sweat starts to build as you think to yourself? What the hell have I gotten myself into? All you know is that you can create semi-decent sketches of vague application functionality, but over the course of a week or longer. Time is your enemy, speed is your weakness.

Your stress level and blood pressure begins to rise.  You start to frantically gasp for air, the questions racing in your mind.

• How can I produce something that will immediately be built into a functional application.
• What about my training in persona usage, usability testing, card sorting, etc…?
• What about multiple sketches for each application path?
• What about refinement time?
• What about missing user stories or requirements
• What about running out of time?
• What about failure?

The questions just keep on coming as your pulse races. And then the boss chimes in.

“We know it’s hard work, but we know our audience well. We have daily SCRUM meetings, and have a direct channel open to our clients and customers. Our work flow is continuous. You’ll do just fine.”

As you stand there awestruck you are thinking  “No…No I wont.”

Fiction Takes The Form of Reality

The preceding story was not fiction it was true story. Imagine you have 1 day to develop a new major application piece. You need to be able to quickly move from ideation to sketches, to wire-frames, and you have a deadline of tomorrow morning? Add on the fact that a large number of programmers are waiting on you? What do you do?  At the most, you may get out two different designs. This my friend is how the fast paced world of Agile UI design works. Don’t fear it, but don’t let the process control you. (I’ll talk about this in another article).

There are several key factors that will help you tame the wild beast.  Take a breath and let’s start to look at making the chaos manageable.

If you are one of the lucky souls that works on a well structured UX team this process becomes a bit easier (future article Architecture of a UX Team), but if you are a UX Team of One. There is a good chance you just messed yourself. It’s hard to  imagine adding on even more roles to an already overloaded work schedule? Estimating time management, researching the problem, defining the problem, identifying primary and secondary application functions, sketching rapid paper-prototypes, understand stories (AGILE), Understand complex work flows, Refining the design, Gaining Buy-in, More Sketch refinement, and ultimately the next day ready to program. Wow! If you have ever experienced week AGILE iterations then you too might have felt this pressure.

So let’s take a look at this EXTREME situation first and then in future articles talk about refining the process itself.

Help What Should I Do First?

For this article lets imagine we are building a fictitious site called “babyspace” It’s a place for babies and is used to track developmental growth (I actually will cover this in another article as well from a design perspective.).

Step 1:  Ideation & Brainstorming

You want to begin where you excel and that is brainstorming. Use a whiteboard, paper, napkin, toilet paper, whatever you use but make it fast, but also make sure you keep a copy. (I recently purchased a Livescribe pen and keep all my brainstorming sessions in there with recorded notes. It has helped me remeber the most intricate details of a brain storming session and saved lots of time.)

Hopefully, while you are doing this  the business or you yourself have gathered up user stories (small chunks of functionality), and prioritized these.  From the stories you need to figure out what relates to the user interface. Take notes and jot down tasks where you see a UI component being designed. This is going to help you immensely when you go to a Sprint or Iteration planning meeting. You want to be armed with as much knowledge as possible in both function , form, technology and design ideas.

Step 2:  Ask The Right Questions, Who Needs What? Why Do They Need It? How Does This Benefit Our Users?

Do notbe afraid to ask questions. If you need to refine either your user stories or clarify your own UI tasks. Do it! Sometimes it’s easy to miss a crucial detail when you feel the clock is ticking.  It’s better to get as close to the right answer before you start, as opposed to after you start. It’s not fun to rip apart a fully designed application or UI because a crucial story element was missing (Keep in mind this is different then actually refining your UI each iteration).

 As a UX designer you want to know these questions so you can put yourself in the shoes of your user. If you utilize personas you want to match up your personas to these user needs and desires (preferably several weeks before the project begins).  Always, Always, Always ask the following question:  

How is this is benefiting our Customer ?

When a team looses sight of this redirect the conversation. I highly recommend asking this same question of your team in different ways.

“Why would a user need to do this?”
“Why would persona A care about this?”
“Is user really going to have a need to do this?”
“Does this make it easier for our customer?”

Restructuring and rephrasing your question helps to get people to notice the different sides of a story or requirements. It helps to draw out those that talk to much in a meeting and those that don’t talk at all. Engaging and intriguing questions will save you time.

Stay tuned over the next few months as I roll out Part 2 of this article. We will continue to cover lots of other tips and techniques, as wella s more of my process. Soon I’ll be able to notify my readers if my panel (core conversation) is choosen for the 2010 SXSW conference.

Related articles:

1. UI Design News: Vote For My Agile UX Panel At SXSW 2010
2. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?
3. Agile UI Design Series: UI Design in an Agile Project Cycle Part 1

Employee v.s Machine

Initially, an employee walked us through and showed me the usage of the machine. While my friend stood by and casually joked
“Does the food come out the back?” They all laughed. Personally I thought that would have been awesome, but no they still have to cook it. All the while I was thinking here we are 2009 and no Jetson’s technology yet, oh well. And now back to the topic at hand.

The Interface

The interface was quite pleasant to use. The initial screen had very large buttons with images depicting the various type of food categories. Each touch passed you through to the next round of choices. After studying the menu on the wall I decided I wanted a #6 combo. I noticed the image button with white and black outlined lettering with the word “Combos.” Easy enough so far.

As I proceeded onto my next select the system spoke very loud and let me know my current location (bread crumbs may have helped here). My design brain kicked in at this point and I thought. Awesome so far this system seems to be on the right track, let’s see what else it can do!

I next choose my combo size which the system graciously suggested three size options. I choose “large”, and was asked to choose a drink followed by my side item (free curly fry upgrade for using the system? Hell, yeah that’s incentive!)

Now came the true test, the system presented me with two buttons on the bottom Pay – Customize ( I’m not sure of those were the exact names because I’m trying to remember the system).The employee kindly showed me how to customize the order by touching a “customize” button.

I have sketched out this part of the UI from memory because, I only decided to examine the UI after the fact. Essentially, I was presented a screen with the items I ordered and a scrollable list that allowed me to choose 1-4 options for each of the items on my hamburger. I found the mustard option and set it to none and then clicked “Pay now.”

I was then presented with 3 buttons credit card (no debit card?), cash, and one more which escapes me. And since there was a ton of available real estate on the screen I thought these buttons could be even larger, and the addition of an arrow or text could point towards the actual manual interface options on the machine. In this case the credit card slot.

I proceeded to swipe my card the “wrong way”, like so many of us do. (Perhaps someone could build a better system for swiping cards – double strip maybe?). The ticket then was manually handed from the employee to the person cooking the food. I believe this was simply an issue that the machine wasn’t fully integrated yet with existing point of sale systems at the store. It was odd to have the order ticket handed to the back, but oh well. Next thing I knew my purchase was complete.

The Experience

To my surprise a lot of things went right. The system was friendly and the voice cues left me feeling confident about ordering. I was moved around the screen without issue, and even if the employee wasn’t there I still believe there would have been a fast and rapid transaction.

The UI never left me guessing if the previous selection was done correctly. This was especially important, since I had a pre-conceived notion of what my experience would be like. And like any other user experience that is a tough roadblock to get over.

The customization order screen was clean, not cluttered only showed me the options I could configure. Had I struggled at any point in this process. I would have probably never used this machine ever again.

Many of us have experienced or designed systems that attempt to automate the human interaction and fail miserably. This was not the case with this system. I actually believe I could order faster over time. Jack in the Box could even take this process to a whole other level where the system could recognize your name login ID or something and you could have a one button order of your favorite food. This is actually one of my favorite options on my ATM machine. It saves time and thought.

A Designed Experience With Thought

Let’s face it, the lunch crowd is probably the perfect audience to try out this machine. The only reason I felt guilty using this machine was for the simple fact that it does such a good job. A better job then other automated systems that have been around longer.

How many times have you been trying to race out of the grocery store at the “AUTOMATIC” checkout line only to be thwarted by this “friendly messages.”

“please place the item in the bag.”
“please wait for attendant.”
“please put the item back on the scale.”
“your coupon could not be scanned” (yep happened today)

When it comes to these grocery store touch interfaces it’s about a 50% satisfaction rate for me personally. I would much rather wait in line because the machine just usually ends up telling me to “wait” for human interaction to solve my issue. Beyond that how hard is it for the store to build in extra space so you can have room to put your groceries. Just like in any interface you don’t want the “ERROR: You Are Stupid.” to pop up on the screen.

The next time you are at the grocery store using the automatic checkout. Take a look around and see how many people it takes before the designed interaction of the system fails to produce the required user response. In fact, take a look at other touch interfaces around you and see what their failure rate of failure is.

Conclusion – Cheeseburger Harmony

Jack in the Box put some thought into this design, or at least hired a company that did. And that my friends is what a well thought out interface does.
This is the experience you want all your customers to have. And any UX person worth their cost should know that slapping a UI onto a product, application, etc… is just going to bite you in the ass.

In the case of J&B the return was not only well thought out but delicious.

Related articles:

1. Blog Response: What’s Your Design Sign?
2. How Can I Speed up Proto-typing & Visual Design Mocks with Hybrid Design Proto-typing?
3. Book Reviews: Neuro Web Design What Makes Them Click.

When you examine say Norton,or Adobe products, the consistent design allows the user to quickly locate and find your way around other different tools in the suite. Furthermore; if you are going to push a consistent product brand your design needs to fall within the expect mental model.

If a stop sign said GO would you know to stop? If the color changed would you know to stop? The same is true for your application. If you as the UI designer changed your cancel and your ok buttons around, would the user be able to predict the next screen interaction?

In the end it comes down to the customer experience. Yes, you still want your application to have that “wow” factor, but don’t sacrifice the “wow” for the now. That is to say don’t interrupt me by changing something I’m used to. And if you DO MAKE ME THINK. You better make damn sure the application is and will continue to be worth my time and money.

Fighting The Brains Trained Responses

Take a look at how hard Bing is working to remove the image of google from our heads. When you think search most users automatically think GOOGLE.  When you think Tissue most users think Kleenix.

A consistent application UI can be a powerfull tool when trying to associate your interface with a particular word or phrase. Attaching an easy to recognize and predictable interface is your key to promoting your brand. Without it your just holding up a green stop sign.

Related articles:

1. Blog Response: IE 6 The Devil Not In Disguise
2. Blog Respose: Bowman Leaves Google
3. Blog Response: Do You Love Wireframes?

The quick summary is this. He left because of design V.S. engineering issues. The article goes on to talk about the almost obsessive need to validate and back up every design decision with statistical data. While it is true that design does have a logical component a lot of how we precieve design varies from person to person. That is why it is necessary to hire a person with experience and knowledge of fundamental design principles.

From the blog post Bowman goes on to say:

Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades of blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case. I can’t operate in an environment like that. I’ve grown tired of debating such minuscule design decisions. There are more exciting design problems in this world to tackle.

I’ve been in this boat more times then I can count. And while most of the blogosphere is jumping on these statements as being the reason for his leaving. Personally I believe  it was a series of design by committee driven ideals that pushed him out the door. I’ve been there, and sometimes you just don’t want to fight the battle any more. This is especially true if you have constantly fought about the same issue (s)over and over again. IE: This color is wrong, This should be an image, I want sound on my homepage, etc…

When Is Enough Enough?

At what point do you either a just not care, or b continue to fight and push your own insanity to the breaking point. As UI designers we fight these challenges every day.  It is no easy task and sometimes only your passion for exceptional design can get you through the next day, project, or year. 

In one way it is comforting to see that even huge “cutting” edge companies fight and struggle with these issues. In another way, it is sad to see design and aesthetics reduced to a mere algorithm. This is especially disheartening when you are considered the expert and were hired for your skills, experience, and love of great design.

No one can work in an environment where they are praised for superior skills one moment and then second-guessed the next.

when I have worked with teams of designers and lost one of the flock it can be morally crushing. This is even more so if the reason for the team member leaving is due to design difference. In the case of google it appears machine v.s. man has won this round.

Related articles:

1. Blog Response: IE 6 The Devil Not In Disguise
2. Blog Response: What’s Your Design Sign?
3. UI Design Dissection: Google Reader What Makes an Application Great?

IE 6 is a demon that still won’t go away. Sadly, I still have to make my time sacrifice to the demon. I can only hope that Google Chrome will solve IE 6 issues sooner so we as experience, web application, and web designers don’t have to suffer through the tortue and pain of a relatively new browser on the scene.

Related articles:

1. Blog Response: What’s Your Design Sign?
2. Blog Response: Do You Love Wireframes?
3. Blog Respose: Bowman Leaves Google

Let me back up a little and begin there. The other day I was driving home from work and recently started  on a new UI project. I was going through my normal routines  when presented with a  project.
I start to ruminate over all the things I can do and how all the various functions of this new application would tie together. As I pondered this in between paying attention to traffic and driving, one core question popped into my head. A light bulb snapped and thus this article was born. I realized just how many designers, and developers, forget to ask one magic question.
Maybe they are strapped for time, burned out, or whatever the reason might be. You need to ask yourself this question!

Would I use my own application?

Would  I use this application. At first glance it is such a simple question but extremely valuable and woven with complexity. By knowing the answer you begin to discover unknown paths, problems, and practical answers to otherwise obtuse solutions.

Frequently, when I’m working on a new application with a development team I have to stop them a minute and get them to think about what we are trying to build. Not from a developer, QA, BA, Interaction Designer, UI Designer, System Architect, SQL Developer, perspective but from the person using the tool.

Walk A Mile In My Application

I like to think of it this way. It’s easy to make a pair of shoes, especially if you don’t have to wear them. Nails can stick out of the heel and the fabric may be torn. I still get an A for effort right? WRONG!

Another comparison would be just like the athlete who advertises how great a product is then turns around and uses another instead. Wouldn’t you as a user / consumer feel cheated in some way?

A true life example recently involved a function and feature for inter-application navigation. The feature was supposed to allow the USER to quickly change between editing different individuals’ information.

“A user could quickly change between various people and edit them rapidly.”

It sounded like a safe idea on the surface, but here is where the problem existed. We started by examining all types of ways to make this feature work and be non-confusing to a USER. I tried chunking the information, grouping it in different ways, larger titles, more prominent text. No matter what was tried in the current framework it was still extremely likely for the USER to get lost and more importantly loose the context of the initial task they were trying to complete.

Should We Design for the Sake of Design?

So I sat back a while and thought about the problem. That is when the answer hit me. Why? Why are we trying to let the user do this? Why were we trying so hard to fit a square peg into a round hole? Of course, every group had their own answers:

• Developers – “It would be great if a USER could manipulate the data quickly.”
• QA – “It works and does not break functionality. What is the problem?”
• Business Analysts – “The user should be able to do this function (but why?)
• Interaction Designer – “There must be a solution to this to make it highly usable and fit into the requirements.”

Now let’s back up a second. What about the task itself? Why would a user care about editing multiple individuals quickly? The quick untested assessment was “Users sit down and want to edit multiple people at once.” That was the expected reality but taking a step back and analyzing the task step by step the team discovered that there was absolutely no need for 99% of the users to do this task. They just would not use this system or this feature in the way it was envisioned. If I was editing an individuals information it was because I was either:

A. Talking with a customer recently and discovered changes to this information
B. Made a mistake when entering information and wanted to correct the information.

In either case we had other methods to handle these scenarios. What we didn’t have is a way to mass edit a single individuals information (usability and focus group testing should be conducted to figure out if that is needed). No matter how much everyone wanted this feature we really had no need for it. It was cool but as you read in previous articles that is not enough to justify its importance in an application.

So when you are developing or building a new UI. Ask yourself these questions:

1. Would I use this application (feature)? If not why?
2. What are the tasks the user is trying to complete?
3. Are there too many tasks complicating a single workflow?
4. Does my UI or application framework have enough flexibility to support these new functions?
5. Have I been consistent in my UI framework?

So ask the question and challenge the team to give the “why”. Why are we building this application? Why should we build this application? Will our customers or more importantly will I use this application?

Related articles:

1. Corporate Conflicts A Cantakerous Cacophany of Confusion.
2. UI Design Lessons: A UI Designer in an Agile World, Get Me Out of Hell! – Part 1
3. Agile UI Design: A Fundamental Miscalculation in UI Design Excellence?

Usability is nothing new. What is new is the use of the term usability by anyone and everyone. It has become the de-facto buzzword across the design world. There are so many definitions and differences of opinion across the web on what usability actually means. Let’s take a look at the dictionary definition:

Websters defines usable as the following:

1. capable of being used
2. convenient and practicable for use

As UI designers, we draw upon a few more concepts to define this idea further. My personal definition takes into account the following:

• Learn-ability
• Memorability
• Performance
• Expected Interactions
• Consistency
• Repeatability

Yes, I know that’s a lot of “abilities”.  I will discuss this in future articles,but right now let’s just focus on what falls into the category of usability from an application standpoint and how it can directly impact adoption of our application.

Here’s A Feature, There’s A Feature, Every where’s A Feature

Many notable UI Designers, Interaction Designers, and User Experience Designers have talked about the problems of “featuritis.” The term simply refers to the rapid increase of features beyond either application need or user desire. This can occur to almost any product you can think of.  The goal is to minimize and avoid user frustration by understanding what it is the users really need. After you have identified what is needed it’s important to categorize your features, functions, etc into primary and secondary interactions ( I will talk more about this in a future article.)

Even The Best Applications Have Skeletons In The Closet.

Let’s examine some existing products on the market and identify some problems with these applications. Im sure many of us have used Illustrator, Photoshop, 3dsMax, or Bryce. These applications have a high user competency. You may need classes, formal training, and many years of experience to produce professional results. That is not to say these companies have “driven usability off the cliff.” In fact, many follow the same “menu” toolbar structure seen in 100’s of applications. Each application may have their own slight twist and or added access to complex functions. Regardless, there is no doubt a very important process has taken place at some point during the development of these applications to priortize the location of menu features. Hopefully, this process involved usability groups to actually figure out what the priorty was.

Take 3Ds Max for example. 3DS max is aimed at highly competent designers with modeling, mathematical, computational, and visual skills.  One version of 3DS Max I’ve used contained many complex context menus with alternating functions to complete as expected complex design modeling tasks. Personally, I’m glad I’m not a 3D modeler working with Max or Maya. The interfaces may be some of the most difficult UI’s I have ever encountered. Multi-Tiered cascading menus, complex keystrokes, and alternating views of wire-frames.

Let’s take a look at Photoshop. Pretty much every designer I know has used this behemoth of an application. The sheer power of the tool led to a lot of acceptance of any short comings. Yet, with the creation of CS 3 Adobe redesigned many core menu structures. One simple example is the tool bar that can now be set to a single strip along the side. This was one of my pet peeves. I would frequently run into the tool bar constantly being in the way. This small change (to the user interface) has saved me many minutes of productivity, and eliminated a major annoyance.

We The Users Will Not Stand For UI Mediocrity

Alan Cooper’s Book “The Inmates Are Running the Asylum“-(published in 1999)  talks about the complaceny users of software faced when working with web applications. of course, it is now 2008 and a more recent study by Jakob Nielsen points out that users have lost thier patience. No longer will users stand idly by and wait for that 30 second flash splash screen to load. Poor UI designs and convoluted interfaces, face a growing demand to be made better. It’s our job as UI designers to improve and invent new and easier methods of interaction. If any feature proposed as a usability enhancement fails it is much easier for users to swich prdoucts.

There was a time in the past when humans were pleased by simply improving complex processes with the use of a computer and software. The novelty has worn off, and now users expect much more out of the software they buy.

Think back to the last time you waited for a web page to load. Did you wait patiently? Maybe you tried to click faster in hopes the page would load faster. If you are like me, you simply go to one of the billion other web sites.  It’s reasonable to assume loyalties will shift and applications that fall to the road-side and allow usability to suffer will ultimely loose users.

The Dreams That Dreamweaver Dashed

For many years I was an avid Dreamweaver user. The tool allowed me to code faster than notepad, and did not overwrite my code. Adobe became comfortable with it’s lead on the market and the tool never really pushed the bounds of innovation.

Each subsquent upgrade lead to more features, but what I really needed now was a tool that could read my complex CSS style sheets and visually give me a good in program rendering engine. This would allow me to not have to constantly switch back and forth to my browser to check my designs.

So after years and years of program use I switched to Expressions Web. The CSS rendering engine was  amazing. Sure, it was an entirely new interface to learn not to mention Microsoft’s insistence this was not a FRONTPAGE tool but instead was directly aimed at professional designers. I hesitated making the final switch, but haven’t looked back. That being said now Expressions is falling behind on delivering the best software experience. I may have to take a look back at Macromedia.

Don’t let your software and usability become a fat pig. Conduct usability groups and determine where to go next with your application. When you have your list of features be cautious.

All Features Are Not Created or Treated Equally

Imagine you are in the market for a new luxury car. The list of features reads something like this:

• Power Steering
• Anti-Lock Brakes
• Rear View Mirror Camera
• Internal GPS
• IPOD Connection
• Stereo CD Controls
• Cruise Control
• Defogger
• Air Conditioning
• USB Ports
• Extra Outlets
• Block Heater
• Light Panel
• Spare Tires
• Microwave Oven

This is a top of the line luxury car. It has items you may never need. The engineers believed it was best to have two spare tires. One attached to the roof, and one in the trunk. They reasoned with the manufacturer that because of all the extra features the tires are not the best quality, but we did get all the features in. Occasionally, the operator of the vehicle may turn on the brights when adjusting the radio. They may short out the battery if too many items are plugged in to the outlets. They may burn fuses, but “everything” asked by the car manufacturer was included. Some pieces are less reliable then others, some have some major bugs, some even may cause system failure.

You may laugh at this example, but sadly it is very true. So many times features are the prized cow at the fair. They are the desired outcome of a super speed, fuel injected, development cycle.

Now let’s fast-forward a week later to the purchaser of this vehicle. His initial reaction was WOW it offers me all of these things? That’s a lot of stuff. Sure I may not use many of them, but oh well. I may need them some day! (just what the engineers, and developers wanted them to think). In The past they would have drank the kool-aid! OH YEA! Today that car is going right back and guess who just lost a sale and millions in investmetns?

The next time you want to jam that feature or expand that application. Stop! Think a moment about what the cause and effect will be.  Not to just the current implementation but future expected implementations. You may just prevent your application from careening off a cliff!

*Author’s Note – Due to the size of this article I was a bit late in publishing.

Related articles:

1. Features In The Front Usability Get To The Back
2. UI Design Series 1: Web Application Design Where’s The Vision? What’s The Value?
3. Design Lessons: Should You Rush Your Design To Market or Stall it for Great Design?

Well, one method is this blog. That is one of the reasons this has been put out here. So here is the first design challenge. We don’t have many readers yet, but I have faith! Think of a complex design that you had to break down into an easy to use web application.

• Why was it considered not user friendly?
• Was the applications activity fully understood?
• Who was the user base?
• Was the technology proficiency of this user group under or over estimated?
• What do you think was your #1 reason for failing in this design?

My most recent experience is with an account application. I knew after spending over 15 different screen mocks and numerous in person sessions that the design was overly complex and we were trying to do way too much. I voiced this, but eventually just gave up under the weight of pushing the application through development, Quality Assurance, and into demonstration mode. I should have pushed harder, but so many voices were in on the design that it took on a solid form and any variation outside of what was deemed “approved” was not really up for debate. So I pushed on with the design knowing full well it could be better.

As it turns out the design was even complicated to implement programmatically. It was obvious that we had to take a radically different approach to this design. The business wanted to include so many features and I knew from my experience the usability of the application would suffer. After numerous issues of real internal users trying to use the application that had never seen or been involved in the intiial development. It was quite obvious that we needed to take another crack at it. So I came up with another 3-5 hours worth of designs. I was still adhering tightly to our existing model because code had already been written and we didn’t want to toss it and because we had to stay inside our approved design model and within the timeline. On this second pass, or maybe it was third I lost count. The same initial problems were maybe cleaned up a bit but within the existing framework there was not enough outside thinking to turn the app around. Features that were determined to be core feature sets were insisited to remain. Even though I felt how feature bloated the application was I could not make a dent in radically changing the design from what was the pre-concieved and accepted design.

I hope to someday go back and redesign this application, which probably currently only has an adoption rate of 1% users. And that adoption is not because of usability but because of shear necessity. That’s probably the #1 thing you will hear from developers and programmers it works! Working isn’t good enough, especially when you want to have pride in your design and the ability to make the task it was designed for quick and painless.

There were several reasons this design failed. The activity for which the design was built for became way to large. It was imposisble to account for every scenario even though the mentality was that we needed to. We should have focused on the the top 2-3 primary activities and make the application do those like a pro. Any other functionality should have been carried by the main application and not handled within the management. I knew this from the start but couldn’t get the dreaded buy-in I needed. And in a corporate environment buy-in is the key to getting your voice heard. Eliminating those less important features would have made the User Interface extremely flexible.

Another downfall revolves around the understanding of the primary application goal. My understanding became so muddled as we added more functions and features I started to loose site of the users and what they would be doing. I was trying to balance the primary features and elevate the lower level features as high as the primary application function. This caused a complete blurring of what the whole product was meant to do. And more importantly what path the user would take to complete task A – Subtask B – Subtask C – all in hopes of reaching end task F. Then repeating this cycle for another user. That looks complicated just reading it in text!

So please feel free to share your stories and info!

Related articles:

1. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?
2. The Haves, Have Nots & Feature Bloated User Experience.
3. The Most Important Questions to Ask When Building A Web Application UI.

Feature List That Needs To Exist On New Book Add Page:

User Needs:

• to add a new book in rapid succession
• to delete a just added book
• to Edit The New Book Entry
• to create new book categories
• to add reviews to the new book
• to maintain a registry of who has original book copy
• to search for books
• to manage categories
• to manage users

Now it’s quite obvious that some functionality may be used 1% of the time. And thus begins the battle between UI designer and business analyst or the client. The number one problem I have faced personally is unnecessary features in non-logical places. A virtual Swiss army knife. They client or BA may want a Swiss army knife, but what does that really mean. Well, if you have used a Swiss army knife you have to remember where all the tools are, and pull up the right tool in the right sequence, while making sure that other tools don’t get into your way. Basically, you have to find what you need by memory, or worse luck. Think how easy would be if you needed a knife and you had a pocket knife in your pocket and that’s all you had.

The same is true with our development process. Why should we put 20 features into one application process, path, when they may never be used by the common user. Couldn’t that time be spent on other application development cycles. Things like speed improvements, or gasp improving and revising your existing UI.

The hard sell in corporations and even to a client wanting you to build an application is the concept and mentality that “more is better.” Our application can do 50 things! What we fail to illustrate or tell is: it’s confusing as all hell to use, only 1% of our user base are advanced users and they might use more than 10 features in every given application usage sitting.

What can be done to convince these non-designers, non interaction developers, that more is not better? That tossing the usability out the window, or just tacking it on at the end is really not good enough? There are a few ways to do this and one way is to just let it all hang out and see what happens. Let the application go live and then learn from the failure. In a corporate environment you don’t have that luxury unless you hate the people you work with and you may.

Excluding the option above you need to find a way to convince these other groups that usability and the design of the application is more important then adding 50 extra features that 1% of users may use. So how do you do that?

Tune in later as I examine more on this topic.

Related articles:

1. SXSW Interactive 2008 – Day 1 March 7, 2008
2. SXSW 2008 – Day 2 Summary -
3. UI Design Lessons: Are You Driving Your Application Usability Off A Cliff?