Marty Cagan's "Open Letter to the Design Community"

13 May 2010 - 8:16pm
3 years ago
4 replies
1121 reads
Audrey Crane
2009

Wonder if people have seen or have responses to this? http://www.svpg.com/an-open-letter-to-the-design-community/

My summary of his article:

  1. Mainly / only show execs polished work
  2. Be flexible and sensistive when introducing research -- don't try to bite off too much
  3. Research is more than usability testing
  4. Be honest about your skill set -- most people aren't equally brilliant at visual and interaction
  5. Mostly, stick to these titles: “Interaction Designer,” “Visual Designer,” and “User Researcher.”
  6. ...and then some finer points on conducting research.

 

In particular, I struggle with #1 because sometimes what I need to do in order to think through a problem and be able to design something is what Marty would consider "sausage making", but at the same time execs want to see something at least weekly, and sometimes that stuff takes more than a week to manifest in visually designed comps.

Anyway, curious about people's thoughts on that in particular or anything else in the article.

- Audrey

Comments

13 May 2010 - 11:57pm
Hilary Bienstock
2009

I agree with a lot of the points that Marty makes in this article.  For example, I think it's very smart to try to separate out the product design from the background research and have them happen simultaneously on separate tracks. And I also strongly agree with the nomenclature argument -- our profusion of names is ridiculous, makes us look disorganized to outsiders, and makes it more difficult for us when we need to, say, find a new job.

The one piece that I really take issue with is the idea that wireframes cannot be usability tested.  I think it depends so much on the content of the wireframe and the test questions, as well as on the types of users being tested and even on the moderator's skill in explaining what is going on.  However, I think a wireframe can indeed be tested to answer some basic questions -- as long as those are questions about things like nomenclature rather than about complex interaction, etc.

Hilary

14 May 2010 - 7:53am
Chris Paul
2009

Generally. I agree with Marty's points....they make for a solid primer for UX teams inside large organizations. Our UX team inside of IBM/Lotus has learned some of these lessons the hard way and have ultimately reached many of the same conclusions.

I will say the "don't show execs wireframes" statement isn't always the way to go, in my experience. I believe the key here is to get to know your executive stakeholders via regular dialog and interaction. Some will appreciate (and expect) early design walkthroughs....others can't really process a wireframe and aren't interested in anything save for the highly polished prototype. It requires deliberate trial and error to discover which. (I've taken execs through highly polished designs only to be challenged on the interaction model because they assume we're hiding flaws with refined visuals.)

In the end, I concur that your goals are generally better served with a high-fidelity prototype sooner that you can socialize with your stakeholders. Sometimes, however, this isn't optimal/reasonable/doable and you'll need to pitch something less refined.

14 May 2010 - 11:50am
jeanhand
2010

Thanks for letting me know the situation. I will expect to hear back for you and Roni. Have a good weekend. Jean

-----Original Message----- From: ixdaor@host.ixda.org [mailto:ixdaor@host.ixda.org] On Behalf Of Chris Paul Sent: Friday, May 14, 2010 11:56 AM To: jean@topdogstaffing.com Subject: Re: [IxDA] Marty Cagan's "Open Letter to the Design Community"

Generally. I agree with Marty's points....they make for a solid primer for UX
teams inside large organizations. Our UX team inside of IBM/Lotus has learned
some of these lessons the hard way and have ultimately reached many of the
same conclusions.

I will say the "don't show execs wireframes" statement isn't always the way
to go, in my experience. I believe the key here is to get to know your
executive stakeholders via regular dialog and interaction. Some will
appreciate (and expect) early design walkthroughs....others can't really
process a wireframe and aren't interested in anything save for the highly
polished prototype. It requires deliberate trial and error to discover which.
(I've taken execs through highly polished designs only to be challenged on
the interaction model because they assume we're hiding flaws with refined
visuals.)

In the end, I concur that your goals are generally better served with a
high-fidelity prototype sooner that you can socialize with your stakeholders.
Sometimes, however, this isn't optimal/reasonable/doable and you'll need to
pitch something less refined.

14 May 2010 - 1:10pm
cgoebel
2010

Having gone through one of Marty's product management workshops and gone through the process of re-structuring the product management/UE processes and disciplines, I may have a unique perspective on this. First, Marty was a voice to the product teams that I had been looking for in explaining the importance of UE in the product design process- Thank you Marty.

I appreciate Marty's comments about only revealing the minimum necessary to execs in order to make a compelling case for the design. We can not assume our work and all the guts of the methodology speak for themselves. We need to use our own user-centered design thinking to think about the audience we are presenting our case to. We need to spend time packaging our ideas for the executive audience.

We introduced rapid prototyping as part of a move to agile, the most challenging part of implementation was the extra time and bandwidth it takes to get to a high-fidelity prototype. We ultimately came up with some basic scenarios around the level of fidelity (low-fi interaction, low-fi visual, hi-fi interaction, hi-fi visual) required for different types of interactions and different audiences (product manager, user, executive).

A good product manager should be able to represent the business needs and requirements, they also should be in the brainstorms around interaction, they should be able to understand wireframes at any fidelity- (whiteboard to fully documented). So by the time you get to a prototype, things should be pretty solid, and you are using the prototypes with executives mostly for buy-in, not review.

For user testing, as others have said, it truly depends on what you are testing and the complexity of it. Example, if you are testing a specific interaction, then the site around it can be pretty low fidelity but that interaction needs to function as close to the end-state as possible, balanced with the minimal dev effort (such as using flash to test instead of Ajax if that is faster/cheaper for your team). If you are testing nav structures then maybe you should be using card sorting and have the confidence to move forward w/o testing a wireframe. It's all about focusing on your testing goals and getting a little creative about appropriate testing, less about paper vs interactive or wireframe vs fidelity.

my 2 cents.
Christina




On Fri, May 14, 2010 at 9:06 AM, Chris Paul <chrispaul@mindspring.com> wrote:

Generally. I agree with Marty's points....they make for a solid primer for UX teams inside large organizations. Our UX team inside of IBM/Lotus has learned some of these lessons the hard way and have ultimately reached many of the same conclusions.

I will say the "don't show execs wireframes" statement isn't always the way to go, in my experience. I believe the key here is to get to know your executive stakeholders via regular dialog and interaction. Some will appreciate (and expect) early design walkthroughs....others can't really process a wireframe and aren't interested in anything save for the highly polished prototype. It requires deliberate trial and error to discover which. (I've taken execs through highly polished designs only to be challenged on the interaction model because they assume we're hiding flaws with refined visuals.)

In the end, I concur that your goals are generally better served with a high-fidelity prototype sooner that you can socialize with your stakeholders. Sometimes, however, this isn't optimal/reasonable/doable and you'll need to pitch something less refined.

Syndicate content Get the feed