31 Responses

  1. Chris
    Chris at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Great points… thanks Chris!

      Reply
  2. S. Wachter-Boettcher
    S. Wachter-Boettcher at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  3. James Eggers
    James Eggers at |

    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.

    Reply
  4. Gail Swanson
    Gail Swanson at |

    I appreciate your directness. 

    Reply
  5. Gail Swanson
    Gail Swanson at |

    I appreciate your directness. 

    Reply
  6. Scott Kiekbusch
    Scott Kiekbusch at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
    2. firefly
      firefly at |

       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.

      Reply
      1. Lis Hubert
        Lis Hubert at |

        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.

        Reply
        1. firefly
          firefly at |

          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?

          Reply
          1. Lis Hubert
            Lis Hubert at |

            Ah ha NOW I see… great points! Hmmm that could work.

  7. Daniel Hanawalt
    Daniel Hanawalt at |

    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.

    Reply
  8. Jessica Vallance
    Jessica Vallance at |

     

    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
    pretty interface.

    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
    ourselves.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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. 

      Reply
  9. Livia Labate
    Livia Labate at |

    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. 

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Thanks for the response Liv! Always love to hear your input. I hope that we can talk about this more one day in person!

      Reply
  10. Christopher Fahey
    Christopher Fahey at |

    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. :-)

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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.

      Reply
  11. Sascha
    Sascha at |

    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. ;-)

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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! 

      Reply
  12. Andrew
    Andrew at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      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!

      Reply
  13. Jess
    Jess at |

    Ah those were the CRAZY days 

    Reply
  14. Usabilla UX Tweet Scoop – Week 10 of 2012 - The Usabilla Blog

    [...] Lis Hubert talks about the de-evolution of UX design. [...]

  15. Wyrwane z kontekstu – The De-Evolution of UX Design « UX Labs - codzienne źródło wiedzy o user experience

    [...] Źródło: The De-Evolution of UX Design, Elisabeth Hubert, Elisabeth Hubert blog. [...]

  16. kiplinger
    kiplinger at |

    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.

    Reply
  17. benry
    benry at |

    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.

    Reply
    1. Lis Hubert
      Lis Hubert at |

      Thanks Scott!!

      Reply
  18. Bloggat
    Bloggat at |

    [...] The De-Evolution of UX Design This entry was posted in Uncategorized. Bookmark the permalink. ← Tidigare inlägg The difference between Google and Facebook → [...]

Leave a Reply

5 × 1 =