Problem Context

Loading a flight booking takes up to 20 seconds due to legacy back end issues. 
At the time when a user tried to retrieve their flight booking via the mobile app a series of 8+ API calls were requested.
These calls were mostly sequential and the backend systems were slow and overburdened. 
The product owners had struggled to speed up the application and approached UX to see if a solution could be achieved.

Find the right problem

I could see the problem quite apparently but I wanted to verify if the problem was widespread before solutioning.
I had a 3 prong approach to understand this problem.
Firstly, I worked with stakeholders to fully understand opportunities and challenges. While we were not in a position to prioritise optimisation of these backend systems it was enough to have the discussion to share our concerns and discuss UX. Knowing the problem existed now and could not be addressed, certainly helped us get future problems addressed.
Secondly, I used corporate communications at Emirates to bring some users into Emirates HQ to run some think observations and think aloud sessions to understand how much of a problem this was. Additionally, it gave good indicators of success for time spent loading. Users indicated a desired response time of between 5-10 seconds which agreed with Don Norman's work on website response times.
Finally, I conducted a product review with the design leads to see if there were any other similar issues in the rest of the application and how they were addressed. Similar issues with the backend were present in most parts of the application but there was no clear path forward and the issues were placed on our design technical debt backlog.

Build the best (aka least worse) solution

Given that it seemed impossible to change the actual backend, or speed up the front end, I really only had two options. 

1. Provide visual system feedback of the delayed time to load. This was used throughout the platform already and an existing pattern would be fast and easy to implement.
2. Find some way to provide a distraction so that the user was not aware of the passing time. This was not used, but given the duration and importance of the delay this proposal was accepted to prototype and test.

Scenarios were explored with sketches and discussed with product owner to find one that also solved another problem. 
Seat selection, early check in's were all options explored but through discussion and exploration a concept arose surrounding naming a trip. I.e. rather that London-Dubai, as was commonly named, why not offer to rename the trip to something more personal like honeymoon or holiday.
Sketches were brough forward to wireframes, verified with design team and tested with users with stub data. These were then brought forward to final designs and passed scrutiny of the product team and again tested with users who reported back a complete elimination of load time, or a 100% improvement. 

Problem Context

BD Synapsys is a complete smart lab automation solution that utilises AI and thoughtful design to support and optimize Microbiologists workflow in a lab setting.
As Microbiology labs, and Synapsys, scale more and more products are physically and digitally integrated into the solutions.The primary goal of this piece of work was to integrate a physical process of spotting organisms into a MALDI ( matrix-assisted laser desorption/ionization) plate (See image below) with the Synapsys to record digitally each patient sample that was placed on the plate and place records on the patient electronic health record. This diagnostic system is used ultimately to identify disease and therefore the stakes for a solid design are high.

Find the right problem

In addition to the above objective there were dozens of other features which were necessary to be placed in the same location in the application.  Space was at a premium and immediately the application scope started ramping up massively. A mix of lab observation and card sorting determined the prioritisation and potential placement of the functionality.

Build the best (aka least worse) solution

With a demanding list of functionality to place into this section of Synapsys the majority of my efforts were focused on the priority 1 functions placement and design. This process took well over 1 year and involved a lot of collaboration with product owners and business analysts, observation and testing with various Microbiology lab personnel, and of course multiple review and co-create sessions with the design team. Many aspects were beyond the scope of this design piece (calendar widget redesign, modal redesign) due to existing component use in other parts of the system.

Eventually after 38 revisions (all tracked with detailed review and redirection notes. A final version was released and tested with our target users. 

Even with this design and component creation there were plenty of functionality that needed to be hidden with slides, accordion's and modals etc.
It was a fascinatingly complex piece of work that challenged me, some may say broke me, but I'm quite happy with the outcome all things considered. 

Problem Context

Synapsys has been launched and relaunched several times. The process of updating medical software is difficult and leads to old software in the field that rarely gets updated.
To that end Synapsys has many different styles and system governing its design which sometimes contradicts itself. Such as the use of modals below (close button and OK / Cancel etc.)

Find the right problem

A unified component library is needed, in addition to a plan to maintain it. Additionally, and somewhat fundamentally, a system of design which suggests next steps for all elements of design from 'how, when and why to research' to how to estimate work and maintain a design technical debt backlog etc.
Similarly, BD makes acquisitions which need to be adapted to Synapsys or Synapsys adapted to them. A clear process and repository was required.

Build the best (aka least worse) solution

A complete information audit was needed to assess all the components in use. Variations of components were noted and as well as discrepancies and estimates for redesign and, if applicable, redevelopment. These were added to the backlog and stored in our management system (Azure devops in this case). 
Standard design practice such as responsiveness had not been considered due to fixed screen design but as Synapsys expanded to new products this was a good time to refactor everything.

Brad Frost's atomic design was used as the template for a new design system library. This is a really smart way to hierarchically embed all components from tiny labels to section and page templates.
This system makes for fast iterating and light maintenance.
UXPin was used as our UX repository to store not only our design artefacts from research to prototypes, but also our sprint planning and backlog prioritisation.

An important part of this system was stakeholder threaded commenting on all artefacts, prototype testing and recording live with users and developer Javascript, css and asset handover integrated.
UXPin was the perfect solution for these too. Figma, is an equally useful online collaborative design system repository, but the navigation, team environment and iteration history sway us to UXPin. 
Figma is a great tool and definitely better for more B2C commercial applications where visual design is more important. For enterprise systems this is possibly not as important and a wireframing / prototyping system works well.
If any designer would use Figma (for enhanced visual design) or solidworks (for industrial design) copies of the design file will be stored in UXPin and the actual files linked.
Maybe this is not best suited for everyone, but it worked well for us.