I've been thinking on this for a while and I admit the idea's still only half-baked. But I thought I'd toss it out to the list for commentary.
I think there are three kinds of design for product features (web site features also, not so much with intranet features). 1. Core design. This is "the good stuff" that we all want to be doing, that we have tools and techniques aimed to support (personas, contextual design, et cetera). We write and speak about this design all the time, and we behave as if it was the only kind of design we do. However, we end up designing other things, and those other things often eat up a lot of design cycles. 2. Demo design. This is particularly prevalent in enterprise software or situations where the customer (person who writes the check) isn't the user (person who works with the software on a regular basis). This design is not for things that support user goals, or that help people complete tasks with the software. Or for that matter, any other metric that's used to judge features in category 1. This design is all about "does it look good on a demo?" "will it impress customers?" For example, a program might support complex layout movement/arrangement features for its components. Salespeople will use this to show off how whizzy and powerful the app is. But real users (or at least 95% of them) won't change the default settings or may even be given a 'corporate look' and not allowed to change it. When doing this design, all the user research in the world is irrelevant. Most good interaction design techniques aren't much help either. If it looks good and sales people can memorize a great spiel around it, you design it. (or at least, I do, grimacing all the way. Dunno about anyone else.) 3. "Checklist" or "me too" design. This happens a lot in situations where products enter into a highly competitive space, or one where there's a dominant or well-known leader. If you want to compete in the market space then you end up needing to check off certain features on a head-to-head comparison. It's not usually an opportunity to apply innovative design - everyone knows what the feature is and expects it to behave in a certain way or look a certain way. The fact that you can produce a more efficient or aesthetic design isn't really at issue here - doing so would run counter to peoples' expectations and that's not going to help. A classic example here is entering mailing addresses into a form. In the US, having the Zip code uniquely identifies the state, and in over 95% of cases allows you to know the town as well. And yet, every single form asks you for city, state, and then zip code. Why? Because it's not a differentiating feature. Nobody cares that it's 2/3 wasted effort on the user's part. You have to have a way to capture mailing addresses, but the usual interaction design goals don't really apply here. Just do it the standard way. (where here "standard" really means "expected"). Does this match up with your experiences? Is there another major category I'm missing that you find sucks up significant design cycles on your projects? --Alan ________________________________________________________________ *Come to IxDA Interaction08 | Savannah* February 8-10, 2008 in Savannah, GA, USA Register today: http://interaction08.ixda.org/ ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://www.ixda.org/unsubscribe List Guidelines ............ http://www.ixda.org/guidelines List Help .................. http://www.ixda.org/help
