Example Case Study
How I can create solutions for you.
“My power bills are too expensive.”
Problem Statement.
Step One: Define The Problem
How does one start the discover phase? It’s simple – ask questions and gain clarity.
Who is asking to lower their bill & why?
Why is the bill too expensive?
What are the KPIs?
What determines success?
What is in and out of scope?
Who are you working with?
These entry level questions, plus many more, can help set the parameters of the problem. It helps me quantify, what does expensive mean to our customer and what is she actually asking for? Is she asking for a lower bill or just complaining?
By setting the win and lose conditions early on expectations are clearly defined.
SteP Two: The Five Whys
Now it’s time to talk to our customers, and ask the “Five Whys” to get to the root cause of the problem.
In conjunction, if there’s data available, I like to examine the data to see if it is out of control (is not normalized).
The combination of doing gemba walks, listening and being respectful with the customer as I observe them, and hard data begin to paint a picture of what our root cause of the problem could be.
It’s one thing to treat the symptoms of a problem, but I prefer to find out what the source of a problem is, and treat it at the source.
Step Three: Discovery
Now that we’ve defined the scope for the project and validated that we are targeting the correct user group, it’s time to define personas.
Who are we targeting? What are their ages, preferred genders, income, etc.
All of this information is gathered and is used by myself and my developers to act as a stand in during the agile development cycle. I often ask myself:
Will this decision help or hurt my customer?
The answer to that question, through using my defined persona, will guide all decisions moving forward.
Step Four: User Flows
It’s one thing to know a process and another thing to document a process. Documenting a process through user flows and diagrams paints a clear pictures of wins, losses, and most importantly – Opportunities for growth!
Step Five: Wireframes
When I wireframe, I keep them fast and cheap. It’s about brainstorming and placement, not the exact final solution. This is also a great step to pause and test with users or to get feedback from stakeholders. Wireframes are made to be loose and free, so that with little investment, I can scrap whole concepts in favor of solutions that just work better.
For this sample project, I decided that since our user group all had phones as their primary means of consuming data, that some type of notification would work best to inform them when they reach various thresholds in regards to their power usage.
Step Six: Mockups & Prototypes
Mockups are one of my favorite parts of the process, because it’s when all of the research and planning first starts to look like a real solution. Mockups, high fidelity or low fidelity, give the user and the stakeholders a good idea of what the final solution will fell like when they use it. Prototypes and mockups are also excellent companions to business rules and requirements written into stories for developers to consume and QA to check against.
In our sample project, I’ve decided to mockup up two variations for usability testing in the next step.
Step Seven: Usability Study
This is the really fun part. I typically conduct my own studies with a partner and occasionally a stakeholder and an observer to gain buy-in. I read from a prepared and consistent script and do not help the user, but ask them to complete a series of tasks. After the study, I administer various suveys depending on the need of the project. These include:
Net Promotor Score
SUS Scores
Completion vs Failure Ratings
Custom Surveys to meet our project’s needs.
I think take all of this data, compile a report, and present the findings to the stakeholders. Together we decide on what to build, and it’s off to development to code.
Step Eight: Deploy, Measure & Control
The time has come for the solution go to production and be consumed by our end users. At this phase we focus on communication. I work with my team to make sure that users know of this feature, are educated on it, and trained on this feature if it’s needed.
When you deploy a feature, you’re not done, there’s still a few steps left! Now we measure. How did our solution do compared to our original data? Did we solve our root cause?
If we did, now we must implement a control. I recommend a plan for continuous improvements to the application so that we know we have truly solved this problem.