MY ROLE
I am the lead designer on this project and I’m responsible for the experience strategy, UX research and the overall redesign of the product. I’m currently partnering with 2 content strategists, 2 product managers, a product management director, and an architect.
This project is still a work in progress.
THE CHALLENGE
CONFIGURING STOREFRONT REQUIRES CONNECTING DIRECTLY TO A WINDOWS SERVER AND OPENING AN MMC SNAP-IN
Our goal for this project is to create consistency across the other management UIs used across Citrix components which are now web based. In addition, we want to better align StoreFront with other components such as our flagship product Studio, creating a more consistent web-based platform for admins to use across all Citrix components. Lastly, the existing UI has deficiencies we would like to resolve as part of this — focusing on slowness and complexity.
Our high level goals are to:
Provide a more consistent experience with Web Studio which has been recently introduced for Citrix Virtual Apps and Desktops (CVAD) on-premises (non-cloud version)
Enable full remote administration of StoreFront servers using a web browser without needing to Remote Desktop into a StoreFront server
Make it simpler to configure new and existing StoreFront deployments with less learning curve compared with the current management console
Enable management of of multiple StoreFront deployments from a central location
Make it simpler to migrate between Cloud StoreFront and on-prem StoreFront, or to manage hybrid environments using a combination of Cloud StoreFront and on-prem StoreFront, e.g. for different use-cases or for redundancy
THE KICKOFF
UNDERSTANDING AND IDENTIFYING USER NEEDS
When I was first assigned as a lead on this project, I knew virtually nothing about StoreFront and its purpose for internal admins. In order to better understand how to solve these problems, I needed to understand our users' behaviors, their needs and how exactly they deployed a server in order to launch virtual applications and desktops. I needed to build empathy with their pain points and identify opportunities for enhancements.
With limited access to speak to admins directly, I set up a listening tour and interviewed stakeholders from different cross-functional areas in order to better understand the product, experiences, and users. Through these interviews, I was able to gain a high level understanding of how StoreFront worked and identify problems within the current console. In addition, I sat in on a couple of customer calls that one of my product partners facilitated and asked questions to better understand pain points which in turn helped me to build empathy with our users.
Key takeaways:
StoreFront is kind of a set it and forget it type of product with the exception of issues that may occur with deployments
The current console is slow, overly complex and not very intuitive when it comes to setting up a store
There’s no central location to manage all of their StoreFront deployments
There is a steep learning required and a lot of training in order to properly use the StoreFront console and admins would like it to be more aligned with Cloud StoreFront
RESEARCH
SETTING UP A DEPLOYMENT AND AUDITING THE PRODUCT
After now having a high level understanding of StoreFront as a platform, I wanted to experience first-hand what it was like to set up a deployment and create a store. I worked with our engineering team to gain access to StoreFront and leveraged our documentation to go through the set up process. By going through this process, I was able to build stronger empathy for our users who were having to set up deployments and create stores for customers as part of their tasks, sometimes as often as daily depending on how large their customer base was.
I captured screenshots as I was going through the process and documented the journey on a FigJam board. I also worked with another product designer to help identify existing Cloud StoreFront settings and focus on parities between the two products. By doing so, we were able to ensure consistency in duplicate settings throughout the configurations of the platforms.
I am currently working closely with two content strategists who are helping to identify all of the settings currently available in the StoreFront and help to simplify the configuration of those settings. We’re focusing very heavily on the information architecture problems from the original console that we’ve identified.
THE DESIGN
SKETCHING AND BRAINSTORMING
I set up multiple working sessions with stakeholders where we sketched and produced low fidelity designs to determine how we might go about laying out this new web-based console. Through these sessions we were able to come up with a variety of designs that we would then put in front of admins to gauge their initial reactions and capture feedback.
TALKING TO ADMINS
I facilitated a series of calls with CTPs (Citrix Technical Partners) and shared the early designs with them. Their initial reactions were positive and they didn’t have any major usability issues that they called out either. This indicated that we were on the right track for this redesign. Based on their feedback, I put together a series of concepts for the new console.
IMPROVING THE LANDING PAGE
One key area of opportunity that we identified early on was the landing page experience. Admins currently open up the console and their initial landing page only has two options — to either view stores or create a new one. This is something that I assumed was less than valuable to admins and that we could improve this experience.
VALIDATING ASSUMPTIONS
In order to properly validate my assumptions about the landing page and lack of value, I put together a survey in Qualtrics with a series of questions related to the landing page. These questions include determining the value of the current landing page and what they would rather see when they land on the console.
This survey is still live and we’re awaiting the analysis.