My design work at Bsquare extended to working with our Services team to design custom solutions for our customers. I particularly enjoyed working with our customers to design solutions for their unique problems and advocating for their needs. In this example, I worked directly with the PM at Ansoft (name falsified) to design a solution for application availability.
Problem
Ansoft is a manufacturer of devices and a seller and distributor of software (applications) for those devices. Customers buy devices and software from Ansoft for deployment within their fleets. Ansoft wanted the ability to control the availability of each application by dictating which customers each application version was available to.
My approach involved:
- Gathering requirements from the customer
- Exploring alternative ways to tackle the problem
- Reviewing the results with the customer
- Iterating on the designs based on customer feedback
Gathering Requirements
The first step was to discuss the requirements and needs of Ansoft. As a designer, I was particularly interested in understanding the personas and use-cases involved in the application availability feature.
Personas
- Application Developer – Application developers are responsible for developing new software for deployment within the Ansoft environment and maintaining the meta-data and versions of said software. They may work directly for Ansoft or may work for a third-party development company.
- Certifier – Certifiers are back-office professionals who verify application readiness and approve or reject applications for deployment within the Ansoft environment. They are one of the primary persons of contact for third party app developers to help get their applications approved and published. Certifiers work for Ansoft.
- Support – Support users are responsible for assisting customers by troubleshooting their problems as they relate to Ansoft devices, Ansoft’s environment, and software developed or distributed by Ansoft. They are a primary point of contact for customers as well as third party developers. Support users work for Ansoft.
Use-cases
- Ansoft is developing a new application and wants to test it with a limited beta release to a few trusted customers for their feedback.
- A customer has complained about a unique situation on their devices and Ansoft wants to develop a fix to one of their applications just for that customer (not all customers).
- A third-party developer is developing an application for use on Ansoft’s devices and wants to release the software to a limited list of customers within the Ansoft system.
Exploration
With requirements gathered, the next step was to explore alternative solutions to the problem. My goal was to have 3-5 options to present with varying levels of change. While designing, I was considering the following questions:
- How and when do users want to customize application availability? Is this an application level detail or a version level detail?
- Do users want to determine availability when they create an application or version? Do users want to be able to change the availability after a version has been published?
- Assuming availability is at the version level, should a new version inherit the availability of the previous version?
- If a new organization is added to the system, will they have to be added to all of the versions?
- What is the most common use case? How can I design that use case to be as low involvement as possible?
- Do users want a new tab for availability or integration with existing systems?
- What information and statistics about availability do users want to be able to see (if any)?
The questions in bold were the ones that I focused on. The possible answers to those questions became the main differences between the 5 resulting options.
- Option 1 – A simple addition of a new tab allowing users to add and remove organizations from an application version.
- Option 2 – Whenever a new organization is added, all the user will need to do is add them to the relevant groups and all the appropriate applications will be available to them.
- Option 3 – Instead of considering all the different organization groups, all the user needs to consider is whether this version is meant for everyone or a custom list of organizations.
- Option 4 – Integrating availability into the existing Customers tab (which allowed Ansoft to issue licenses to customers).
- Option 5 – Exploring some top level statistics (adoption rate, installation count, and license count for a particular version) that Ansoft had mentioned.
Review
Before reviewing with the customer we did a review with internal stakeholders to determine any changes before asking the customer for feedback. We decided to go forward with options 1, 3, 4 and 5 but not option 2 because it was too far outside of the agreed scope.
In reviewing the options with Ansoft we got feedback on each of the options presented and on the high-level questions I was considering. Ansoft was very concerned about adding new organizations to the system, agreed that the most common use case was a version meant for everyone and should be optimize accordingly, and determined that they wanted availability to be its own standalone feature and not integrated with other existing systems. As a result, option 3 was the version they wanted to proceed with.
Iteration
From customer and internal feedback I did one more round of optimization on option 3.
Option 6 focused on optimizing:
- The terminology used for this feature.
- The information users would want about each organization.
- The ability to search for how any organization was related to the selected application version.
- The configuration screen by making it layout in the same way as the read-only screen.
We reviewed option 6 with Ansoft and they approved these wireframes for development.