Refection Submission : VISUALISATION 

 Challenge : Describe your challenge , including all relevant information .   My client , a global healthcare organisation , provided a suite of clinical healthcare analytics software to   primary healthcare providers , with over one - thousand deployments across several clinical care   commissioning groups . 

 The software acquired patient health data from local ( on premise ) system and transformed these into   clinical insights for use by healthcare professionals and administrators . 

 The software was provided on a deprecated version of a popular ( ubiquitous ) operating system , and having   grown organically over nearly two decades , was poorly architected , version controlled , and sparsely   documented . 

 The challenge was to reimagine the software suite as a modern serviced - based platform , cloud - hosted , with   a CI / CD pipeline , and a browser - based user - interface , to overcome the issue of local hardware variations . 

 Selection : In your own words , briefly describe the tool you selected ( e.g. , what it is and why   you selected it for your challenge -- including any appropriate video lecture references ) .   The tool selected was visualisation .   As we ( my team ) were tackling a pretty complex suite of user- applications , we wanted to ensure that we could get a clear understanding of ‘ what is ’ that could be   consumed by everyone involved in the project . 

 The transformative nature of the project meant that the extended team included senior executives as well as   a co - located design and development team . 

 We wanted to ensure early on that we were able to clearly communicate our findings and allow the team to   supplement and enhance our understanding , without creating and maintaining a ream of documentation   that people would not want to engage with .   Especially as the system we would eventually start modelling   would supersede this one , and hopefully would have an improved set of ‘ requirements ’ ( with regulatory   implications ) , that would need to have comprehensive documentation . 

 Application : Describe how you applied the tool you selected to your challenge ( e.g. , what you   did and how the tool was applied effectively or ineffectively ) .   We worked with our client to story board the user journeys they believed their users were making , as part of   our understanding of ‘ what is ’ .   We identified candidate user personas and asked our client to explain how   each persona interacted with the various applications in the suite . 

 We constructed a stick - man visualisation for each persona - application journey .   This gave us a pretty clear   understanding of overlaps between journeys to differentiate between platform functionality and app   functionality . 

 We then visited a selection of clients to validate our ‘ perceived ’ understanding .   We asked them to help us   visualise their day to day usage of the applications in the suite , to help us understand real bottlenecks and   process inefficiencies .   Many ( most ) of these had not been known to , much less understood by , our client , 

 who had for many years complacently misunderstood user ‘ silence ’ to mean satisfaction , when actually the   opposite appeared to be the case . 

 Insight : Describe the insight you gained from applying the tool you selected to your challenge   ( e.g. , how an insight affected your thinking about the challenge and about design thinking   more broadly ) .   By visualising real world user journeys and contrasting these with our clients ‘ intended ’ user journeys , we   were able to help our client acknowledge some reality about their product , in terms of the value derived and   derivable by the end users .   Clearly , use of the products ( or indeed any software products ) under the   pressure and stress of the end - users BAU daily activities had never been considered . 

 By the end of our end - user interactions , we had a completely different – empathic and value based –   understanding of the real needs of the end users , and what would help them to carry out their tasks more   ‘ pleasurably ’ .   We learned that , Medical personnel , no matter what persona they represent , simply do not   need to have additional complexity added to their work - life , by being forced to use non - intuitive computer   systems . 

 We were able to recommend many opportunities to rationalise common workflows into platform level user   journeys which were highly reusable , and simplified day to day use of the system by the end user . 

 We were also able to identify many of the products in the software suite that were simply not being used by   the end users , and recommend a roadmap to retirement for these ( potentially saving hundreds of thousands   in development costs ) , and we identified key products that needed to be prioritised earlier in the   development lifetime of the new system , and a strategy for changeover to enable and incentivise end - users   to transition to the new system . 

 Of course , the best outcome is that the end - users will have a system that they feel they have contributed to ,   and influenced the design of ,   Visualisation , as a tool , helped us to build a collaborative relationship with our   stakeholders , that a more traditional or clinical approach may not have fostered . 

 Approach : Describe what you might do differently next time -- applying the same tool you   selected or a different one -- and the reason(s ) why .   I am happy that the correct tool was selected and applied .   However , we spent a lot of time , up front ,   capturing what we thought ‘ what is ’ was .   It was not until we interacted with the real users that we gained   some real understanding . 

 What we should have done is captured the intended outcomes of the various applications in the legacy suite   upfront , and then got to the end users much quicker . 

 The implications here are that we asked our client to invest their valuable time in giving us their stories , and   then we had to go back and carefully tell them that their stories were ‘ wrong ’ , according to the real users .    This had to be handled with great sensitivity and care , because of the project visibility to executive   stakeholders . 

 It , perhaps , might have been better to have rather gone straight to the users and reported back what was   ‘ working ’ , allowing our clients to naturally come to their own determinations about adjusting the suite and   creating a prioritised roadmap , instead of which , we actually had to negotiate a change to existing   expectations , and force a change to the strategic planning already in flight . 


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: Refection Submission : VISUALISATION 

 Challenge : Describe your challenge , including all relevant information .   My client , a global healthcare organisation , provided a suite of clinical healthcare analytics software to   primary healthcare providers , with over one - thousand deployments across several clinical care   commissioning groups . 

 The software acquired patient health data from local ( on premise ) system and transformed these into   clinical insights for use by healthcare professionals and administrators . 

 The software was provided on a deprecated version of a popular ( ubiquitous ) operating system , and having   grown organically over nearly two decades , was poorly architected , version controlled , and sparsely   documented . 

 The challenge was to reimagine the software suite as a modern serviced - based platform , cloud - hosted , with   a CI / CD pipeline , and a browser - based user - interface , to overcome the issue of local hardware variations . 

 Selection : In your own words , briefly describe the tool you selected ( e.g. , what it is and why   you selected it for your challenge -- including any appropriate video lecture references ) .   The tool selected was visualisation .   As we ( my team ) were tackling a pretty complex suite of user- applications , we wanted to ensure that we could get a clear understanding of ‘ what is ’ that could be   consumed by everyone involved in the project . 

 The transformative nature of the project meant that the extended team included senior executives as well as   a co - located design and development team . 

 We wanted to ensure early on that we were able to clearly communicate our findings and allow the team to   supplement and enhance our understanding , without creating and maintaining a ream of documentation   that people would not want to engage with .   Especially as the system we would eventually start modelling   would supersede this one , and hopefully would have an improved set of ‘ requirements ’ ( with regulatory   implications ) , that would need to have comprehensive documentation . 

 Application : Describe how you applied the tool you selected to your challenge ( e.g. , what you   did and how the tool was applied effectively or ineffectively ) .   We worked with our client to story board the user journeys they believed their users were making , as part of   our understanding of ‘ what is ’ .   We identified candidate user personas and asked our client to explain how   each persona interacted with the various applications in the suite . 

 We constructed a stick - man visualisation for each persona - application journey .   This gave us a pretty clear   understanding of overlaps between journeys to differentiate between platform functionality and app   functionality . 

 We then visited a selection of clients to validate our ‘ perceived ’ understanding .   We asked them to help us   visualise their day to day usage of the applications in the suite , to help us understand real bottlenecks and   process inefficiencies .   Many ( most ) of these had not been known to , much less understood by , our client , 

 who had for many years complacently misunderstood user ‘ silence ’ to mean satisfaction , when actually the   opposite appeared to be the case . 

 Insight : Describe the insight you gained from applying the tool you selected to your challenge   ( e.g. , how an insight affected your thinking about the challenge and about design thinking   more broadly ) .   By visualising real world user journeys and contrasting these with our clients ‘ intended ’ user journeys , we   were able to help our client acknowledge some reality about their product , in terms of the value derived and   derivable by the end users .   Clearly , use of the products ( or indeed any software products ) under the   pressure and stress of the end - users BAU daily activities had never been considered . 

 By the end of our end - user interactions , we had a completely different – empathic and value based –   understanding of the real needs of the end users , and what would help them to carry out their tasks more   ‘ pleasurably ’ .   We learned that , Medical personnel , no matter what persona they represent , simply do not   need to have additional complexity added to their work - life , by being forced to use non - intuitive computer   systems . 

 We were able to recommend many opportunities to rationalise common workflows into platform level user   journeys which were highly reusable , and simplified day to day use of the system by the end user . 

 We were also able to identify many of the products in the software suite that were simply not being used by   the end users , and recommend a roadmap to retirement for these ( potentially saving hundreds of thousands   in development costs ) , and we identified key products that needed to be prioritised earlier in the   development lifetime of the new system , and a strategy for changeover to enable and incentivise end - users   to transition to the new system . 

 Of course , the best outcome is that the end - users will have a system that they feel they have contributed to ,   and influenced the design of ,   Visualisation , as a tool , helped us to build a collaborative relationship with our   stakeholders , that a more traditional or clinical approach may not have fostered . 

 Approach : Describe what you might do differently next time -- applying the same tool you   selected or a different one -- and the reason(s ) why .   I am happy that the correct tool was selected and applied .   However , we spent a lot of time , up front ,   capturing what we thought ‘ what is ’ was .   It was not until we interacted with the real users that we gained   some real understanding . 

 What we should have done is captured the intended outcomes of the various applications in the legacy suite   upfront , and then got to the end users much quicker . 

 The implications here are that we asked our client to invest their valuable time in giving us their stories , and   then we had to go back and carefully tell them that their stories were ‘ wrong ’ , according to the real users .    This had to be handled with great sensitivity and care , because of the project visibility to executive   stakeholders . 

 It , perhaps , might have been better to have rather gone straight to the users and reported back what was   ‘ working ’ , allowing our clients to naturally come to their own determinations about adjusting the suite and   creating a prioritised roadmap , instead of which , we actually had to negotiate a change to existing   expectations , and force a change to the strategic planning already in flight .
### Output: 