It is happening across many companies, as we re-deploy staff and re-prioritize design initiatives. In a vast majority of cases, the primary design knowledge for an application is stored in the heads of a few interaction designers. These design decisions are rarely documented in a manner that can be used by others in the organization. When one of these people heads for greener pastures, a great deal of that knowledge leaves with them, never to be leveraged by the rest of the organization. The investment previously made in web design is also lost. The remaining members of the team must then piece together the prior design decisions and revisit many design issues previously agreed upon, in an attempt to salvage prior work and keep the projects moving forward — again, loss of time and money.

Interactive team meetings and a whiteboard are the basic staples of an effective design session. My issue is not with the design meeting, but rather with how we leverage the great ideas that come from them. I have worked with design teams for over a decade and have witnessed this age-old problem repeatedly without fail across nearly every industry, project, and technology initiative. Because the issues surrounding user Interfaces are so complex these days, a vast majority of the time, which interaction designers invest on a daily basis, is spent in design meetings. Is your firm capturing these design decisions, validating them with some real world usability testing, and then sharing them with other teams to leverage this valuable, time consuming and costly effort across your enterprise?

Many corporations, which recognized the need for increased usability, set up a team of interaction designers and usability engineers to work as consultants within the corporation. With today’s economy, there is increasing pressure to reduce the headcount of support staff and, at the very least, to allow for immediate and highly leveraged results from these teams. I am constantly seeing these consultants running from project to project, trying to add value, but not really getting their collective knowledge out to the various teams in a clear, coherent fashion. This resource utilization issue often leads to burnout on the side of the interaction team and frustration on the side of the developers.

It is hard enough to get developers on the same team to share code and templates. Implementing a standard look and feel of design best practices across your organization or even your local development group can be a monumental task. The main issue here is availability of good content and education on how to implement the best practice design ideas. The biggest complaint that we see at companies that have attempted a standards program is that the developers feel the content is not up to date with their technology decisions. The web is a much more dynamic environment than the prior world of Windows, with its semi-stable cadre of MFC controls and Microsoft-mandated look and feel. For example, developers facing web design decisions on an intranet application have very few solid examples of the BEST way to turn a client/server grid control into a viable, usable web-based grid for showing and managing lists of data. Once an approach is adopted by a team, it is rarely shared among other teams in the company.

The push to meet tight deadlines with fewer resources has created a situation where developers either don’t take the time to implement designs as originally envisioned or find shortcuts to try to meet the intent of the original design. There is often not enough time to hold sessions between the interaction team and the developers, where the details about behavioral aspects of the user interface can be taken the to next level of detail. As a result, developers often resort to implementing a solution based on their existing code set and capabilities. How often have you heard from developers, “That’s nice, but it can’t be done with our time constraints”? Instead, in an effort to meet a deadline, the developers pull code from free sites on the Internet, scour their archives of previously used code snippets, and generally make do with the limited resources immediately available to them. The result is often a design with three or four different methods of data validation, two or three different ways to sort and filter a list, and of a variety of different layouts and methods of selecting dates across your consistent and well thought-out application.

This is a big problem without an easy answer. However, I’ll attempt to address some key ideas we’ve seen work in organizations that are achieving success in user interface design. As usual, the solutions that come to the forefront involve getting the right people, adopting the right process, and using the right tools.

It always amazes me to see how many millions of dollars companies spend to manage and protect their code assets, yet these same companies spend almost nothing to manage, leverage, and protect their visual design assets! I suspect this is an indication of the relative newness of visual design on the development process. Even the most basic design decisions are still being argued in conference rooms around the world daily, such as when to use a button vs. a link, proper use of colors, and basic form layout. It is not uncommon for companies to spend 60% of their development effort on the front-end design of applications. Despite this, form templates, navigation models, validation routines, control behavior, and physical design assets like graphics, icons, and images are rarely leveraged across projects or teams. These assets are often stored on a designer’s desktop or in a ‘hidden’ directory only to be lost during the next team transition or reorganization. The simple solution to this is to have a central repository where you can capture and deliver all your visual design assets. This repository needs to be scalable, open, secure, web-based and easy to use. A small team can manage the repository and sort out the design ‘gems’ that come along from your company’s various design efforts. Anywhere, anytime web-based authoring should allow all members of your organization to suggest new ideas and provide real world solutions to be shared across your organization.

One problem with capturing design knowledge is what to do with it once you’ve started collecting all of the design ideas from across your company. A small team of web designers can quickly become overloaded with design ideas coming in from teams out in the field and may often barely have enough time to document and communicate suggested designs on their current projects. Again, until recently, this was not an issue because of the lack of importance placed on user interface design by most firms. Now that usability has been raised to a higher level of importance, companies are realizing that if they don’t carefully manage their design knowledge assets, they could end up wasting millions on this critical area of application development. Again, the best solution for managing assets is to put them in one place, so they can be organized and easily accessed. As your design team sorts through the design assets to highlight the ‘keepers’ from the ‘challenged’ ones, you’ll need some form of workflow and process management to allow the team to collaborate and quickly organize and manage this critical process.

Now that you are getting a handle on capturing and managing your visual design assets, the most critical step ahead of you is how to get this knowledge out to the teams. The goal is simple — get them using this knowledge in their daily decision making processes. We’re all familiar with the scenario where the boss hands out the latest ‘standards document’ at the Monday staff meeting, only to see it shelved or buried in a pile of other documents on our desks by Friday. The bottom line is that guidelines by themselves are not enough. Those of you that have spent time watching users in a usability lab or have been on-site for the first day of a major product implementation have witnessed the first-hand effects of good vs. bad design. In essence, the best way to deliver your visual design knowledge is through an experiential model. Assuming we can’t require every developer and designer to hang out in an observation room of a usability lab, the next best thing is to get them real world examples and case studies where we capture the design knowledge with context that applies to their specific projects and issues. Then, link the resolutions and knowledge to specific guidelines to support the case study. Better yet, link them to sample code that gets them to a real-world solution with a couple of clicks with a browser-based developer knowledge portal. Developers love working code examples. When we tell them what we want AND give them a coded example, it not only assures that the design will be implemented as planned, it also can dramatically reduce the development coding effort.

The choice is yours; be content with outrageous risks and 75% failure rates, or realize that we are in a brave new world of technology design and development. Understand that a new breed of web-based collaborative tools, people, and processes are needed to achieve success.

By the way, we think we have a great solution to get you started. It’s called GUIguide™, the world’s first User Interface Design Knowledge Portal. www.guiguide.com. Let me know what you think, info@classicsys.com.