UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 809 March 27, 2012

The De-Evolution of UX Design

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.

ABOUT THE AUTHOR(S)

User Profile

Lis Hubert is a Strategy & UX Consultant based here in NYC. Her passion lies in helping people and companies of all types make their products and services easier and more enjoyable to use. Lis has worked with clients such as ESPN Mobile, NBA.com, Google, Weight Watchers, and MTV Networks and has recently signed on as Chief Experience Officer at 8coupons.com.

Add new comment

Comments

35
39

good read! good points on IA and visual vocabulary

40
46

Yes...I've been an internal UX-er for enterprise software companies for over ten years, and the only constant seems to be a reduction in time spent figuring out the Whys, Whats, and Whos. As designers, it's fun and easy to dive right into How and to show off our design chops with prototypes and other artifacts, but I echo Holger's comments - I am a questioner, and if I don't have a 'good enough' understanding of the problem space, and the needs of the audience, stakeholders, and team, I struggle. To my way of thinking, IA is all the stuff that reflects the up-front decisions teams must make to ensure a successful project. Perhaps most shockingly, many of my UX colleagues don't even know what IA is...or they consider it the purview of a different role.

34
42

This confirms what I've seen in many places, UX is becoming prey to a land grab of 'genius' visual designers. 'i know what i want to do' is replacing or over shadowing, 'I know what problems I'm solving' or 'goal i am designing for' . Information architecture, information design, content and context of use still have a place at the table. Digital design hubris will diminish UX as a field and products suffer as a result.

37
41

I agree with Christopher Detzi - it really depends on the nature of the product. The software (web app) that I am currently designing requires IA simply because of the nature of its content - big data presented in pivot screen format with interchangeable attributes and metrics with multiple dimensional views. If one doesn't understand the nature of the atomic data and can architect visualizations for it, the project would be a flop. Even for my team of 30+ coders, without very specific architectural diagrams of data joins to visual output, there are days we get lost. On the flip side is a senior management bent on gamifying the app, so IA becomes even more important simply to retain integrity. UX will move forward BECAUSE we get better and better at IA, not because we abandon it (for the same reason the rudimentary HTML I first scripted back in 1994 looks so elementary by today's standards but the principles of it still apply).

30
40

Thanks for the comment.... and I read you post as well... great article! I think the main point that brings our two thoughts together is the thinking and planning and how that is so very important. I think you are right in that exploring the other C... colleagues... could be very interesting!

33
43

Hi Lis, great article and what I love most is the discussion. Because I believe it's always worth it to stop and to rethink what we are doing and why.
I've been working on UI since 1985 when there was only the Mac Plus around. That was when I found my interest in UID and information structures began to grow. And I still change my way of working form client to client and from project and project. New procedures, field of activity and deliverables are not an end unto themselves.
The activities and deliverables are a means of communication and to push projects forward - together with several stakeholders, departments and people.
it is of utmost importance to examine and pay attention very acutely to be able to identify the real bones of contention, communication and understanding, in turn to be able to intervene in a helpful and constructive manner to deal with and, if possible, to solve the conflict of smooth and hassle free communication.
We are always asking and being asked: what are the deliverables. Throughout my career as an IA, UX-planner and designer, as well as during my study of architecture and town planning, I have constantly asked myself following the questions ...
... What kind of project is it? What are the key points?
... What should our steps and milestones be in the project?
... What should our/my deliverables be?
... How can we/I explain the main idea?
I have realized that if I do not answer these questions previous to creating a deliverable, I waste more time and deadlines slip.
A few months ago I wrote an article 'Walk a while in someone else's shoes: Exploring the Role of C...s' ( http://ux4dotcom.blogspot.de/2010/08/walk-while-in-someone-elses-shoes.html ) - this article is about the understanding of 'Cs' (the C stands for: the Consumer, Customers, Casual - and Commercial User) and how we bring them together. But maybe I should expand the meaning C = Colleagues !?

33
37

You just exacly described the problem i experience with a lot of project where you have to fight with the client to recieved the content and struggle without it during the ux and design phase.

Thanks for the great article.

37
38

