Category: User Experience

Lean UX is about communication

November 25th, 2012 — 11:33pm

There are few articles linked below on Agile & UX that I really love. The common theme between them is the replacement of documentation (PRD, Func Spec) with team communication. Teams develop a shared understanding as they work together. The user’s voice is championed by UX but because other disciplines are involved from the start leaps can be made in how a feature or workflow is built, usually more technically sound with better quality.

In The new user story backlog is a map Jeff Patten describes how story mapping creates momentum for the team and is the basis for presenting the fundamental direction to the team. The team works together to understand the problem and user goals and plans what needs to be done first to be able to create a minimum viable product that can be tested.

In “Lean UX: Getting out of the Deliverables Business” Jeff Gothelf describes how UX Designers can lead the charge, and work with the scrum team, to create better results and software than could have been done otherwise.

Comment » | Agile, User Experience

My experience with UX and Agile

November 13th, 2012 — 11:15pm

Recently I’ve been considering how I would help other user experience designers work with the my product team as collaboratively as I have for the past two and a half years…what do I do?…how have I been successful? The feedback I’ve gotten is that I’m an integrated part of the team – appreciated by the engineers I work with almost to the point of relief. This means that I work with the team to make decisions daily. Ideally these decisions are informed by domain knowledge, and/or by direct user feedback. Design decisions have to be grounded in the product, division goals, and practical considerations of current and future state of technology. Not every decision can be researched, and designers have to trust their instincts as designers and their knowledge/history on products and workflows to make decisions.

During the course of our most recent release, I set up continual research with a set of senior stakeholder users that I consider product advisors. These users tend to be evangelists, or could be so, in their companies and want to work in 3d and understand the potential of modeling large scale infrastructure projects in 3d. Continual research means ongoing meetings, either one or two sessions per month with ten or so users. This roughly equates to 3 – 4 hours of informal interviews per week to discuss requirements, review design concepts, and to perform usability audits of prototypes.  Conducting continual research is hard, but keeping it informal makes it manageable, and keeps me in touch with how our key customers are using the product currently and where there are gaps in the workflows they hope for, and provides a mechanism for concept direction and design validation.

Knowing the medium I work in has also been a critical component, and allows me to create the best interaction model within the current state of the technology….handing Van Gogh a stone block and a chisel would would have perplexed him, because its not the medium he knew and he would likely have struggled.

Let’s break this down…

What does it mean to be an integrated part of the team?

  • You are not the defacto expert, and you don’t need to be
  • Start with the assumption that software engineers, QA engineers, product managers (and others stakeholders) have addressed detailed problems in the domain and have a deep understanding, and therefore are a source of input
  • Make decisions on the fly with the team on a day in and day about basis. If you’ve done research you tend to lead the discussion
  • Don’t be afraid to fail. Agile means you can correct mistakes
  • You are an interaction designer making software. You are not a mock-up designer producing documents. Testing early mockup is great for validating design concepts and design direction but fails terribly for testing interaction design.
  • Testing working end-of-iteration prototypes makes you a better UX designer.

But making design part of the scrum team means I’m losing authority as a designer….

  • This could not be further from the case
  • Believe it or not, engineers want the best experience, set of workflows and features for the user as possible
  • Talking to users continually means you understand how they think
  • Engineering will look to you as the lead in making decisions on the scrum team because of your thinking and the discussions you’ve had with users….
  • Because the nature of agile means breaking down stories to atomic levels, it is up to UX (and product managers/product owners) to make sure the big picture is not lost when piecing together user stories back up to the epic and theme level

Comment » | Agile, User Experience

Breville Power Cord

March 24th, 2010 — 12:03am

One of my favorite design details of any product I’ve seen is the power cord that comes on the Breville Juicer. Instructions always tell you that you should remove the power cord from the outlet by pulling on the end, rather than pulling on the cord. Breville creates a simple affordance that not only makes this incredibly clear visually, but makes it the best way to pull it out. Many  power cords are difficult to remove, and pulling on the cord is simply easier with the added leverage. Breville does not really advertise this in any way that I can see, but there get the idea in the photo below. The circle tells you emphatically that it should be pulled….

Breville Power Cord

Comment » | User Experience

Back to top