×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

i'm now sitting in a session entitled "hello? is there a user in the house?" with .  amy is a user interface designer and has been around the block with regard to user centric design...something that is lacking in probably most software development processes.

here's some of my raw notes/thoughts.  if you've done user-centric design before, most of this will not be new.

creators == consumers (understand who they are building for because they are building for themselves) -- this is what makes some projects successful in the geek world -- we develop for what we want as we are the users.

lots of successful projects in open source...lots of unsuccessful.  unsuccessful because they aren't taking the user in mind.

ui design is primarily about interpretation, empathy, aesthetics and editing (most important).  how do you ensure a project makes sense: know your audience. using blogs, who is the user? author, reader, reader/author, stop-in/regular, lurker/commentor, consumers via APIs and syndication?

side note: someone is literally weaving some type of string in this session...weird...oscon is the only conference where i see this type of diversity (and people bringing their newborns).

here's some critical steps in involving the users' perspectives in design:

    • use persona for guiding your development process.  create the target users (and potential edge users).  define them well.
    • use task paths (use cases)...task paths have scenarios and goals. 
    • user interviews (subject matter experts) [what do you do now, use, when, what do you like/not, tell me about your day). 
    • observation and watching your users in their habitat. 
    • research.  look at competitiors, look at leaders in your space.
    • prototyping - use paper-based prototyping (audience member mentions DENIM).  before you write code, test some designs on paper, etc.  invest in changing drawings before you invest too much in changing code :-)

some audience members commented/questioned about changing designs of existing applications.  some good suggestions i heard:

    • gradual changes (if possible, i think in real world budgets and pointy-haired bosses this might not be easily accomplished) -- implement small, effective changes gradually rather than dump completely new experiences on the users
    • enable 'classic style' implementation.  this audience member pointed to when windows xp came out there was an option not to use the new design and get winxp but with the battleship gray user interface.

overall a good session.  i've hung around some folks that are really good at user interface/experience design and felt that i've already absorbed this information -- but it was clearly a good presentation solidifying that concept as well as it looked like a lot of people hadn't used it before.



DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.