We start by understanding that there is no such thing as “universal ease of use.” A product is only usable by a certain set of people, and we need to understand the skill sets and motivations of our users – the storage administrators. To build our understanding, we recently started a “Design Partner” program in which customers volunteer to spend several hours a month with us, whether that is having us come onsite for visits, or simply having conference calls with screen sharing. Design Partners have the opportunity to shape the product in its early stages, and develop working relationships with the product designers and developers.
We leverage the Design Partner Program to inform us in the following ways:
• To help understand the job role in general and to create personas epitomizing the job requirements
• To provide general feature input about the upcoming and future releases
• To give us specific usability feedback on the upcoming release.
Understanding the job role and creating personas
To help us keep the storage administrators in mind, we build personas – fictional characters based on our interviews with real storage admins. We use the personas to remind developers that they are NOT the target user, to focus the team on the skill and motivation of real users, and to have some fun. We’ve also made posters out of our personas and we sometimes carry the posters into meetings to have a big visual reminder of our target audience as we design the product.
To create these personas, we interview each of our Design Partners during which we ask the Design Partner to show us how they use ViPR SRM or the SA Suite. As one example, we conducted a site visit to an international shipping company to learn about their use of ViPR SRM, and a healthcare company to learn about their use of the SA Suite. These interviews have proven invaluable for gleaning vital design feedback and to help us better understand the needs of our target customers.
Providing general feature information
Sometimes we hold conference calls and web conferences to get feedback on general ideas for future releases. For example, we held several meetings with our design partners to ascertain what they liked and found useful in the ViPR SRM 2.0 landing pages (examples shown in the screenshot below), and what they wanted improved.
Figure 1: ViPR SRM 2.0 landing page
We learned that they wanted high-level status information to help know what to focus on, and they wanted it in a more engaging and modern way. To that end, we worked with the Design Partners to re-design the landing pages. For ViPR SRM 2.0 we were able to make the landing page more visually engaging, as you can see in the sample screen below.
Figure 2: Re-designed landing page for ViPR SRM 3.0 (Left navigation tree has been closed in this picture)
And we are working with the Design Partners to add high-level summary status in the future, as shown in the following sample mock-up:
Figure 3: Sample idea for adding high-level information to a landing page
(We cannot promise that future user interfaces will actually look like this).
Giving specific usability feedback
Another important part of our Design Partner program is monthly usability testing (depending on the stage of the development process, we sometimes even do the testing weekly). We schedule remote usability tests using web conferencing, and give our Design Partners control of the screen to perform usability tests of prototypes or early builds of the next product release. We try to schedule all the tests on one day, analyze the results, and make recommendations to product management and engineering on the very next day.
The changes we make based on the usability tests range from simple wording changes to large re-organizations. For example, the results of one test indicated that our Design Partners had trouble with the term “Investigate Breaches”, but that changing it to “Compliance Alerts” made the user interface more usable.
Figure 4: Changing “Investigate Breaches” to “Compliance Alerts” improved usability
The results of other testing led us to recommend that we change the naming of an alerts page. Originally, the page was called “All Alerts Console,” as shown in the figure below.
Figure 5: The original "All Alerts Console"
The Design Partner feedback led us to change the title “All Alerts Console” to “All Alerts” as shown in the following figure:
Figure 6: Revised "All Alerts"
Perhaps the most significant change we made in ViPR SRM 3.0 based on Design Partner input was the overall organization of the navigation tree on the left. In this case, we asked Design Partners to perform a card sort to place views into the categories that made sense to them. This helped us understand where views should be and which views should be together. The results from this exercise led us to reorganize the tree to remove an “ViPR SRM Solution pack” item that was buried and treat the entire tree as the ViPR SRM product. The results of the card sort also helped us to reorganize the tree based on the tasks that storage administrators would have to do.
Figure 7: The original and revised navigation tree in ViPR SRM Suite 3.0
The User Experience Design team is responsible for designing how you interact with the software interfaces of EMC products like ViPR SRM and the SA Suite. This team has found the Design Partner program very useful. The Design Partners keep us grounded in real-life situations and provide useful feedback on our designs. If you are interested in participating in the Design Partner program for ViPR SRM suite or the SA Suite, please send email to EMCUsabilityTesting@EMC.com.
We also invite you to follow our design blog.