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.


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 .