Why Did My Design Fail Miserably and Other Not Nice Things?

So as I was laying here sick in bed and thinking about design stuff. That’s the great thing or a curse about having a design based job. Even while you are sick you can’t always turn off your brain. So unless asleep or staring at the tv you are always thinking.

So the concept I was pondering this evening was design patterns and innovating existing user interface design patterns and widgets. I think web designers and user experience designers tend to fall into a pattern. “My ways are the best why change?” I know this has been the case with myself. I find it easy to fall into my design mantra. Constantly justifying the re-usable controls, grids, design parts and pieces as all of a “consistent” design. That is the trap! Limited time to come up with a new design before moving onto a new project just makes that trap even more self-fulfilling. Now that the trap has been identified how can we escape it?

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.
4. UI Design Dissection: Jack in the Box Self Order Machine
5. Developing an Effective Corporate Social Community with Baby Steps – Part 1