If we set aside the labels, any piece of the puzzle that is left out hinders the user experience. I'm not referring to deliverables, but rather, prioritizing content and understanding the relationships between content/tasks. Nothing brings this into focus like designing for small screens.
For example, do I really want to have a direct link to managing my list of emails while I'm writing an email on my phone? Or are the two chiefly related tasks reading and writing/responding to emails? If so, a direct link to list management just gets in the way or leads the user down an unexpected path. Without coming to terms with issues of priorities and context, controls and actions can end up with relationships and priorities that feel unnatural to users.
Some folks can manage this sort of thing in their head and start sketching. But Liz brings up a salient point - this hasn't been run by the client, nor has it been made evident to the team. Plus, mapping out tasks and subtasks can also help with usability testing and help us understand where our origina tasks paths did not match up with user expectations.
After living through many trends, it seems the latest technique (or lack thereof) is always seized on as a means to save time and money, or subvert the need to learn a skill. While our disciplines are still evolving and growing, we have to remember there's no silver bullet. Skipping key steps will cause our products to stumble.

31
41

Thanks for all of the awesome discussion so far! I am glad (and also sad) to see that others have been seeing this same trend. The intention of the piece is to point out the need to slow down and think about the structure of the virtual places we are building through our websites, apps, and more before we start to think about the interface of those virtual places. I do agree that a formal IA step is not always necessary, especially in smaller projects, however I firmly believe that some sort of IA thinking and skillset (however formal or informal) should go into constructing any virtual place. The extent of that thinking is dependent on the situation, as always.

