Getting Innovative

I was recently given feedback on my abilities to design for web 2.0 technologies.

When I found the time and space to reflect on that feedback my first reaction was dismay. As a designer it is my job to take advantage of technologies. A design is pretty much worthless unless it is actually built. To fail to take advantage of a technology because I don’t understand it would be akin to a painter not using red because he hadn’t painted with red before.

Then I admitted that I was afraid: afraid that I wouldn’t be able to successfully design for these technologies. In retrospective that’s a silly fear – the purpose of design is not to make a technology possible for the sake of a technology. User and market requirements/needs/expectations drive the choice of technology. (Choosing to successfully design for a technology would be like looking around the house for a job that needed a hammer. What if what I really needed to screw a leg back on a chair?)

Then I got to my core fear: I was afraid that my toolbox was full of outdated tools. I was afraid that I my world view was too static, that my experience integrating iterative design practices into waterfall software development had “hardened” me, so to speak, and that the flexibility of web 2.0 models and paradigms were out of my reach.

Perhaps my need to create a user model – so helpful at the start of the web-based application era – was a process that sacrificed real output.

So I reviewed my basic process: let’s say I’m trying to design a shopping site. I’ve designed many browse categories, search results, details, shopping cart and check out processes quickly and confidently. There are paradigms, documented paradigms, for each part of these processes and there are still great places for innovation. I would have started with some task flows, then made a conceptual level diagram documenting the main features and users, then would have begun a site map and wireframes, and then written a detailed specification (if needed).

This design process is very linear; breaking down the problem from big picture to low-level details. And along the way there’s validation with users, exploration of designs with users, paper prototyping with users.

So what about building the same application using web 2.0 technologies – would that impact the design process? Would it impact the design documentation? Should it? And how do new software development processes, such as Agile, impact that process and documentation?

I think designers are in a hard spot right now. Designers are being asked to be innovative, to take products to the next level, to make software purchased by IT departments to be as appealing to users as consumer products. (How many of you have heard, “We want the next ipod!”) But at the same time designers are being asked to produce careful, concise documentation on how to implement that innovative design.

Why is that? Because user experience teams have traditionally fought to prove their profession role in the industry: they have fought to have their work respected and implemented, they have been continually asked to prove their ROI in organizations.

But we’re heading into a new world paradigm. Computers are almost ubiquitous in America today. The next generation coming into the workforce doesn’t remember a time without the internet. People expect more from their computers and software than ever before. And people are more comfortable demanding good design. The days of “user error” are coming to an end.

So designers must design better, faster, smarter, cooler. But owning the detail specification does not give user experience teams the ability to design better, faster, smarter, cooler. It keeps user experience teams tied to software development cycles, it keeps user experience teams focused on change requests and ECOs. It keeps user experience teams focused on the short term and not the long term.

The only way a designer can give herself the time and space to create innovative design is by developing true collaboration with the rest of her organization. Designers must be true leaders and empower the rest of the organization, chartered with design excellence, to follow.

Don’t think your organization has a design excellence charter? Think again. Those crappy applications don’t have a lot of time left.