User Story:

As a user, I need the ability to quickly and easily configure a technically feasible semiconductor test system that meets my customer’s system level requirements so that I can deliver value quickly to my customer and close more deals.

The Problem:

The semiconductor test systems (STS) business unit had built several custom tools to enable them to configure and quote systems for customers. Having to use multiple tools to configure systems was inefficient and also difficult to maintain.

The Solution:

Create a new online system configuration experience for internal users that is streamlined, scalable, easily maintained and provides all of the necessary information and output documentation needed to close a semiconductor test system deal with a customer.

The Process:

Competitive Analysis

I started by taking time to look at other industry configuration experiences to get a better understand of typical patterns and flows that users come across when configuring products online. While there are no semiconductor test system configuration experiences that I could reference, as this is a very unique use case, this was still a very valuable exercise in better understanding current patterns and trends for digital configuration experiences.

Research and Discovery

There was quite a bit of discovery and research that needed to be done. We were embarking on building a configuration tool for a highly complex subject matter, with engineers being our primary and secondary users. I am not an engineer. There was a lot to understand. What were these systems? How are they put together? What were the different types of instruments that could be put in these systems? For each instrument that could be put in these systems, what were the various cabling options and scenarios to consider? Were there various sizes? Different capacities? There was so much to learn. Myself and a Systems Analyst spent a fair amount of time looking over STS documentation and meeting with R&D STS Engineers to look at the systems and ask questions. Below is a few of the most impactful artifacts that we found and regularly referenced to help us come up to speed on these systems.

Personas

After going through a period of discovery, I started working with my product owner to clearly define who our users were. Yes, we had sellers (who were engineers, turned sellers) who would be using this tool. And yes, we had R&D team members (again, engineers) who would also be using this tool. But within each of those groups, there are a lot of different roles. What Sellers and R&D roles specifically were we targeting and what were their unique needs. We identified the following:

Low Fidelity Wireframes

Now that we had a firm grasp of who our users were, we were able to begin concepting and ideating. I got into Axure and started trying to map out different flows. As we worked and made progress, we would circle back with our STS stakeholders to review wireframes and get feedback. We went through multiple iterations. My product owner and I sat through a ton of brainstorming and white boarding sessions together. We worked through concepts for both a highly configurable experience as well as a deterministic experience.

We continued in this iterative approach until we landed on a flow and overall direction that resonated with our users. While in the beginning, our STS Stakeholders were convinced that they needed a highly configurable experience to replace their custom configurators that they were currently using, in the end, they saw the value in having multiple STS offerings that were available to configure in a deterministic model where they could go in, click a few buttons and have a technically feasible system ready to quote for our customers that was based on system standardizations that the business unit was working to define.

Essentially, the first step of the experience would have the user making some upfront selections to determine the hard constraints for their system. These upfront selections would then determine the hardware selections available to the user on the second step of configuring hardware. After configuring hardware selections, the user could make software and add-on selections and finally review their system and access output documents.

Now that we were all in alignment on an overall direction and flow, it was time to start refining the experience and getting into the nitty gritty details of defining patterns and states. One of the more challenging aspects of this experience for me was figuring out a consistent pattern to use when reviewing product selections that the user had made. We had come up with a way for the user to interact with the system visualization and when they selected an option within the visualization, a side panel would slide in from the right and the user would have the ability to review the selection and see what the item was, and relevant information about the selection.

In these semiconductor test systems, there were modules that connected to 1 spring pin block on the mass interconnect. There were modules that connected to multiple spring pin blocks. Some spring pin blocks could have multiple modules connected up to them. There were specialty RF (radio frequency) instruments that had multiple connection points. Some needed to be connected to another instrument on one side, and on the other side would need to be connected to multiple different instruments. Some instruments connected up to RF ports on the mass interconnect instead of other instrument. Distilling all of these various use cases into a consistent and intuitive pattern definitely gave me a few extra gray hairs. But, we were able to eventually come up with a very clean and very consistent way of displaying this information for the user. We first had to look at all of the various instrument and port scenarios and categorize them. We found that at the end of the day, even though there were all of these complexities and various options, when you abstracted all of the complexities away, what you were left with was 3 unique use cases to solve for:

• 1 item connected to 1 item

• 1 item connected to multiple items

• multiple items connected to multiple items

Once we had defined those categories, then we needed to map the different instruments and connection points into those categories. In doing so, we came up with the following:

• 1 item connected to 1 item

  • 1 instrument to 1 spring pin block

  • 1 spring pin block to one instrument

  • 1 VST to one port control module

  • 1 port control module to 1 VST

• 1 item connected to multiple items

  • 1 instrument to multiple spring pin blocks

  • 1 VST to multiple RF blindmates

  • 1 port control module to multiple port modules

  • 1 port module to multiple RF blindmates

  • 1 spring pin block to multiple instruments

• multiple items connected to multiple items

  • multiple instruments to a spring pin block with multiple connection points

  • multiple port modules to a port control module with multiple connection points

Once we had the mapping in place, I was able to work through designs for a side review panel that a user could access when they interacted with an option in the diagram. This panel would provide the user with information about the selected option that included both where it was placed within the system as well as what options it was connected to within the system. If the user needed deeper information regarding connection points, they would have the option to expand and see specific connection details.

The Result:

A beta version has gone out and reception from the Semiconductor Business Unit has been very positive. Users now have the ability to enter the STS Configurator, quickly select and add hardware options to their system, view their overall system setup, understand what options are placed and connected where within the system, access output documents for customer proposals and quickly share configurations to collaborate and make edits as needed. We have identified a few pain points for our users, as well as some bugs, and are working to prioritize new features to alleviate the identified pain points.

What’s Next?:

The first complete MVP version of the semi-conductor test system will go live in mid Q4 of 2020. When the configuration experience goes live, all standard semiconductor test systems will be configured and quoted in the new tool. We will continue to work with Sellers and R&D Technical folks to identify gaps, pain points, bugs, etc. and work to continuously improve both the functionality and visual refinement of the new configuration experience while also working to bring other system level offerings onboard to our new configuration platform.

Role:

Product Designer

Medium:

Desktop

Methodology:

• Competitive Analysis

• Research and Discovery

• Personas

• White boarding

• Low Fidelity Wireframes

Tools:

• Axure

• Whiteboard

Project Duration

• 11 months