Applying Visualization to

Mobile App Concept Development

1: Challenge

The underlying business challenge for this application of Design Thinking is within the field of  Transport & Logistics, more specifically refrigerated containers used for transporting, e.g., fruit, meat  or flowers over long distances. My company manufactures containers, and we have learned from  customer feed-back that they find it slow and complicated (and even archaic) to configure these  containers (temperature, humidity, etc) using the physical control panel on the container.

Consequently, we are currently investigating creating a mobile App to complement the display panel.  This would allow us to deliver a significantly improved user experience without having to update the  display panel on literally hundreds of thousands of containers across the globe.

In relation to this course, the design process challenge for me was how to facilitate a project kick-off  workshop with a diverse group of people (manufacturing, customer support, sales, IT), most of whom  I had never worked with before.

2: Selection

I decided to hold the workshop in two parts: One would focus on the “What is” and progress  somewhat into “What if” using the Application Mountain model. This would allow us to establish an  initial picture of the Mission Statement of the App, the Key User Tasks, and which Features would be  needed in the App in order to support those User Tasks. I won’t go into further details of this first half  of the workshop.

The purpose of the second half of the workshop was to establish a common understanding of the  product – what the App would be like to users. I basically wanted to make sure that we left the  workshop with the same “picture” of what we were going to create, so there wouldn’t be any  misunderstandings going forward (with collateral waste of time having to go back and re-discuss).

For that part, I decided to use Visualization as the primary tool. This decision was based on the very  illustrative visualizations in the “Visualization Tool” video in week 1 of this course – once you show  people what you talk about, rather than just use words, it’s much easier to establish a common  understanding. Without the visualization, it is up to each person to create an “inner mind’s image” of  what you are describing – and they certainly will do so.

3: Application

As Todd Zarki Warfel puts it in his book “Prototyping”, any prototype serves as a communication  tool, and different kinds of prototypes serve different purposes. Consequently, the design process for  this project covered three different versions of the same visualization – in increasing fidelity – done  over two weeks.

The first visualization of the App was done “live” in the conference room, where we held the kick-off  workshop. I was using a whiteboard and markers in different colours, drawing (improvisationally) as  we talked about the different features of the App, how they related to each other, and which ones  were the most important.

The purpose of visualization #1 was to ensure that everybody

was “on the same page” during the workshop

I then took the plane home to head office, where I did a higher-fidelity version of the same  screen the next day. This allowed me to re-think the lay-out and visual concept once more,  based on my previous experience in UX and UI design. This second visualization was now  sufficiently credible to take to upper management of our company, asking for funding.

The purpose of visualization #2 was to convince key stakeholders that this App had

potential, and that it would make sense to create a prototype

Once management had understood the idea and its potential business value, they approved us  proceeding with a prototyping study, where we would build a mock-up to test with users. Thus,  Visualization #2 was handed over to a graphics designer in our company, who came up with the next  version of the visualization:

Visualization #3 will communicate to App developers – on a pixel level – what

we want them to build for us

This is where we currently are, awaiting delivery of the functional mock-up of the App. The mock-up  still won’t have any back-end integrations, since this will take significant resources. We need to verify  with actual users that we are really building the right App for them, before we commit to the final  specifications and design.

4: Insight

There is no doubt that using visualization at such an early stage in the project helped everyone agree  on the intentions of what we were planning to do. Taking us from the first part of the workshop –  which was very much based on writing down keywords in bullet lists – to a far more tangible “product”  allowed us to advance both faster and with more confidence. As the visualization “grew” in the  workshop, we would also benefit from going through the details of all buttons/features with input from  all the involved teams/departments.

The benefits of this way of working stretched far beyond the workshop, though. When myself and the  head of IT later presented Visualization #2 for management, we were able to answer all questions  with ease, because we were presenting a relatively mature product, where all aspects had already  been considered. Getting a “green light” from management was very much thanks to the successful  application of visualization.

Finally, we expect the developers to create the mock-up for us without any fuss, since the  visualization is now high-fidelity, and all underlying aspects have already been settled upon.

5: Approach

To put this method into perspective, I would like to compare it with the traditional method used in large  companies (like my own :-).

Assuming that the initial part of the project was the same (part 1 of the workshop), the next step would  have been for a Business Analyst to write down detailed Requirement Specifications in a Word  document – probably 15-20 pages. Once everyone had agreed on the written specifications, a graphic  designer would have set out to interpret that document and create his version of what it would look  like. Only at that point would the stakeholders get the first view – and it would probably differ quite a  lot from everyone’s “inner mind’s image”.

In conclusion, we have certainly saved significantly in both time and frustration on this project by  applying Visualization as described above.


