Tackling the Big Problem.

Frequently as Designers, Product Managers and Development Leaders we face “The Big Problem”, this is particularly true in enterprise application development.  How do we go about eating the elephant as they say?  Here are a few ways to break down the bigger parts in an order and fashion that lets you and your teams create effective solutions (you will know they are effective by what your metrics tell you).

What follows below is the outline of a process that I follow whenever the opportunity to innovate presents itself.

Ask the important questions.

Situational Awareness + Audit

• Where are we?  How did we get here in the first place? - ask the questions if you don’t already know.
• Who is our user?  What do they care about, what is most important to them?
• Why are we doing this at all?  What core belief is underlying our desire to take on such a big task?
• Take stock - what are all the parts and pieces that are currently in place?  Inventory experiences, infrastructure and users.

Observe and Analyze.

• Find sources of information and dig in.
• What do current users or customers tell us?
  • What are the willing to say?
  •  What do they do and what do their actions tell us?
  • What latent needs can we uncover? 
• What does data tell us?
  • What sources do we have?
  • What trends can we observe?
  • Is there other data out there that we need, what tools might help us dig deeper?
  • Is there a gap between what data tells us and what users say?
• How do they disagree and why?
• Is one source more valid than the other?

What problem are we trying to solve?

• How does solving this problem align to our core belief?
• Establish a goal - should be small enough to be achievable in a reasonable period of time but big enough to make a difference in the user’s life.
  • Figure out how you are going to measure the goal, how will you know you have been successful or you have failed?
• What are the biggest challenges to face in achieving the goal?
• What will happen if you don’t achieve it?

Map the Experience.

• How do users move from the beginning of the experience to a natural end?
• Where are the critical touchpoint for your users and customers?
• Where do users:
  • Make decisions?
  • Feel the greatest impact?
  • Experience the “Brand”?
  • Become frustrated?
  • Leave?
  • Experience delight?
• Pick an area of the experience to focus on
• You can’t solve everything at once or address all issues in small batches so focus.
  • Pick the most critical element in the experience and/or the most bang for the buck (hopefully both).
• Document the experience map and keep it visible

Design and Test.

• Low fidelity sketches (lots of them)
  • Everyone on the team is involved and picks up a pen, pencil or whiteboard marker.
  • Design and Design Thinking are no longer the jurisdiction of the design team, everyone is a designer.
• Get Feedback - this is probably the most important step in the entire process.
  • Early and often
  • Bring users into the design process, show them what you are thinking about doing on their behalf and get their input.
  • Give them a whiteboard marker, let them participate
• More sketching but iterative
  • What worked well?  
  • What did users respond to positively or negatively?
  • What worked as planned and what was misunderstood or misused?  Can you leverage that?
• Prototype
  • Build out more complex flows, make it “clickable”
  • Study the problem holistically, what things slipped through the cracks in the initial sketch work?
  • Test again, get feedback, iterate
  • Test some more.
  • Figure out what is good enough (MVP/Product Market Fit/etc.)
    • Must benefit the underlying belief
    • Must address a critical user need or experience issue
    • Must be measurable

Build

• Create whatever design documents are necessary but err on the side of discussion instead of documentation
• Write code, test cases and setup deployment environments
• Ensure measurement “hooks” are included and data can flow to dashboards or other outputs.  No data collection is not acceptable.

Deploy and Measure

• Let users in and begin detailed observation.
• Important questions to answer:
• How does the new experience improve over the previous?
  • Does this move us towards our goal?  Does the solution benefit our core belief?
  • What didn’t work as planned?  How does what we observe align to what our testing told us?
  • Validate the data against the goal, did we succeed or fail?
  • What next, do we need to iterate more or have we established a baseline of success that will allow us to move forward to the next step of the experience?
• If so, what’s next?  Refer to the experience map and layer on the finding from the current experiment.
  • If not, what’s failing and why?  Ask your users if its not obvious.

See how this process has allowed us to craft transformative experiences in enterprise applications.