Lean UX in an Agile Enterprise Organization Part 1

Enterprise UX - Dave Landis - Lean UX - Better Together graphic

Dave Landis’ Lean UX graphic is well known and there’s a reason – it helps paint the picture of how UX work gets done within Agile. It’s a great illustration not just for UXers but Product Owners, Business Analysts, Developers and Business Stakeholders.

There may be better graphics but this is the one we use and it helps us map our groups and activities to the overall process.

We break out this iterative process into four main sections: Discovery, Hypothesis, Build and Feedback.



Step One – Discovery

A critical first part of the UX process is to understand the user need versus reacting to the user want.  This is accomplished through the discovery step.

Enterprise UX Discovery

What is done?

Identify Business Needs through:

  • Mapping Business Requirements to Business Value – This step is basically getting your head wrapped around what the business goals are and identifying the initial requirements to meet those goals. The key element from a UX perspective is finding the true business need vs. the business want. The business often times will already have a solution they think will meet their goals. That’s a good place to start but UX needs to validate if that proposed solution is really going to provide the value that the business needs.
  • Ghosting Sessions – This is where the UX team physically goes out and sits with our users to understand what they do today and identify potential improvements.
  • Brainstorming – Internal discussion of potential solutions within the UX team, Product Owners, Business Stakeholders and our users.  This is more focused on the what vs how.
  • Conceptualize Solutions – Lots of white boarding and mock-ups of potential solutions. This is really an extension of the brainstorming step as we now create some sort of visual artifact to generate discussion.

Who is involved?

  • UX resources
  • Product Owner
  • Business Analyst
  • Business Stakeholders
  • Users

When?

  • This is done whenever a new request is generated from the business or product team.
  • This step happens well before Sprint Planning, Epics or User Stories are finalized.  It’s great if this is happening before backlog grooming or is separate offshoot of backlog grooming.  The primary intent is that this step is well before development and that it has enough lead time for the UX team to fully understand the current-state user experience as well as clearly identify areas where improved UX provides business value.

 



Step Two – Hypothesis

The next step of the Lean UX process is geared around creating visual artifacts (mockups/prototypes) of proposed solutions to generate feedback from all required stakeholders.  Often times this is what product teams want to start with.  They want to see mockups!  The problem is that without the discovery step those mockpus are built on assumptions and/or the product team’s understanding.  No one wants to build something the wrong way but often times a Business Analyst’s questions are more aligned with the business want vs. driving towards understanding the business need.  This is why UX discovery is so important and should not be skipped over.

The other critical aspect of the Hypothesis stage is that it is iterative.

  1. You have a hypothesized solution
  2. Build a mockup/prototype
  3. Get feedback
  4. Revise hypothesis … rinse and repeat

The cadence and time allocated to this step should be time-boxed so that there’s an agreed upon “deadline” that a solution is considered ready for development.  Depending on the scope and timeline of the project this can be anywhere from a couple of weeks to a couple months. The reality is that the product teams will want to give you a couple of days …. push back!!! UX needs time to build and validate.  Just as developers and QA need time to do their work, UX needs time to do theirs.

Entrprise UX Hypothesis

What is done?

Mockups and/or Prototypes are created to:

  • Validate Business Goals/Needs – pretty straightforward but this is to make sure that the business is happy with the solution we are proposing and if it aligns with their original business goal.
  • Identify opportunities for re-use  –  The Business and Developers love re-use because it lowers cost and reduces developer time.
  • Business / User / Developer Feedback – This is critical to make sure that all feedback is taken in to account and is also communicated across all stakeholders. This is where real alignment happens.  Developers get to push back on a specific UI pattern because it’s going to blow up their sprint with significant amount of extra work.  Business can prioritize that they “really” need specific functionality in release A and can wait on future enhancements for release C.  UX is responsible for advocating for delivering a highly usable product and not just a functional product.  In an enterprise environment you may have a user group that can actually participate in these sessions directly.
  • Usability Testing – The single greatest advantage that Enterprise UX has overall all other UX environments is that you have access to the users! This is where UX can leverage measurable usability testing metrics to support their arguments. The business is going to push-back with scope, timeline and cost. Developers will push-back with effort and number of sprints. UX needs to push-back with something other than “UX best practices”. If you can show strong metrics around efficiency and productivity with a good UX versus a poor UX – the business will listen.

Who is involved?

  • UX resource
  • Product Owner
  • Business Analyst
  • Business Stakeholders
  • Users (Usability Testing)
  • Developers

When?

  • After Discovery
  • Backlog Grooming

 

How we use Lean UX within an Agile Enterprise Business Part 2

 

What is UX Alignment

I have over 20 years of UX experience in one form or another. I’ve been a web application developer, UI designer, UX designer, UX engineer, UX architect, UX manager and I’ve even taught web design classes. Based on my experience, the most challenging role I’ve had is how to align User Experience within an Enterprise organization.

UX Alignment will be a place to share what I’ve learned that works and what doesn’t. More importantly, I hope that it’s a place that you can share what works and what doesn’t for you!

Creating great user experiences in whatever role you have is a challenge in any environment but it is extra special in a large enterprise organization. Feel free to ask questions and share your ideas.