"Everything is Design... Everything!"
Cisco.jpg

Cisco: Services Redesign

 

Cisco: Services Redesign

Service Profile is the first product touchpoint for Cisco’s cloud customers and needs to be a seamless experience. However, legacy design, poor information architecture and unintelligent content is hampering end user adoption.

Role and Responsibilities

As the UX lead on this project I worked on the following areas:
User Research: Collaborating with sales engineers and doing literature reviews to understand the problem space. Conducting feedback sessions with customers on the usability of designs.
Design Strategy: Defining goals and metrics for success.
Interaction Design: UI wireframing, Prototyping in Sketch and InVision.

Background

The services framework enables admins to create and add their own services to the service catalog and make them available to the application architect. Cisco’s earlier model of service creation was a painstaking process, involving lengthy forms with little visibility into application dependency. The goal of this project was to improve the service creation workflow and make lives of service admins easier.

I have omitted and obfuscated confidential information on this page to comply with my non-disclosure agreement, and the content does not necessarily reflect the views of Cisco.

Understanding the Problem

Inherited Designs

service is a mid-tier building block for an application and the first touch point in the product for Cisco’s cloud customers. Service admins live and breathe in the services profile page just like how business analysts spend their time with Excel. However, legacy design, poor information architecture and unintelligent content is hampering end user adoption. Below are some customer quotes about how they feel about the services experience.

“The Out-Of-Box (OOB) services that are included in the Workload Manager module are outdated and rarely used by our admins.”

“Service creation workflow is very lengthy and doesn’t show content relevant to the service type.“

 

Metrics for Success

What will success mean and how will it be measured? Based on the initial user pain points the success metrics of the project became clearer.

 

Preliminary Design Explorations

I began by mapping the information architecture and identifying where new features/actions could be introduced. One of the most common user pain points was with the lifecycle actions - they didn’t match user’s mental model of grouping or ordering. I explored several concepts to visualize the lifecycle actions data, and after several discussions with PMs, SEs, UI Developers as well as design reviews, we finalized a design direction and proceeded to create a higher fidelity solution.

 

High-fidelity Prototype

Next, I worked with the visual designer on this project to create some high-fidelity prototypes. We wanted to bring in a refresh from our design toolkit and make the interface more clean, modern and concise. During this phase I also worked with the technical writer on service definitions which needed to be surfaced in the UI per customers’ requests.

 

Feedback from User Testing

I conducted feedback sessions at Cisco Live in San Diego with both existing and potential customers. Participants went through the entire process with me, from creating new services, editing existing ones, to using them for single and multi-tier applications. I asked them questions in a semi-structured interview format and noted their questions and concerns at each stage. Follow up sessions were held remotely on iterated designs. I held 2-4 sessions each with 4 different customers. I then transcribed and coded the feedback into two broad groups of positives and areas where there was room for improvement.

 

Broader Impact

For the next release, I prioritized the need for having better App Profile integration from a UX perspective. Getting buy-in from engineering and PM became easier once they were presented the feedback from user sessions. I then collaborated with them to define the screen flow for an integrated import and export experience.

Dependent parameters was another feature which impacted the broader app management experience while enhancing the service definition phase by introducing new service types.

Such feature enhancements involved more efforts on the logic and definition phase than UI changes. This meant spending more time and effort collaborating with other stakeholders to document the workflow of features.

 

Reflection and Learnings

Redesigning the services experience was challenging. Since we were proposing something that was completely different from the current system, it took a lot of convincing other stakeholders and explaining to them why we are doing this in the first place. We also faced some reactive and directive feedback that "this is too simple, it's never going to work" and "why are we not doing this instead?". A lot of our time was spent convincing stakeholders that improving the services framework is key to the product. However, it was very rewarding to address the end users of an enterprise service.

This was also one of the first projects where our design team conducted in-depth user research along with multiple feedback sessions, which influenced the design process every step of the way. I also learned a lot of lessons on the way - not only gaining a fairly good understanding of cloud services but also lessons about how bringing change is an extremely challenging task. It requires a lot of self-belief and an attitude to take an initiative and never give up.