Customer Driven Product Development and Innovation

23^rd September 2022 | Author: Anthony Hyde

The role of customers or end-users in the development of new products is vital in both ensuring a successful product and in creating an innovative one. This collaboration was key to the success of the AZtec EDS software platform.

Building on success

We already had a market-leading software platform in INCA, but it was showing its age and needed replacing. The way that the EDS technique was developing meant that analyses were taking seconds instead of minutes, and the INCA workflow was not designed to work in this way. The programming architecture was outdated and restrictive, so we knew it was time for a complete overhaul from top to bottom.

Employing the latest technology

When it came to designing INCA’s replacement, we employed new software tools, such as:

• WPF
• .net

• TFS

• Subversion/Git repositories

• Continuous integration

• Nightly builds

• Unit tests.

We went from 32-bit to 64-bit software architecture and utilised the power of multi-threading programming… All of which meant that we were better able to create a new software platform that could best utilise the latest developments in hardware, while also allowing new innovative applications to be realised. In terms of methodology, we implemented an ‘Agile process of software development and assigned product owners to software project. In fact, I was the first AZtec product owner.

Designing for the user

As the AZtec product owner, it was my job to, not only to come up with a product specification, but also be the Voice Of the Customer and reflect our users needs. To best do this, I went out and talked to hundreds of users, both of our equipment and our competitors. I needed to find out what jobs they were doing and what jobs they wanted to do but couldn’t with their current systems. Then, there are the little things that people put up with and never mentioned, because they’re thought of as insignificant.

Simplifying workflows

Watching people use your systems is a great way to pick up on these ‘little’ things.

Let’s take a specific example of adding or removing an element map. INCA was designed around a central workflow, and all the settings were side steps to the main workflow. This means, if you were looking at a set of maps and wanted to add an element map, you would go to a settings step where you would no longer have visibility of your maps. You would choose the element, and then go back to the map step to see the map. If you’d made a mistake or weren’t quite sure whether it was the one you wanted, you would have to repeat this process – very time consuming:

With AZtec, we took this pain point into account, and we removed the side steps to the main workflow. Any settings were then available right where they’re needed and, in this case, all you need to do is click on an element and the associated map is shown instantly:

Understanding the need

Then there are requests that mask the real need, such as the request for Quantitative Mapping, which was a common request for the first release of AZtec. The question was “Can you make Quantitative Mapping quicker?” When we asked why QuantMap was required, it turned out that the main reason was to generate peak overlap corrected maps, so they could see the real distribution of elements in their sample. This gave us the task to investigate ‘Could we generate Overlap Corrected Maps fast enough to be displayed in real time.’

This led to the development of ‘TruMap’, which deconvolves overlapping element maps in real time (along with removing background artefacts).

This was a piece of functionality that gave these users exactly what they needed and not necessarily what they asked for.

Providing results in Real Time

Another example of user interaction being responsible for the development of innovative functionality was Live Chemical Imaging. This came from several VOC trips to users who performed Quality Control and Failure Analysis jobs with SEM-EDS. Here, we watched AZtec users rearrange the interface to best suit their application. They went to the analyser or Point&ID navigators and expanded the ‘Spectrum Monitor’ window as wide as it would go.

They would then move around their sample using the SEM controls, while keeping an eye on the spectrum monitor. Because the user generally had a good knowledge of their sample, all they needed to do is watch for a spectrum with a set of specific peaks; their job would be finished, and they could contact their customer with a verbal result. Other more involved applications would involve acquiring a standard spectrum or X-ray maps to make more informed decisions. The one thing that these customers had in common was that they wanted their results as quickly as possible, because there was generally someone waiting on the end of a phone for an answer.

We then asked these users; “would it be useful to remove the necessity to stop the microscope stage every time you need extra information and to acquire standard spectra and maps?” and the overwhelming response was “Of course.” The reason for that specific question was that, with the advancements we had made with large area detectors, high throughput electronics and the use of multi-threaded programming, we believed that we could acquire and process the electron image, X-ray maps and spectrum continuously from within the AZtec software. In addition, we also believed we could control the SEM stage during this continuous acquisition.

From this VOC exercise, we eventually launched our Live Chemical Imaging capability, which removes users’ current ‘stop and start’ approach to analysis and gives them a continuous and dynamic one.

The use of LCI is ideal for Failure Analysis and Quality Control, but it can be a fundamental part of any analysis, like finding an area or feature of interest so that a more detailed analysis can be carried out. All this shows what a fundamental part the user plays in the role of product development at Oxford instruments.

About the Author