prototyping

BayCHI: Turning Mediocre Products into Awesome Products (Zurb)

I recently attended a BayCHI talk entitled “Turning mediocre products into awesome products,” led by two members of interaction design consultancy Zurb.

Amidst screenshots, photos, and Star Wars references, Jonathan Smiley & Jeremy Britton told the story of how they designed & launched a new product in 4 months. My notes from the talk follow:

“Design for People”

Design Principles:

  • Small details can change the world
  • Craft matters (you need to be able to design and build it!)
  • Everybody should be able to design - “Can’t draw stick figures? Pick up a yellow pen and highlight something. Can’t pick up a yellow pen? Pick up a red pen and cross something out”
  • You need people
  • Ask “why” five times
  • We love businesses with a long-term view
  • UX design doesn’t exist (as a discipline) since you can only control ½ of the experience; the other person brings their own context to the table

What do you need to make awesome products?

  • Lots of enlightened trial & error
  • Customer feedback ASAP
  • Team behind it - buy-in, want it to succeed

After this talk, challenge yourself to:

  • Design 1 more prototype
  • Demo with 5 more real customers
  • Create 1 more team advocate

The “lone genius” doesn’t exist - everyone’s heard fables of insight happening overnight, but we know that’s false & lots of work goes into every great invention

- ex: the lightbulb

- ex: Steve Jobs (has deep intuition for people, iterates, fails)

Building Verify

Week 1: Sketches

  • multiples -> no ego bruise (don’t feel bad about ones that suck)
  • fast -> in a flow (don’t need to set up anything beforehand)
  • cheap -> easier to repeat
  • disposable -> just a spark (easy to chuck bad stuff)
  • opportunity -> “wow” moments (accidental moments of insight)

Sketching becomes the “requirements” doc - better than a huge doc because they look less intimidating so people respond to them more honestly & productively

Month 1: Prototype

  • Front end code in ~1 week
  • “Spec” - Created a single page that lists out every screen in the app in order to build the app, including thumbnails of what they screens will look like. Divided up by user task. Links directly to the pages.
  • Literally scanned, chopped up, and dropped hand-sketched icons into the app

Month 2: Test Ideas & Iterate

  • presented at “Demo 2010” conference, got lots of excitement & signups
  • shared with users & iterated

Month 3: Private Release & Feedback

  • beta with 200-300 users
  • once people were using & paying for it, feedback came in strong
  • continued to learn user behavior - when added links to more tests at the bottom of the “Thank You” page, they found users would usually take another test because they’d found the last one to be so quick & fun

Month 4: Launch!

Additional Reading Material

AS3: event.target vs. event.currentTarget

I just figured out how to solve an ongoing bug in my AS3 code.

The problem: I added a MouseEvent.CLICK handler to a Label. Whenever I clicked on the label, the event would fire– but when I called “event.target” in the event handler, it would return a TextField instead of a Label. This meant that to get the Label, I had to come up with messy workarounds like checking the type of the event and calling its parent if it wasn’t a Label.

The solution is actually quite simple: rather than calling “event.target”, use “event.currentTarget” to get the object that originally had the event handler registered to it (in my case, the Label). I wish I’d known this earlier! For further reference regarding event propagation in Flex, see the Adobe documentation.