Reflection – Visualization

Challenge

I work for a Payment Solutions development company. We are developing a mobile payment solution that will  allow customers to pay with their cellphones even when they are in store. After having some preliminary  thoughts regarding the solution architecture I wanted to get feedback from a group of stakeholders whether  I was trying to solve the right problem and that the solution involved the expected players. Furthermore, I  wanted to use this information as a guideline for solution architecture.

Selection

Aiming to achieve a single understanding of the issues involved and trying to get as many requirements as  possible from potential users, I have chosen the Visualization tool or Visual Thinking. The idea was to print the  same image on everyone’s mind so that we could discuss the details and alternatives from the same baseline.

Application

Following the Visualization process proposed by Dan Roam on his book “Back of the Napkin”, this task should  iteratively go through four phases: Looking, Seeing, Imagining and Showing. As we have been working with  this kind of solution for a while, the looking phase was quite straightforward as we had plenty of material and  context information available. The seeing phase required me to analyze the situation under six dimensions:  Who/What, How much, Where, When, How and Why. For each of these seeing dimensions I had to follow the  SQV1D (read squid) model to imagine the proper level of abstraction (high/low) that would be more adequate  to my audience among Simple/Elaborate, Qualitative/Quantitative, Vision/Execution, S1ngle/Collective,  Future (Delta)/Present. As I wanted to discuss how things would flow but with several different kind of  stakeholders, I chose the flowchart visualization tool with high-level elements.

Insight

After adjusting my understanding of the problem with the feedback I received, we started to draw the solution  architecture and an interesting insight came out. Our major concern was how to integrate the payment  application on the customer’s cellphone with the existing checkout solution at the merchant. It was clear from  the beginning that we should provide an Application Program Interface (API) to be consumed by the checkout  application in order to inform the payment application about the items that should be paid and their prices.  What was not clear from the beginning is that other mobile applications could also perform payments  consuming the same API. This was a huge improvement on the solution quality because it could handle distinct  situations in a homogeneous way, thus reducing development and maintenance costs. Regarding the usage of  the tool itself, something that called my attention was that the rougher the diagrams the easier for people to  share their thoughts. As we evolved the drawings, people got somehow intimidated to make suggestions.  Therefore, we created a rough version of our flowchart that we use to show people, even if we already have  a more refined version for ourselves.

Approach

Although the Visualization tool is aimed at the What Is phase, its products were mainly useful at the What If  phase when we started to ideate around the learnings we have gotten. Definitely, the Visualization tool has  shown to be an invaluable resource to place everyone on the same page and generated raw material that was  used as resources for the subsequent phases and as documentation throughout the project. Verbal  descriptions of the problem and the situation would never allow us to reach a common understanding as fast  as we did.

