How We Create Our User Experience

Defining a user experience for us starts with clarifying the problem to be solved for the user and why it is worth it to us to do this. Nothing happens until this is clearly understood. We measure the worth of solving the problem by the measure of success, typically one of our key performance indicators, that we intend to achieve by creating a solution to the problem at hand, for our intended user. Once the problem is clearly defined, and the ROI for solving it is clearly understood, the problem is elaborated and clarified in jobs to be done language. All of this happens in text, with dialogue, in a doc. No prototypes, sketches, or anything just yet. We work through coming up with a common definition of what we are going to try to do, up front. Text and talk is cheap and fast, and the investment low, which guarantees no egos get attached to an idea.

Once the text is defined and agreed to and we all have common language to describe what we intend to do and why, we then start sketching the storyboard. We put pen to paper, or in our case stylus to tablet, and with absolutely no fidelity we draw how it might work, and we mock the flow by putting the drawings into Google Slides so that by clicking specific links we can walk through our story as we intend our User to walk through it. Once again down and dirty fast, nothing is made pretty, no investment in anything is allowed, everything is relatively inexpensive and nobody gets bent out of shape if something is scrapped and thrown away.

And now that the problem is defined, the intended ROI understood, and the jobs to be done stories described in sketches on a Google Slides storyboard of sorts, we now know with relative certainty what we want to make. And all along the way (from text to sketch) the technical types who know what is possible, and what is not, are reviewing and contributing to the story. And with their contribution confirming that it is possible for the investment at hand and that they deeply understand what is trying to be achieved. Now we can invest in pixels and create the actual experience in HTML, throw in some CSS, and where we have to, add a little Javascript to make it flow. We go a little deeper at this point and invest in making sure that the proposed solution takes into account the W3C Accessibility Guidelines to confirm that our intended solution is open and accessible to all. And we publish this HTML for as many people to critique as we need to, and we can afford with the ROI we have, to solicit. The team, the company, other UX types and Product Owners from other teams, and our community of Users, whoever we feel we need to solicit to confirm our intended solution. We don’t do this randomly as each solicitation is expensive. We go as far as we need to go to confirm and be comfortable with the hypothesis we are intending to prove. If we are comfortable, we work it out within the team, not so comfortable, another team or two, still unsure, out to the community we go, and for sure we share with the company on at least an FYI basis to keep everyone in the loop as to what is coming. And if we are really unsure and we have a really big problem to solve, off to a design sprint we go. But the design sprint is our most expensive confirmation and should be called only for the really BIG PROBLEMS to be solved.

At this point the Developers take the HTML and CSS, plumb it up to the back end, and make it speedy and shiny. Everything follows the rule of 2 as much as possible. It takes less than 2 clicks to make something happen and each click happens in less than 2 seconds. And once again, they publish and share the final results as far as we need to, and come final review, out to the community it rolls.

Bang! We are done. NOT SO FAST. We delivered but we don’t know if we solved the problem, or if we achieved the measures of success that we set out to deliver. Yes, we released, but the most important step is about to happen, the learning and validation for what we delivered needs to be done. We wait the pre-allotted time that it will take to gather the data from the deployed solution, and then we spend as much time, generously given to this most important step, to validate and learn from how it was received, and, at the very least we come up with 3 or less “things” that we gleaned from the data, that we improve upon next. We build, we measure, and then we learn, this is how we create our User Experiences.