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 . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: 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 .
### Output: 