Category Archives: Design

What Would You Like?

Design, Project Management, User Research, ,

Discovery phases are often started by asking stakeholders, “What would you like [application X] to do for you?” Once they get over blank slate syndrome, a laundry list of wants, needs, brainstorms and brain-farts pours forth. Someone hands off that list with the title REQUIREMENTS on it. A project scope is born.The document is handed to the business analyst who is told “This is what our users and stakeholders told us they need.” The BA validates the requirements asking “How important is this feature?” “We must have it.” say the stakeholders.  Everyone puts forth their best efforts and designs a smashingly feature rich design. The stakeholders look at it and give their stamp of approval.

Then the development estimates roll in. Reality steps in and suddenly you have to revamp the design to something that costs 40% less. We’ve all been there.

It’s at this point that the team starts asking questions that let you determine what’s in or out.

  • How often will this feature be used? By Whom?
  • What value does it bring to the user? the business?
  • What is the impact if it’s not included?
  • How great is the cost of human error?
  • How much money is currently being lost because this feature is not there?
These questions should be asked before and during design. Talk to users. Find out what they do, what issues they are trying to solve. Find meaningful criteria by which functionality is scoped so that you don’t end up including every idea that the team has. If a feature saves someone 1 hour once a year, is it worth developing? Everything added increases the cost of complexity.
Without meaningful prioritization criteria, scope is a playground for political bravado and never-ending debate.
Save your sanity. Do some user research. Build some metrics.
 
Of course, if you’re agile, you shouldn’t have this problem.

To Code or not to Code, that is the Question.

Design, Education, ,

There’s been much debate lately on whether designers should write code. This article from Jared Spool seems to have stirred up a hornets nest. I started off my career doing both design and front end code and enjoyed both. But doing both made me feel like a bit of a hack. I just wasn’t hard-core-geek enough to invest as many of my nights and weekends basking in the cool light of the monitor’s glow as becoming a ‘coder’ required. And I was always being distracted by my interests in human factors and the evolving field of user experience.

So I focused on my UX tools and built my career of designing good experiences. I love it. I’m one of those lucky bastards that does something I enjoy for a living.  My technical knowledge certainly makes me a more effective designer.

I’m sure there are benefits to being a ‘non-technical’ person. Perhaps your brainstorms are less tainted by thoughts of what is possible to build. Perhaps you can be a little more focused on what’s good for the users. Maybe. But is not being able to speak a developers language hurting your chances of getting the design built?

I’ve had countless conversations with developers talking about what is possible, what is easy vs time intensive. Knowing enough about how things work under the covers lets me play diplomat and find the good concessions. I love the collaboration. So many times the ‘techies’ have brought UI gems to the table that really bring the design together or take you down a path you didn’t notice was there before.

Let’s not forget that coders are the users of our design work. We should take the same measures to understand them that we do our website users. We’ll all be more successful.

That said, I occasionally miss getting my hands dirty, doing the making not just the designing. And things have changed a bit in the past few years. HTML5, CSS3, and jQuery have come on the scene and I feel a bit like I missed some episodes of my favorite show.

It would be a shame to let the technical skills that I have degrade irretrievably, so I’m packing up the family and heading to Minneapolis for An Event Apart 2011. Two days of getting my UX groove on followed by A Day Apart to get a crash course in HTML5 and CSS3. I’ll let you know if being a designer who can code turns out to be a good or bad thing. Maybe I’ll see you there!

Multi-tasking or Juggling?

Design

I’ve frequently been part of long term projects, finding myself working on a single initiative for months, if not years at a time. I can testify that once you transition to maintenance and long term enhancement strategies things can get a little stale. The creative excitement dwindles and long for a new project to throw my energy into. But in the beginning, having one project can give you time to focus.

Recently I’ve started working on a few endeavors simultaneously, creative energy bouncing from one thing to the next. I wonder if switching between projects will turn out to be a huge time vampire, or be a great way to keep the creative energy flowing while other projects start to drag.  I suspect that I’ll find it inspiring as it often helps to divert your attention from a design problem for a little while and let your subconscious chew on it. The best ideas come to you while you’re doing something else.