user experience architect

The De-Evolution of UX Design

Published on February 15, 2012

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.

UX… Let’s Stop Being Unicorns

Published on November 16, 2011

I’ve mentioned several times before how I have the opportunity to attend many UX and technology events (mostly because I live in NYC and am a consultant, but also because I try my hardest take advantage of these situations). I’ve also mentioned before that I got to attend this year’s NY Internet Week (see UX… so you wanna work with startups for more thoughts on this event). What I haven’t mentioned here before is that I have discovered that we, as User Experience Designers, are unicorns. Meaning, we have skills and talents that technology companies want, need, but don’t truly understand, AND we are super hard to find.

Now, these technology companies, especially startups, are creating a ton of new products and updating a great deal of old products all the time, and they are going to these technology events and discussing lessons learned and tips to success from their experiences. Unfortunately, when they are doing their creating and updating and reporting back to the tech community, they aren’t talking about user needs, goals and tasks in the least. Not one company, at least in the events I’ve attended, has talked about how they went out and did user research to understand current user behavior. They do market research, at times, but that isn’t what I’m talking about. I’m talking about the real, down low, getting to know your users. Instead, these companies talk about giving users new functionality they didn’t know they wanted or giving them functionality that they should want without knowing why or how the user might use it in real life.

Of course, in the UX world, this is a problem that we are well aware of. By not taking user behavior, tasks, needs and goals into account, these companies are designing for solutions to problems they haven’t yet defined. How can they be successful in this regard? We’ll leave that discussion for another day. The problem I want to talk about today is one for our UX world. That being, these companies have no idea who we are, what value we can bring, and that we are sitting right in front of them watching, listening, and shaking our heads in disappointment. This is a problem for our community, because it means that the people and companies that need us the most have no idea how to engage us. Thus, we are unicorns. We have the power to heal these companies “sickness”, to make their products better… but they don’t know how we do it (must be magic!). Further, we can only be captured by a virgin… ok that’s a long shot but the idea is that we are really hard to find. This is something we need to change.

So, what is our solution, how do we stop being unicorns? First thing is first, we need to be in the room. We need to be around the people whom we want to help (see UX… so you wanna work with startups for more thoughts on this). Whether startups or larger corporations, we have to get out of our shell and make our presence known. We can do this by attending events local to us, participating online in conversations that are related to the work we want to do, and ensuring we are branching out, beyond UX, in our search of knowledge.

Second, when we are in the room (or online), we need to be vocal. We can’t be flies on the wall. Instead, we need to speak up and make sure we are adding the UX perspective and educating others about the value that we bring. This, of course, should not be in a condescending way (don’t say “you idiot, you aren’t even thinking about the user.” but instead “how have you integrated the user perspective into your product roadmap?”).

Third, we need to have empathy for the business and technology folks that we want to work with. We need to understand why they aren’t looking towards UX, or if they are what are they hoping to find. A lot of companies, especially startups, don’t realize that we can help them with their product definition and roadmapping. They just think we are UI! We need to gain understanding of their point of view of what UX is so that we can solve the problem of them not thinking of UX in the early stages.

By taking these steps, we stop being that unicorn. We make our presence in the technology and corporate community known, and we make sure that those involved realize all the value that we bring. We become tangible, real, but no less valuable. Once companies are better able to find us and understand us, then it becomes easier for UX to work with the businesses that we want to. This, of course, allows us to do what we do best; help define and solve problems for the betterment of our user base. No unicorn can do that.