Work book review!

I grabbed this one for its relevance to what we’re currently working through. It builds upon the principals from Lean Startup, which I haven’t yet read. In hindsight, I probably should have read that first, but this book stands up pretty well on its own.

Who would I recommend it to? Anyone with their hand in UI/UX design, which should be everyone out there.

The premise is that designing a user experience is difficult to do in a lean environment. All too often we get caught up in the old BDUF approach. Collaboration is the key and it starts at the design phase. Someone from every discipline of your team should be involved from the start to the finish. This establishes ownership and understanding of the goal and product. There’s no more “Oh, my job is done, on to the next thing and I’ll half-assedly glance back at this other thing now and then.”

One of the key suggestions for getting great UX in a fast moving environment is to design toward outcomes rather than a backlog of must-have deliverables. Similar to how a backlog is created (or how one should be created), customers are polled. Rather than having one person responsible for that interaction, the entire team is. How? Regular user acceptance testing. Get the product in front of actual customers and see what they say. Have everyone view the results. This book and idea are primarily focused on UX, but it can go for any feature of the product; getting more people involved in understanding customers can never hurt.

My Highlights (brackets = paraphrasing, indented italics = my comments):

• “Get out of the deliverables business.”
• [Your] most urgent task [should be] delighting customers.
• It is time to break down the silos, unite the clans, and get to work.
• • Just don’t do it… From the start, create a 2nd release. Give it a real version number.The biggest lie in software is Phase II.
• You’re not going to get it right the first time.
  • Don’t try to. Make the roughest of plans and iterate. Don’t be afraid to ship UX debt, but do be sure to note it in the backlog and address it appropriately.
• To generate the best solutions quickly, you must engage the entire team.
  • And do so in a meaningful way. Don’t e-mail out a spec and ask for comments. Call out specific people for comment. The project manager should ensure that someone from each group has signed off.
• Working software [is better than] comprehensive documentation.
• [Respond] to change over following a plan.
  • Don’t code to a spec that you know isn’t perfect. Just like your code, it will never be. Roll with it.
• “Lean Startup processes reduce waste by increasing the frequency of contact with real customers, therefore testing and avoiding incorrect market assumptions as early as possible.”
• [Minimally viable products don’t have to be made from code]. Each design is a proposed business solution — a hypothesis. Your goal is to validate the proposed solution as efficiently as possible by using customer feedback.
• Their involvement must be continuous, from day one of the project until the end of the engagement.
  • This is in regard to folks from different disciplines in your team.
• Keep your teams small — no more than 10.
• Understand what the users are doing with your products and why they are doing it.
• Research involves the entire team.
• Give potential customers a chance to provide feedback on your ideas sooner.
• The success or failure of your product isn’t the team’s decision — it’s the customers’.
• Rockstars, gurus, ninjas, and other elite experts of their craft break down team cohesion.
• The answer to most difficult questions the team will face will not be answered in a conference room. Instead, they will be answered by customers in the field.
• Frequent failures lead to increased mastery of skills.
• The team’s focus should be on learning which features have the biggest impact on the their customers.
• Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome. We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes.
• The hypothesis statement is the starting point for a project. It states a clear vision for the work and shifts the conversation between team members and their managers from outputs (e.g., “we will create a single sign-on feature”) to outcomes (e.g., “we want to increase the number of new sign-ups to our service”).
• None of your metrics will be meaningful if you don’t have a benchmark in place.
• It’s much easier to pivot from a failed approach if you haven’t spent too much time laboriously documenting and detailing that approach.
• [Promote] “individuals and interactions over processes and tools.” – Agile Manifesto
• Style guides create efficiency.
• [With style guides,] reviews become more focused on the core product.
• Build MVPs that allow you to observe and measure what people actually do, not just what people say.
• Usability testing should be a group activity.
• [Iterations should have themes.]
• [You should have iteration planning meetings.]
• [Scrum meetings offer little value without the above because nobody cares or knows what anybody else is working on.]
• Proactively reach out to your [support team], product owners and executives.
  • Nobody knows the customer better than the support team. They should have regular views and chance to comment on what you’re working on.
• Your organization needs to adopt a mantra of “competencies over roles.”
• Break your big teams into what Amazon.com founder Jeff Bezos famously called “two-pizza teams” (http:// www.fastcompany.com/ 50106/ inside-mind-jeff-bezos). If the team needs more than two pizzas to make a meal, it’s too big.
• “Speed first, aesthetics second” (https:// twitter.com/ jasonfried/ status/ 23923974217).
  • Iterate, iterate, and iterate. Don’t spend too much time on any one design. Makes it that much easier to throw away when it is deemed deficient.

A decent read and pretty quick read. If you’re interested in UX in the slightest, you ought to give this a go.