I do believe that without this thinking UX is in decline. I can see that not only in the client expectations that I run into, but also in the work that we, as an industry celebrate (much is aesthetically pleasing, but hasn't been constructed into a useful form). I'm interested to see how all of it plays out!

38
37

* architecture

32
38

Extraordinary article. I was comforted (but sad) to see that the same behaviour accures everywhere. and it is not just me that preach to information architect.

32
33

The "de-evolution of UX design" may or may not be happening to some organizations. But the disadvantages remain when information architecture is ignored or skipped. To those who can relate to this, we should be reminded of its importance in the design process.

33
43

Hi Lis-

Extraordinary article...well done!

I try very hard to teach information architecture and user/searcher experience to search engine optimizers because IA has such an incredible impact on findability...not only on web search engines but also on site search engines.

I think it's difficult for many people to "get" IA because it's not visual. Many of my clients and colleagues are very visual, and they rush into poor designs and even poor wireframes because they require that visceral impact to understand the deeper, perhaps more "frontal lobe" thought process for an effective information architecture.

Add to it the unfortunate challenge of, "Make my #1 on Google all of the time, and do it yesterday" mentality. That's the challenge that search professionals face.

Again, kudos on an extraordinary article.

33
42

One thing I've found that can gum up the full, complete flow for UX work is actually the audience of stakeholders.

Often the best thing for your audience is "the works" in a certain order: personas, IA sticky-note games, flows diagrams, wireframes, interactive wireframes, mockups, specs, etc.

But a lot of the time your audience is not going to "get" some of those steps, and some will only take part if you do them out of proper order. It has to do with what they're used to in order to full grasp what you're delivering to them.

I've had stakeholders that have gone through several rounds of esoteric steps (taxonomy, wireframes) without any feedback and then suddenly wake up when they see the first mockup - unleashing a torrent of feedback about not only the new visuals but about the core aspects reviewed in the earlier steps. What that means to me is that some of these deliverables seem "real" enough to our audience that they fully understand them, while the other materials just whooosh past them. If they don't have the experience (or patience) to simulate what these early IA steps mean for the final results then I've found people either mentally check out or they nit-pick over inconsequential details.

As a result, I've started switching order and skipping steps to get stakeholders engaged early, so that when I show them an esoteric step, they know that it's important.. that it's going to be used in the throw-away example I showed them previously. It's more wasteful but I think it's often necessary to avoid time bombs in the design process.

37
34

Is the UX field now dominated by people named Chris? Looking at the comments here, one would think so.

34
37

Like many here, I have been part of what we call UX for a long time now. I came into the work through HCI.

Here is my real issue with your point of view. You suppose that the "Architecture" (organization of information) supersedes the experience in terms of value. I could not disagree more. The structure and navigation of information is important, but that might lead you to a "Jacob Nielson"-like philosophy, stripped down experiences built and utility. This is not *true* for humans, design, interaction and appeal drive adoption, usage and affordance at least as much as proper IA/structure.

All experience professionals would be better off to look at work on a per-project basis, and consider the needs from there. In some cases interactions and design may lead, in others IA. Thinking of experience as purely a reflection is an old, and incorrect view of usability.

Feel free to poke at my blog posts anytime! http://thearchetypist.com

34
41

Your experience is largely echoed of Nancy Roberts’ (see “No more information architecture?” http://www.ixda.org/node/32339). I recall a few years ago there was a small movement against user research and for a “Great Designer” mentality, which assumed we can create superior products from the preternatural intuition that of course all us Designers have. This coincided with a new emphasis on “emotional design,” where the goal wasn’t so much to inform the user but to instill a certain feeling or motivation. Perhaps some web design houses have bought too much into this, and thus emphasize aesthetics over the user’s information needs. We’ll see if the forces of capitalistic natural selection allow these houses to survive. Meanwhile, perhaps you and Ms. Roberts should update your resumes and start shopping for more compatible workplaces.

40
32

Its a strange coincidence I am reading this article even as I am thinking about what's wrong with many of my clients. I am a freelancer from India and have often heard this "we don't need no understanding of users - here's what we want to do - now go fetch me the 'wireframes' in 2 hours" sequence, simply because the right path costs money which is perceived as unnecessary expense.
Most clients don't want me to talk to the users because they claim to have 'the necessary experience' on user behavior and habits.

33
40

I disagree as well. This may be the case for a few individuals but what I've learned most from working with other UX people is that we aren't all the same. There are those who are "doers" and have a task at hand to create wireframes which is all they do with out understanding the problem to be solved.

Then, and there are much fewer of these, are the rest of us who know that the only way to completely solve the problem is to understand it completely. We move away from the placement of buttons and jump directly to what the project is, what the business requirements are and move forward from there once we have an understanding of what everyone wants. In doing so, we also task ourselves with pushing back when the business requirements are going down the wrong path or when an unforseen issue comes to the surface that the stakeholders did not, and could not have seen during the inception phase.

I consider myself to be a rare bird among UX people these days unfortunately, but lets not be quick to categorize all of us with de-evolution.

36
37

Ok. I'm old. Well 44, but in internet years that is kinda crusty. I have been an IA by title since 2000 and by practice since 1998. I have worked inside huge corporations and small agencies. I have definitely noticed a trend towards pictures-first design. I believe this comes from the pressure to "show progress" to our clients, and to them that means screens and prototypes. In my experience the clients we work for (both internal and external) do not understand the need to build systems of categorization and organization. In JJG's planes of user experience they blow past strategy, bum rush scope, ignore structure, get confused by the skeleton, and ask to see the surface right away. We fight against that, but in many cases it is a losing battle.

41
42

I totally disagree that the IA-step is being skipped by UX practitioners (or I am completely misunderstanding your definition of the IA step). As chrisdetzi points out, I see now an even bigger integration of IA in UX design than 5 years ago.
It should be obvious for all UX designers that information about the content, context and users should always precede the creation of wireframes and visual design. The benefits that comes with observing users, their needs and their context before actually designing something is the reason the UX field even exists! Furthermore, the importance of using knowledge of users as input to design is barely mentioned in your text, which I find a bit strange.

Maybe I'm just being an old UX whiner when I say that this article's preaching to the choir. However, I strongly disagree to the claim of UX design being in a state of "de-evolution".

32
40

I do a lot of work in the WordPress/Genesis arena. I actually just gave a talk about this at WordCamp San Diego. I agree, we see this a lot, especially in smaller projects where a single designer/developer completes the project (one who often has no formal training in traditional web design), or a business owner works on their own. Since it's easy to install WordPress and relatively inexpensive to install a professional-looking premium theme, they skip some of the most important steps of the design process...namely the Discovery and IA phases (I'm old school, lol!).

I'm hoping that by educating designers and clients about the concrete benefits of investing the time and effort it takes to complete this step, we'll have a UX revolution.

33
40

Great article. I like the definition of de-evolution where we degenerate through a gradual change or evolution.

39
41

I think that you're making some broad generalizations. What evidence supports the premise that IA is being "skipped" by UX Designers? Perhaps you're equating the adoption of a new title (eg, UX Designer) or development of new techniques (eg, sketching) with the shedding of a fundamental process (creating an Information Architecture), but I don't necessarily see it that way. Many UX Designers that I know are well-versed in IA and do it all the time. In fact, the 2012 "Information Architecture Summit" just wrapped and boasted the largest attendance in its 13 year history.

If anything, I see UX as a field that continues to move forward and practitioners thinking even more broadly about the design problems we face and how to best solve them. Sure, some of the artifacts we produce to communicate those ideas may change, but I don't see a wholesale abandonment of the core IA principles.