Applying Visualization to Mobile App Concept Development 1 : Challenge The underlying business challenge for this application of Design Thinking is within the field of Transport & Logistics , more specifically refrigerated containers used for transporting , e.g. , fruit , meat or flowers over long distances . My company manufactures containers , and we have learned from customer feed - back that they find it slow and complicated ( and even archaic ) to configure these containers ( temperature , humidity , etc ) using the physical control panel on the container . Consequently , we are currently investigating creating a mobile App to complement the display panel . This would allow us to deliver a significantly improved user experience without having to update the display panel on literally hundreds of thousands of containers across the globe . In relation to this course , the design process challenge for me was how to facilitate a project kick - off workshop with a diverse group of people ( manufacturing , customer support , sales , IT ) , most of whom I had never worked with before . 2 : Selection I decided to hold the workshop in two parts : One would focus on the “ What is ” and progress somewhat into “ What if ” using the Application Mountain model . This would allow us to establish an initial picture of the Mission Statement of the App , the Key User Tasks , and which Features would be needed in the App in order to support those User Tasks . I wo n’t go into further details of this first half of the workshop . The purpose of the second half of the workshop was to establish a common understanding of the product – what the App would be like to users . I basically wanted to make sure that we left the workshop with the same “ picture ” of what we were going to create , so there would n’t be any misunderstandings going forward ( with collateral waste of time having to go back and re - discuss ) . For that part , I decided to use Visualization as the primary tool . This decision was based on the very illustrative visualizations in the “ Visualization Tool ” video in week 1 of this course – once you show people what you talk about , rather than just use words , it ’s much easier to establish a common understanding . Without the visualization , it is up to each person to create an “ inner mind ’s image ” of what you are describing – and they certainly will do so . 3 : Application As Todd Zarki Warfel puts it in his book “ Prototyping ” , any prototype serves as a communication tool , and different kinds of prototypes serve different purposes . Consequently , the design process for this project covered three different versions of the same visualization – in increasing fidelity – done over two weeks . The first visualization of the App was done “ live ” in the conference room , where we held the kick - off workshop . I was using a whiteboard and markers in different colours , drawing ( improvisationally ) as we talked about the different features of the App , how they related to each other , and which ones were the most important . The purpose of visualization # 1 was to ensure that everybody was “ on the same page ” during the workshop I then took the plane home to head office , where I did a higher - fidelity version of the same screen the next day . This allowed me to re - think the lay - out and visual concept once more , based on my previous experience in UX and UI design . This second visualization was now sufficiently credible to take to upper management of our company , asking for funding . The purpose of visualization # 2 was to convince key stakeholders that this App had potential , and that it would make sense to create a prototype Once management had understood the idea and its potential business value , they approved us proceeding with a prototyping study , where we would build a mock - up to test with users . Thus , Visualization # 2 was handed over to a graphics designer in our company , who came up with the next version of the visualization : Visualization # 3 will communicate to App developers – on a pixel level – what we want them to build for us This is where we currently are , awaiting delivery of the functional mock - up of the App . The mock - up still wo n’t have any back - end integrations , since this will take significant resources . We need to verify with actual users that we are really building the right App for them , before we commit to the final specifications and design . 4 : Insight There is no doubt that using visualization at such an early stage in the project helped everyone agree on the intentions of what we were planning to do . Taking us from the first part of the workshop – which was very much based on writing down keywords in bullet lists – to a far more tangible “ product ” allowed us to advance both faster and with more confidence . As the visualization “ grew ” in the workshop , we would also benefit from going through the details of all buttons / features with input from all the involved teams / departments . The benefits of this way of working stretched far beyond the workshop , though . When myself and the head of IT later presented Visualization # 2 for management , we were able to answer all questions with ease , because we were presenting a relatively mature product , where all aspects had already been considered . Getting a “ green light ” from management was very much thanks to the successful application of visualization . Finally , we expect the developers to create the mock - up for us without any fuss , since the visualization is now high - fidelity , and all underlying aspects have already been settled upon . 5 : Approach To put this method into perspective , I would like to compare it with the traditional method used in large companies ( like my own :-) . Assuming that the initial part of the project was the same ( part 1 of the workshop ) , the next step would have been for a Business Analyst to write down detailed Requirement Specifications in a Word document – probably 15 - 20 pages . Once everyone had agreed on the written specifications , a graphic designer would have set out to interpret that document and create his version of what it would look like . Only at that point would the stakeholders get the first view – and it would probably differ quite a lot from everyone ’s “ inner mind ’s image ” . In conclusion , we have certainly saved significantly in both time and frustration on this project by applying Visualization as described above .