When I was first introduced to the field of user experience it was the summer of 2005. After leaving my job as a Java Programmer in Hartford, CT I moved to San Antonio, TX where I randomly fell into a UX job (talk about lucky). It’s an understatement to say that I had no idea what the hell I was doing, and I scraped along for awhile trying to figure it all out. Back in those days, my role was not UX Designer or Interaction Designer, in fact, the term UX didn’t even exist in my world! Instead, those of us that 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 doc or some sort of concept mapping), we worked with a visual designer to put our mapping into an interface.
Unlike a lot of what we see today, the first thing I did on the job was NOT learn how to wireframe. In fact I didn’t create my first wireframe until I moved back east to NYC 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 architecture and interaction design was from a conceptual standpoint, and was then expected to map out IAs for my projects. There are several reasons why this was my first step. Reason one was that we IAs and VDs simply needed to know how information was related and prioritized within a website or application before we could design the interface for that system. How else can you design a proper interface solution unless you understand which information types need to be included in that solution, and which are most important to the solution? Without knowing this information, we would have been guessing at the interface. Reason two was that we didn’t want to show an interface to our non-design partners and stakeholders as our first deliverable because what we really needed from them was not feedback on the visual, but feedback on the content and context that related to the system. It’s seven years later, and, sadly, it seems that the time I’m speaking of has come and gone. And, because of that we are facing a huge problem in the world of UX.
The problem UX is facing is, simply, we are devolving. The definition of de-evolution is to degenerate through a gradual change or evolution, and it seems to me that by removing the information architecture step from our day to day process we might be on that path. To be fair, I’m not saying how that IA phase should be structured in detail (that is for another post), but I am saying that this type of thinking needs to be done and signed off on by certain team partners before we can move into interface design (including wireframes).
We see several problems that come out of skipping the IA phase. First, the team (UXers, Visual Designers, Project team members, other stakeholders) won’t all be in agreement on the prioritization and context of the information to be designed for which will cause disagreement in later phases. Second, by showing wireframes without agreeing on IA, we are focusing our 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. We are lying to ourselves by telling each other than UX is not just about form, but it is about function as well. Because if it was about function, we’d spend time on the information (the IA phase) before we went right into talking about the form that the information should take (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 the end all be all answer. Of course, sketching is important, but it all matters what we are sketching and when. What I’m talking about is that we UXers think that since sketching doesn’t involve putting our wireframes into an electronic format, than it doesn’t really count as skipping straight to wireframing. But guess what, even 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 (also known as the IA step).
So where do we go from here? How do we stop this process of devolution and backwards movement? Well, we bring back IA! Ok, ok, I’m not saying that we should all learn Jesse James Garrett’s Visual Vocab (though it wouldn’t hurt) or that we need to institute a structured process that we follow the exact same way every time. But, what I am arguing we need to do is slow down, put down our sketching pens, and our omnigraffle and just think. Think about, draw out and get buy in on your content, your context, and your users. And do so without a wireframe or a sketch of a wireframe. Pick up the Polar Bear book, and ignore the wireframe chapter and learn IA.
By bringing the IA phase back and by concentrating first on the information, several things will happen. First, your sketching and interface design becomes much, much better because you have prioritization and buy off on the content, context, and users you are designing for. This means that your wireframe/prototyping phase becomes a lot more about the interface and not what content should go in the interface and why. Second, you are showing your stakeholders that UX design truly isn’t just form, but really is also about function. We are moving away from the interface, which is how we started, and towards a real solution of which the interface is only a part. Third, we stop lying to ourselves, and we stop saying that the best UX solutions aren’t just the coolest or the best aesthetically, but they 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 print design and outputs, and instead continue our climb up the mountain towards being the user experience experts.
[…] The De-Evolution of UX Design This entry was posted in Uncategorized. Bookmark the permalink. ← Tidigare inlägg The difference between Google and Facebook → […]
Great article Liz. Will be interesting to see the discussions this creates. Love that you are passionate about the need for the right tolls and approaches in our work.
I agree with most of the comments that a lot of UX designers simply haven’t had the experience of having to architect large and deep sites that requires more IA and I would argue even business analyst skills. This is in part due to the fact that UX is now applied to a much more broad set of projects from deep experiences like enterprise applications and sites to mobile sites to apps.
I really think that some of what has been under the purview of IA is now completed by content strategists. When I first started in this business over 10 years ago I worked on a lot of very deep sites – enterprise and ecommerce. I spent a lot of time architecting the site and the experience and helping plan the content. Today I work with a content strategist and we collaborate on the content and structure. I think this is the way we are moving.
[…] Źródło: The De-Evolution of UX Design, Elisabeth Hubert, Elisabeth Hubert blog. […]
[…] Lis Hubert talks about the de-evolution of UX design. […]
Ah those were the CRAZY days
Thoughtful article, but I’ve been doing UI/UX/Interaction design for nearly 20 years and things have not changed all that much. IME it was rare to do any in-depth IA work at any point in time. There was a period when IA was “in vogue”, but for the most part we’ve always been sketching from day one and conceptualizing products in visual form. That won’t change in today’s fast-paced marketplace. The best designers have enough experience to “shoot from the hip” and get things mostly right.
Unfortunately, the world is not full of the best, or even seasoned designers as yourselves. Someone has to teach about context, content and users before interface. I was taught that (maybe it was a weird time) and I’m hoping we start to show that to others.
Thanks for commenting!
Nice post, but why moan about a species, which might face extiction? Or put it differently: clients just don´t care (or only seldomly) about how we name the function, phases and roles which lead us to good results.
We´re just in a project we started strictly from the content side, bringing in design and technology later. And guess what we found: you can´t really seperate them. A great project is the result from an incremental, itirative process, in which each discipline inspires the others.
But wait, there´s one hickup. As we put content and design (or users use) first, we alieanate the tech guys a bit, and they are really having a hard time to rething their hierarchic prgramming and CMS-stuff in a fully networked heterarchichal world. 😉
I see where you are going with it, but it is truly not about naming a phase… it’s about doing the thinking that leads into the interface before drawing the interface.
I also agree that they are not necessarily separated into phases and hardcore project management, but simply that we think before we draw, even for a second.
Great point about the tech guys!
I’m always down with creating lots of conceptual and abstract structural maps of a system, to help designers understand the underlying qualities, logic, mental models, and technologies involved in what a user sees and touches.
Two thoughts about that.
First, I think it’s fine to work on wireframes or even visual design before working on any kind of conceptual flows or information hierarchies or other abstract design exercises. Each kind of activity influences the other, designers should follow their inspiration and work on whatever helps expand their ideas or better define the problem at that moment in the process, and that’s a beautiful thing. Completely avoiding abstraction, however, is usually a mistake.
Second, and yes I am being a little pedantic, JJG’s VV isn’t IA, it’s IxD. 🙂
There you go trying to name “the thing” again hahahaha.
I agree to an extent that it may be fine to work on wireframes because you shouldn’t, as you mention, stifle thought or creativity, and one doesn’t inform the other. I would say that this depends on the maturity of the designer’s familiarity with the process. Meaning in order to get everyone on the same page with how software development works (at least in your organization) we should teach and promote that process. If they are a junior designer just jumping right into the screen in order to get things done, then I don’t agree with doing wireframes first. I am referencing the later in the post (great point to bring up though.)
Thanks for reading and commenting Chris! Really appreciate it.
Hi Lis, I just had a chance to read this. Thank you for the stimulating thoughts! Here are a few reflection points for me:
I wholeheartedly agree that a failure in both gathering feedback and ensuring buy-in on content and context early in the process is a problem. In fact, it has a domino effect which impacts quality of the solution and increased cost of getting the work done (no agreement means more cycles discussing that which has not been agreed upon).
– – –
I have always had a real peeve of framing IA as a phase or step in a process. Not because the work involved isn’t something that should happen before other things, but because a) It historically diminished information architecture practice into one narrow aspect of the work that it entails and b) because the word IA gets in the way of expressing what you described as a moment in the making of the solution; “to architect, organize and make sense of the information within a website or application”. So, I agree with your sentiment, but not with the frame you use to express it.
– – –
Getting sign off on structure and conceptual organization before one can jump into interface design is a preference; it is not a required approach for success. See public examples from 37 signals and Adaptive Path depicting how the work is done. See the prototyping renaissance we are in, where we explore the solution by providing a mechanism, the prototype, to express the various layers of problems we address in coming up with a solution to a problem at the same time.
There is, however, an issue dear to my heart that is hidden in your statement: design maturity. When doing work in a setting that immaturely understands the contribution of design, it becomes important for the designer’s sanity and ability to progress to get commitment that what was done on step A is not going to be debated ad nauseum in step B.
(More on design maturity as it pertains to the environment that one is designing in, see http://www.bplusd.org/2008/12/08/design-maturity-model-2009-beta/).
I’d add to that maturity of the work setting two other factors: the designer’s skillset and the level of complexity of the system they are designing. If you combine the three variables you get as a result, a situation that affords different ways of doing the work.
– – –
I cannot tell why you perceive sketching to be such a problem. Who sees it as an end all be all? How does it validate a discomfort with something else? Why wouldn’t one create wireframes in electronic format because they also sketch? And why ignore wireframing to learn IA? You reject tools and techniques in favor of thinking; tools and techniques are nothing but thinking devices.
Having said that, any tool or technique can be used as a crutch. Sketching, wireframing, card sorting, heuristic evaluation, prototyping, eye tracking. They can all be used for good and evil. They can all be used poorly too. That is what distinguishes the experienced practitioner from the inexperienced practitioner. Also the ethical practitioner from the snake oil salesmen.
The quality of the tool and the quality of the thinking are different issues. They intersect where the designer is reliant on the tool to make decisions. If sketching affords me what I need to express and understand a problem, and articulate a solution, why not?
– – –
I disagree that the practice of experience design is devolving. I see no evidence of that. The issue you describe is real, but in my opinion, no more or less prevalent than it has been before.
What I see in the practice of experience design today is a renewed level of energy, particularly in the last 12 months, driven by two factors:
First, the explosion of personal devices (more new devices as well as greater penetration across audiences worldwide) which is forcing businesses to not only create experiences that fit new contexts of use (mobile use, tablet use, TV use, etc) but also re-evaluate how they’ve been doing this work all along in contexts they had grown comfortable/complacent with.
Second, that and other economic factors have created a large demand for experience design practitioners. This is critical problem right now as we as a community of practice simply cannot meet the demand. (PS: Jared Spool forecasted this years ago, so I’ve been paying attention – I’d add a reference here but I could not find it and am running out of time writing this, sorry!).
As a consequence, there is a lot of experimentation happening. Figuring out how to deal with all the new problems this situation presents forces people to conceive different ways of working. Take prototyping: it is positive in terms of improving quality of the solution created (because it affords iteration, faster cycles, improved collaboration, etc) but it’s also a way for people to differentiate themselves in the market form a skillset standpoint.
It is a burst of energy for Experience Design as a practice.
Thanks for the response Liv! Always love to hear your input. I hope that we can talk about this more one day in person!
I think this is more a symptom of the misuse of the term ‘UX’
than a fundamental problem in the way true UXers work. I think more and more
people are treating User Experience design as a ‘new’ way to describe about
User Interface design, when it reality the structure and labelling of the
content has a huge impact on the user experience – arguably more so that the aesthetics.
This tarnishes the meaning of the term UX. It makes companies think they are investing
in user experience design when really they’re just getting one part of it – a
I agree with the other commenters that the visual design is
more rewarding to deliver to stakeholders – it’s usually the bit they get
excited about. I find that stakeholders
often want to leave the IA, and content in general, until later (i.e. the very
last minute) when they want to use their CMS to copy and paste content from a
tired old website over. Getting
stakeholders to engage with IA is just as important as appreciating it
Yes! Great point… I like the way you are phrasing that. And, you are right, visual design is more “rewarding” to stakeholders but less so to our users and our end product.
Great article, Lis. I tend agree with S. Wachter-Boettcher’s comment regarding many new UXers coming from the visual design world. I followed the same path and, after a couple of quagmires, found that I really had to stop and re-evaluate my thinking about how I approach a project. Learning and understanding IA truly makes the visual design phase go much more smoothly.
Definitely great points in theory. In practice, it’s more difficult. First off, business stakeholders rarely have a grasp on the content that should inform the IA. (This is partially why I’ve become a strong advocate of content strategy, and beginning any design process with a clear grasp of content requirements). Secondly, good luck finding anyone (other than another IA) who is actually willing to review, comprehend and sign off on IA documentation.
Simply put, stakeholders react to design. Keep the IA phase, but keep it light, and make most of the documents internal. Use them to point out gaps and inform design. The faster you can show people visuals (be they sketches, wires or detailed graphic design), the better.
Agreed the into practice is always the hard part (theory is easy… application is challenging) however this is a spot where we can use our creative thinking to push this point forward. Of course, this is sometime impossible, but a total lack of trying leaves us with less not more. The point is that it doesn’t matter if people “want” to sign off on IA documentation; it is that they need to. However that documentation is structured.
We need stakeholders to understand that their systems are not just interfaces… it is essential. Stakeholders react to design because we continue to feed it to them. It is on us to change the cycle.
I agreed with Scott. In the real world we are visual people. Stakeholders are more interested to see the proposed design first as some of them say they will have a better idea if they can see how the content fits into the design as a whole. It’s like some clothes are nice to look at but once you put it on, it doesn’t look right. Also even though client signs off on IA, they will change it once the design is shown.
I do understand this point, and yes, I am visual too but there comes a point where showing a design first, without knowing really what you are designing becomes extremely problematic in further states of the project.
Agreed that clients change their minds… alot. But there should be a general understand of what we are designing before we just design.
We can’t design something without knowing the content and we shouldn’t skip the IA step and what I’m saying is having to ask client to sign off on IA and then move on to design is quite impossible. Maybe the design and IA should be presented and sign off at the same time?
Ah ha NOW I see… great points! Hmmm that could work.
I appreciate your directness.
I appreciate your directness.
I fully agree, Lis. I’ve done both content first and sketch first designs and in retrospect, the sketch first always turns into attempting to fill content into the design until having the design work with the planned content itself.
Sketching can lead to some great ideas about design; however, if the content isn’t taken into consideration, the probability of additional noise on the page increases.
Hi Lis. I really like what you’re saying here, and I think this return to more “traditional” IA concepts is actually going to become more important as we deal with designing for a web that’s more flexible—such as responsive or adaptive sites, where you have to think about multiple interfaces being built off of one IA. For this to really work (and to scale effectively), you need to be able to establish things like hierarchy, prioritization, and relationships between information in an interface-independent way.
It seems to me that this change also coincides with the rise in UXers coming out of design programs rather than library or information sciences programs. Not that there’s anything wrong with that path, but there are tradeoffs. That said, I come from neither background and call myself a content strategist, so you can take that commentary with several grains of salt.
Anyhow, great post, and glad people are talking about this.
That is exactly what started my thinking on the topic… great point!
Ah yes, another great point that I didn’t think through re: backgrounds.
Thanks for reading and commenting!
Great post Lis. I think a lot of what has turned up the volume on “sketch first” without as much emphasis on IA has been a very vocal minority of people who create UIs with limited scope, such as mobile or task-centric web apps.
Some may argue there’s less need for hours and weeks of IA work to create the next Path or Instagram, but that may not be the case for a content-rich site primarily accessed from a desktop.
Your concluding recommendations are spot on.
Great points… thanks Chris!