Highlights from Lean UX

We went over to the client’s office and spent an entire eight-hour day going over each and every pixel and word in that deck. When it was over, the client clapped (really). They loved it. We were relieved. And we never looked at that deck again. Six months after that meeting, nothing had changed on the client’s site. I don’t think they ever looked at that deck again, either.

It’s also for developers who understand that a collaborative team environment leads to better code and more meaningful work.

each principle detailed here will help you build a product design organization that is more collaborative, more cross-functional, and a more useful fit for today’s reality.

Insight on each idea is brought in from all relevant disciplines earlier in the process.

Translated to Lean UX, this concept means creating only the design that is necessary to move the team forward and avoiding a big “inventory” of untested and unimplemented design ideas.

It’s worth noting that there’s been a lot of backlash in the design world against measurement-driven design.

The most effective way I’ve found to rally a team around a design direction is through collaboration.

These conversations may seem awkward at first; after all, you’re breaking down time-tested walls between disciplines.

That’s why you should include a researcher on your team if you can. Just don’t outsource the work to that person. Instead, use the researcher as a coach to help your team plan and execute your activities.

Here’s why: it becomes very easy to create a situation in which the entire team is never working on the same thing at the same time.

The people on the team generally performed in their area of expertise/strength but were supportive of other specialties and interested in learning new skills.

I looked for opportunities to work in real time with other people on the team (such as developers and the product manager) and rough things out as quickly as possible at the lowest responsible level of fidelity.

At most, these teams plan an iteration or two ahead. This perceived “short-sightedness” tends not to satisfy most high-level managers.

Keep the conversations focused on outcomes (how you’re trending towards your goal), not feature sets.

The more discrete a person’s job is, the easier it becomes to retreat to the safe confines of that discipline.

Too often, people in organizations discourage others from working outside the confines of their job descriptions.

Every team member possesses a core competency—design, software development, research, etc.—and must deliver on that skill set. However, he or she may also possess secondary competencies that make the team work more efficiently.

Designers must open up the design process.

The entire concept of design as hypothesis immediately dethrones notions of heroism; as a designer you must expect that many of the your ideas will fail in testing.

Don’t waste time debating which type of artifact to create, and don’t waste time polishing them to perfection. Instead, use the one that will take the least amount of time to create and communicate to your team.

Designers can demonstrate their problem solving skills by illustrating the path they took to get from idea to validated learning to experience. In doing so, they’ll demonstrate their deep worth as designers.

To use the concept of UX debt, write stories to capture a gap analysis between where the experience is today and where you’d like it to be.

Instead, their engagements are based on simple time-and materials agreements, or, more radically, on outcome-based contracts.

Some managers may be threatened by proposals to work in a new way, which could result negative consequences for you.

If your manager still doesn’t see the value in working this way and you believe your organization is progressing down a path of continued “blind design,” perhaps it’s time to consider alternative employment.

Leave a Reply