modeling the experience

Challis’s model of experience design suddenly gave me the image of every project manager I’ve ever known, running […]

Challis’s model of experience design suddenly gave me the image of every project manager I’ve ever known, running around, desperately trying to keep the various people they are working with from slipping away like jello in a fist…

4 Comments

Add Yours
  1. 2
    Brad Lauster

    I feel like I’m missing the context.

    Challis – I know you’re out there…can you explain the difference between design (with a little d) and Design (with a big D)?

    I have lots of issues with this diagram, but let’s start there.

  2. 3
    .jeff.

    I’m not Challis, but my interpretation of the model…

    All of the things in the dark gray uppercase “Design” area relate to visual design — interaction, navigation, graphics, etc. All of the things in the lowercase “design” relate to non-visual (or predominantly non-visual) design. Programmers are still “designing” when they’re writing code, it’s just not “Design” in the traditional art sense.

    I like the distinction because normally the lowercase design is not though of as design — it’s called marketing, engineering, programming. Those things definitely do influence the overall user experience, so they definitely should be included in a description of what goes in to experience design.

    (Of course, I could be interpreting this all wrong.)

    We discussed this diagram last night at the StLouis IA get-together. In general, people seemed to like the diagram. There were a number of things that we noticed were missing. Andrés noticed that copywriting was a big thing missing. I didn’t like the idea of fleshing out every little detail of the uppercase-Design side while lumping all of the technical people on the lowercase-design side into “Web Programmer” and “Technical Architect,” when you could break it up into client-side scripting, server-side scripting, server architecture, database design, etc.

    So, while there are those (and a few other) nitpicks I have, overall, I think it’s a good diagram and can help people to understand the relationship between all of these different positions. Of course, most people (myself included) haven’t ever worked on teams with most of these positions. When you’re on a team of 3, and those 3 people are in charge of everything from color palette to server configuration, well, you cover many bases, so the (relatively) small distinction between a number of the different roles is lost. On most projects I’ve worked on I’ve played at least 5 of these roles simultaneously, and I’m betting that’s the same for most people who are in the IA realm.

  3. 4
    garrick

    Ahhh, big ‘D’ and little ‘d’. This discussion so quickly devolves into flaming. It’s all about how “design” is defined. From my perspective, “design” has been co-opted to pertain to only things traditionally relating to the all powerful “Graphic Design”. It gets so murky when applied elsewhere. I have a hard time defining “d/Design” as anything more specific than “managing the consequences of human behavior.”

Comments are closed.