The Black Sheep of Application Development

Summary: If you’re a UI design professional, then you can probably relate to the way UI designers are usually the outcasts in most application development projects. This article draws from personal experiences and the ways that these common UI issues were dealt with.

If it’s not “usable” then what’s the point?

Sounds simple, yet the idea of focusing on making an interface usable continues to fall to the bottom of the barrel when it comes to the priorities identified in most application development projects today. Many projects start out with good intentions and agree that the application should be easy-to-use, in fact, often times making an easy-to-use application was the entire business driver behind getting the project started in the first place. The irony lies in the fact that the tasks involved with making a usable interface are usually the first to get ignored, de-emphasized or cut. The next to get cut is QA/Testing…but that we’ll save for another article.

Since most application development projects are managed and executed primarily by Information Technology (IT) teams, the project’s priorities are usually focused on developing functionality that “works” according to a set of Business Requirements and Use Cases. This approach can be characterized as a “system-centered approach”. The primary flaw in this approach is that the User Requirements are often left out and never defined. The User Requirements help the entire project team understand what the user’s needs really are and how they will perform the tasks driven by the Business Requirement. For example, a Business Requirement may define the need to capture product data into a database, which can be accessed through a web browser. The User Requirements may define how a user will enter the data using annotated wireframe mockups.

There’s a lot of research coming out now verifying that companies have invested millions of dollars in developing and deploying applications and websites only to find out that their end-users are struggling to use them. The unfortunate part is that this colossal loss of ROI could have been easily avoided by utilizing a more user-centered design approach in the development of these projects in the first place.

The bottom line is making something “work” is never good enough. Making it work and making it usable should always be the goal. Throughout the years there have been countless examples of products that have failed not because they didn’t work but because people could not figure out how to use them. For example how many VCR clocks needed to blink before they finally redesigned the interface to make it easier to set the time? Of course, if you couldn’t set the time you couldn’t record a show – so one poorly designed feature can impact another.

Where it all began

Since the beginning of software development, creating a usable interface has always been a point of contention. Before the Internet boom, and the wave of web-based applications that followed, technology teams developed green screen and client/server applications with limited UI capabilities and design freedom. These limitations caused many development teams to overlook the need and importance of including UI Designers in their process because the perception was that there was only so much “designing” that you could do. Unfortunately, it appears we are still struggling to find a new solution to an old problem. This lack of focus on UI design has been further compounded by the dramatic increase in demand for web-based applications.

During the Internet boom, developers became a very hot commodity because they were the only ones that could get companies up on the Web and develop revenue-generating applications. During the late 1990’s developers were demanding $200 to $250 hourly rates and some were even getting professional athlete-type signing bonuses. What this explosion of supply and demand did was establish the groundwork for having IT departments control and own most web-based application development projects. This ownership is exactly why most application development projects utilize a system-centered approach versus a user-centered design approach today.

House Construction Vs Application Construction

If you compare this system-centered approach to the common house building metaphor it would equate to having you go to the construction workers to build your house first instead of an architect. The reason you need to go to the architect first is to design the house that “you” want according to your needs. It’s not that a team of construction workers couldn’t build a house without an architect. Sure, the house would meet all your functional requirements of needing 3 bedrooms and 2 bathrooms but it’s where the 3 bedrooms and 2 bathrooms are in relationship to the overall layout and flow of the house that really matter to you. If you think about it, there is no good reason why the process of building a house should be any different than building an application. For example, take a look at the various resources and how ideally their roles compare to one another:

  • Design Look and Feel:
    - House Building = Architects and Interior Designers.
    - App Dev = UI Designer or Visual Designer
  • Build Foundation:
    - House Building = Mason.
    - App Dev = Technical Architect
  • Build Functionality:
    - House Building = Plumbers, Electricians & Carpenters.
    - App Dev = Developers and Database Engineers
  • Manage resources:
    - House Building = General Contractor.
    - App Dev = Project Manager

Overcoming the “Opinion” factor

Too often decisions are made during the course of a project that is based solely on opinions rather than the knowledge and experience of a UI design specialist and usability test results. Opinions are always hard to overcome because everyone has one and it’s difficult to convince people to stop relying on their opinions to make good design decisions. The best way to tackle this issue is by backing up your arguments with facts. For example, if a usability test concludes that 90% of the tested users did not interpret the navigation menu labeled “Help Zone” correctly then your argument to change the name to “Tech Support” will hold a lot more water. Usability tests are a great tool for getting opinions off the table and start steering the project team towards making decisions based on facts.

The value of using UI design specialists

A great deal of a UI design team’s time is spent on educating project teams and clients on the value of involving UI design specialists from the beginning and throughout the entire lifecycle of any application development project. Often times the education process involves a presentation, which may include:

  • A walkthrough of the user-center design methodology.
  • Sample deliverables so clients know what they are paying for and technology teams understand what will be delivered to them and how they will need to be involved in the process.
  • Samples of applications that did not utilize a UI design specialist versus ones that did.
  • Research that demonstrates compelling facts about the importance of usability and UI design in the words of industry experts, instead of your own.

Let the developers develop and the designers design

The most successful application development projects are those that utilize resources for their strengths and do not stretch them into something they are not. Obviously some projects with smaller budgets cannot avoid using resources that need to wear many hats but making the database engineer design the UI should be avoided at all costs. In my experience even a little help from a UI design specialist can have a tremendous positive impact on a project’s success. In one project, the budget did not account for a UI designer at all but halfway through the project the Project Manager could see that the interface was not coming together so they found a way to involve a UI designer for 2 weeks so the developers could at least be given some templates to apply to all the screens of the application. In this case, the project went from a path of certain disaster to one that the customer praised and more importantly the users could easily use.

————————————————————————————-

Chris Gieger  |  President & CEO, GIEGER Visual Communications, LLC


Leave a Reply