The De-Evolution of UX Design

Go to article

by Lis Hubert

I was first introduced to the field of UX in the summer of 2005. After leaving my job as a Java Programmer in Hartford, I moved to San Antonio, where I randomly fell into a UX job—talk about lucky. It’s an understatement to say that I had no idea what I was doing, and I scraped along for a while trying to figure it all out.

Back in those days, my role was not described as “UX designer” or “interaction designer;” in fact, the term “UX” didn’t even exist in my world! Instead, those of us who weren’t visual designers were called “information architects,” and that was exactly what we did. It was our job to architect, organize, and make sense of the information within a website or application. After we mapped that out (either in an IA document or some sort of concept mapping), we worked with a visual designer to put our mapping into an interface.

The first thing I did on the job, which may be surprising to many of us now, had nothing to do with learning how to wireframe. In fact, I didn’t create my first wireframe until almost three years later. Instead, the first thing I was instructed to do was visit Jesse James Garrett’s site. I was tasked with understanding what the “visual vocabulary for describing information and interaction design” was from a conceptual standpoint, and to then map out information flows for my projects.

There are several reasons why this was my first step. Learning and applying the visual vocabulary meant that my IA outputs forced the project team to focus on and discuss how information should be interrelated and prioritized within a website or application before we started to design the interface solution. If we didn’t first determine and get business stakeholders’ input into how information and content should be interrelated and prioritized, our design team would be guessing at the design of the interface. Learning and applying the visual vocabulary allowed our IA team to define the information structure and then force a stakeholder discussion around it to get useful direction and avert confusion and frustration during future design phases.

The second reason that learning and applying the visual vocabulary was my first step was that my design team didn’t want to show an interface to our non-design partners and stakeholders as our first deliverable (which is what showing a wireframe would have been). We knew that what we really needed from them wasn’t feedback on the visual solution, but rather feedback on the content and context that related to the system. That information would help us to better define the interface in the coming phases, as well as decrease opinion-based discussions and feedback.

It’s been seven years since I took that first step into IA, and, sadly, it seems that the practice of understanding and prioritizing information before designing the interface has been abandoned. And because of that, we are facing a huge problem in the world of UX, which is, simply put, that we are devolving.

The definition of de-evolution is “to degenerate through a gradual change or evolution.” It seems to me that by removing the information architecture step—where one takes the time to understand and prioritize information—from our day-to-day process, we’re on our way down the path of de-evolution. I’m not saying that there needs to be a structured phase that everyone needs to follow, but I am saying that IA (which includes first understanding and mapping out how information should be structured) needs to be done and signed off on by stakeholders before a project can move into interface design (including wireframes).

There are several problems that arise from skipping the IA phase. First, the team (UXers, visual designers, project team members, other stakeholders, etc.) won’t be in agreement on what type of information is needed and what information is most important to the design, which will cause disagreement in later phases. Second, by showing wireframes without agreeing on the IA, we are focusing stakeholders and other partners on the interface and not on the real thing we are designing for: content and context. Third, we are, in essence, beginning to lie to ourselves, supposing our designs aren’t just about form, but about function as well. If they were about function, we would have spent time on the IA phase before we went right into talking about form in the wireframe phase.

To make matters worse, we as an industry have been trying to validate the discomfort that many of us feel subconsciously with skipping the IA step, by turning to sketching as our ultimate solution. Sketching is an important and helpful technique, but we need to be aware of its limitations, and when sketching is and isn't appropriate in the product design process. Many UXers seem to think that since sketching doesn’t involve putting wireframes into an electronic format, it doesn’t really count as skipping straight to wireframing. But sketching the interface without first sketching the structure of the information means you are skipping the one step that will make your designs truly successful. That step is where you think about the content, context, and users, and force your stakeholders to do the same, without thinking about the interface—in other words, that step is the IA step.

So how do we stop this process of devolution and backwards movement? We bring back IA! I’m not saying that we should all learn Jesse James Garrett’s visual vocabulary (though it wouldn’t hurt) or that we need to institute a structured process that we follow the exact same way every time. But we need to slow down, put down our sketching pens, close OmniGraffle, and just think. Think about and draw out the application content, context, and users, and use this to gain buy-in. And do so without a wireframe or a sketch of a wireframe. Pick up the Polar Bear book, ignore the wireframe chapter, and learn IA. Then go out and put IA into effective practice in your organizations and teams.

By bringing the IA phase back and by concentrating first on the information, several things will happen. First, your sketching and interface design will become much, much better because you have prioritization and buy-in of the content, context, and users you are designing for. This allows your wireframe/prototyping phase to truly be about the interface, not what content should go in the interface and why. Second, you are showing stakeholders that UX design isn’t just about form, but really is also about function. This moves the focus away from the interface and towards a real solution of which the interface is only a part, and brings us back to the roots of IA. Third, we can finally stop pretending that the best UX solutions are the coolest and most aesthetically appealing. The best solutions are those that take content, context, and users into consideration while creating an aesthetically appropriate interface. Most importantly, we stop UX’s slide down the evolution scale back towards the time of design for the interface and not the experience, and instead continue our climb towards being true UX experts.