Reflection – Visualization

Challenge

A need arose within our Global Billing Operations organization for a front-door tool dedicated to the  take-in, tracking and reporting of the Organization’s manual billing requests. This task had previously  been with multiple billing tools, of which the two important for our region were soon to be sunset. The  new tool had to combine the formerly used tools’ functions, serving as a “vessel” for a manual billing  request throughout its lifecycle – from submission, review, through approval, to its completion upon  invoicing. In addition to that, it was supposed to establish a standardized audit trail, reduce the overall  complexity for the various billing organizations, and reduce the overall complexity and variations of  manual billing process handling across the different teams. Though the new tool had to accommodate  some existing diversity, the goal was to have a level of uniformity and consistency in data collection and  processing across the board.

Selection and Application

For this challenge, VISUALIZATION was one of the key components in approaching this task. We needed  to have a visual representation of the tool’s complex space and how the submitted manual billing  requests would flow through the various “gates” per the process. Although this development stage was  preceded by a meticulous collection of the business and functional requirements from the numerous  stakeholders, it was important to really see how the functions of the previously used tools were  incorporated, what the new relationships were, and where did the various stakeholders step in during  the request’s journey.

Diagrams and mock-ups were utilized for the representation of the tool’s space. As the tool needed to  house multiple manual billing request templates used by various organizations, the different teams sat  down and discussed the various aspects in the visualization separately. This was an effective application  as each team could concentrate on their own little eco-system in which their manual billing requests  would exist, and they could talk about the specific challenges or improvements to their area of the tool.

Insight

The visualization presented a quick and valuable insight into the possible scenarios where a certain  condition within the process was/could not be met and open up a discussion and generate ideas where  a manual billing request’s flow should be reversed to in order to adhere to the process, or for any  functional improvements. Visualization was really the most effective tool to use in this case as the  complexity of the process and the tool’s functions were simply too difficult to be told as a story. Hearing  instead of seeing in this case could leave too great of a room for error, or misunderstandings – we  simply may be understanding the words slightly differently and the saying “A picture is worth a

thousand words” rings very true here. Having the tool’s environment at glance through this clear visual  representation established what’s what from the start and allowed the group to test their assumptions  and to focus on the true challenges.

Looking at design thinking in broader terms, I realized there are various types of challenges out there  and they may require or be most effectively solved by applying one or the other of the tools that design  thinking offers. While for challenge X, the best approach may be storytelling, for challenge Y, it may be  visualization or mind mapping, while challenge Z will be best solved through the learning launch.

Approach

If I faced this kind of challenge again, I would choose visualization again. The above challenge was a case  where many of the what is had been already established and known, there was a certain process in  place, the stakeholders were organizations within our corporation – and what we needed to do was to  create a tool which would be an incorporation and an improved version of the functions in the already  used tools. Not much of a mystery here.

On the other hand, I can definitely imagine using storytelling in the creation of a tool or a mobile  application, given a different context. What if we were creating the product for our customers, the  public, without any idea of what their needs were. And though visualization would most certainly be  part of the later development process, the number 1 focus would be on storytelling, number 2 would be  the learning launch to test, learn and iterate as quickly as possible.


Reflection – Visualization Challenge A need arose within our Global Billing Operations organization for a front - door tool dedicated to the take - in , tracking and reporting of the Organization ’s manual billing requests . This task had previously been with multiple billing tools , of which the two important for our region were soon to be sunset . The new tool had to combine the formerly used tools ’ functions , serving as a “ vessel ” for a manual billing request throughout its lifecycle – from submission , review , through approval , to its completion upon invoicing . In addition to that , it was supposed to establish a standardized audit trail , reduce the overall complexity for the various billing organizations , and reduce the overall complexity and variations of manual billing process handling across the different teams . Though the new tool had to accommodate some existing diversity , the goal was to have a level of uniformity and consistency in data collection and processing across the board . Selection and Application For this challenge , VISUALIZATION was one of the key components in approaching this task . We needed to have a visual representation of the tool ’s complex space and how the submitted manual billing requests would flow through the various “ gates ” per the process . Although this development stage was preceded by a meticulous collection of the business and functional requirements from the numerous stakeholders , it was important to really see how the functions of the previously used tools were incorporated , what the new relationships were , and where did the various stakeholders step in during the request ’s journey . Diagrams and mock - ups were utilized for the representation of the tool ’s space . As the tool needed to house multiple manual billing request templates used by various organizations , the different teams sat down and discussed the various aspects in the visualization separately . This was an effective application as each team could concentrate on their own little eco - system in which their manual billing requests would exist , and they could talk about the specific challenges or improvements to their area of the tool . Insight The visualization presented a quick and valuable insight into the possible scenarios where a certain condition within the process was / could not be met and open up a discussion and generate ideas where a manual billing request ’s flow should be reversed to in order to adhere to the process , or for any functional improvements . Visualization was really the most effective tool to use in this case as the complexity of the process and the tool ’s functions were simply too difficult to be told as a story . Hearing instead of seeing in this case could leave too great of a room for error , or misunderstandings – we simply may be understanding the words slightly differently and the saying “ A picture is worth a thousand words ” rings very true here . Having the tool ’s environment at glance through this clear visual representation established what ’s what from the start and allowed the group to test their assumptions and to focus on the true challenges . Looking at design thinking in broader terms , I realized there are various types of challenges out there and they may require or be most effectively solved by applying one or the other of the tools that design thinking offers . While for challenge X , the best approach may be storytelling , for challenge Y , it may be visualization or mind mapping , while challenge Z will be best solved through the learning launch . Approach If I faced this kind of challenge again , I would choose visualization again . The above challenge was a case where many of the what is had been already established and known , there was a certain process in place , the stakeholders were organizations within our corporation – and what we needed to do was to create a tool which would be an incorporation and an improved version of the functions in the already used tools . Not much of a mystery here . On the other hand , I can definitely imagine using storytelling in the creation of a tool or a mobile application , given a different context . What if we were creating the product for our customers , the public , without any idea of what their needs were . And though visualization would most certainly be part of the later development process , the number 1 focus would be on storytelling , number 2 would be the learning launch to test , learn and iterate as quickly as possible .