Background:
Ford Cloud Portal (FCP) is a platform that hosts cloud infrastructure services for Ford employees; such as Pivotal Cloud Foundry, OpenShift, MongoDB, etc.
Solution:
A one-stop shop for all cloud infrastructure needs.
My Role:
-
I led the process for a complete redesign to create an upgraded version of Ford Cloud Portal (FCP).
-
I worked on the project right from the first stage of user research, all the way to the final community launch.
Pain Points:
-
Alert messages are misplaced
-
Difficult to collaborate within users' teams
-
Service forms are long
-
Difficult to find things
Duration:
MVP Soft Launch: 6 Months
Community Launch: 2 Months
Success:
-
Average time to complete service requests by users was reduced by average of 12 seconds.
-
Drop-off rate was reduced to 27%.
-
Created a design system for this product.
*To comply with my non-disclosure agreement, I have obfuscated & redacted confidential information in this case study. All the mock-ups are recreated for purpose of this case study as they display the quality and research behind the design work done for this project.
To Begin With...
Earlier version of the product (let's refer to it as FCP 1.0 from now on) was created without any UX research or design process. So there were many existing, known issues conveyed by users and internal stakeholders via various communication platforms and FCP Roadshows (presentations to other Ford teams to spread the word about our product).
Already known issues:
-
Alert messages are misplaced
-
Difficult to collaborate within users' teams
-
Service forms are long
-
Difficult to find things
​
Alert Messages are Misplaced
-
FCP needed to convey alert messages and notifications on a regular basis. They were displayed on the top of the homepage, which looked different routinely based on quantity and urgency of the messages.
-
Users had reported that they mostly ignore the messages, as long as they're not related to the specific service they had requested.
FCP 1.0 Homepage
Difficult to Collaborate within Users' Teams
-
Service orders were tied to individual user ID of each user.
-
Users in client teams needed to separately collaborate with each other to understand what was ordered from FCP for their team.
FCP 1.0 Request History page with requests tied to individual user's ID
Service Forms Are Long
-
Filling out a long, time consuming request form was unavoidable before completing any service request.
-
Majority of users found the verbiage confusing and said not enough information was provided on the forms.
-
Users had to reach out to either their team members or FCP team or sometimes even service teams to understand what certain fields meant.
FCP 1.0 NameSpace Service Form
Difficult to Find Things
-
It was difficult for users of FCP 1.0 to find help and support documentation which used to end up in them having to reach out to us or service teams.
-
Our 'Help' page was provided in main navigation, which users found quickly. But it didn't have proper and abundant content, which left the users puzzled.
-
Service forms had almost no help regarding each of the service type it was representing.
-
Unless the user had visited FCP many times, it was reported that they found looking for some features difficult.
FCP 1.0 Lack of Help on Service Form
What Does Business Want?
Internal Stakeholder Review sessions, and 5-WHY analysis with some of our service teams revealed crucial insights.
-
FCP team was planning on collaborating with a lot more cloud infrastructure teams to host many additional services.
-
They wanted a more personalized “System knows me!” kind of experience for users.
-
Stakeholders wanted to add some type of a new feature that will help users see what other members in their team had ordered, making it easier to collaborate for them.
5 WHY Analysis Session with Stakeholders from Service Teams
Card sorting stages to capture internal stakeholder review sessions' insights
Getting Started With the New Version...
-
Based on feedback from FCP 1.0 and Internal stakeholder reviews, it was time to start with low-fidelity flow diagrams, sitemap and wireframes.
-
I closely collaborated with solutions architect to come up with new features or improved versions of older features, and make sure the updates were technically feasible.
Early stage wireframes
Difficult to Collaborate within Users' Teams
Package services based on application ID, instead of user ID
Long & time consuming forms
Use auto-fill for as many fields as possible, strategically placed help for confusing form fields
Difficult to find things
Complete navigational overhaul
Alert messages are Misplaced
Provide alerts in stable yet easy to spot location that doesn’t affect look of the homepage
Packaging Services
-
Based on issues reported by users and internal stakeholders, we needed to make the service order Application ID-based instead User ID-based.
-
It will make it easier for all users from the same team to see all services ordered from FCP at the same time. It will be easier to keep track of what parts of cloud infrastructure the already have, when was it ordered, when does the service expire, etc.
Early Stage Application Package View
-
During one of the design-testing iterations, users reported the verbiage on the ‘Create New Package’ was confusing. It was not obvious that the package has to be created only once for each application.
-
From the test participants some were developers. They mentioned that they don’t know some of the privileged information asked here, said they’ll need to check with their managers.
-
Upon discussion with Solutions Architect and PMs, it was clear that it was a security risk to let anybody create app packages as the packages were linked to billing via their App ID.
-
So it was decided that we’ll let only certain job profiles create packages.
-
During task analysis, some users assumed that since app package was providing application wide view for the entire team, it would also show their team’s remaining funds for cloud infrastructure. This gave our team idea to enhance this feature for the next iteration.
Mid Stage Create New Application Package Page
-
During later stages of testing, participants were chosen based on their job profile as there were two different use cases as far as creating/editing App Packages was concerned. Some participants were developers, some were PMs/architects.
-
A user from a major customer team reported that they don’t have permanent application IDs. They start working on an application, get everything set up and hand it over to their client teams.
-
Even though this was a fringe use case, this huge client team used and depended on FCP a lot for their cloud infrastructure needs.
-
I brought the issue back to my team, we had a session with key personnel from both teams. I presented the design done so far to them and understood some issues their team will face with current app packaging. Later I interviewed two more users from their team to get a concrete data of their use case.
Later Stage Create New Application Package Page
This crucial insight added a third type of persona (PoC Persona) to our already existing group.
-
Based on data captured from internal stakeholders and users of this particular group, I proposed idea of ‘App package transfer’. Collaborated with the architect to make sure it was feasible to implement, updated the mockup and got it green-lit from both teams.
-
Per user feedback from previous stage, collaborated with billing team and added ‘remaining funds’ graph on the App package view page. So users will be able to see how much cloud infrastructure budget their team has left before placing orders.
-
During testing, there was a strong need noticed for more helpful messaging around the new feature of app packages. Users were still not sure that it needed to be created only once and that afterwards every time their team members order something from FCP, form fields will be auto filled for them based on the app package.
-
I proposed and created a “how-to” video for users. Our team also collaborated with the communications team to do Ford-internal marketing via newsletters, monthly FCP roadshows, etc.
Transfer Application Package Page
Redesigning Service Forms
-
App packaging was going to allow some fields on the service forms to be auto-filled. These fields happen to be the ones users were having the most time filling as they needed to check with their teammates.
-
Based on observations during task analysis, I made some verbiage updates for the service forms and added on-hover tooltips for especially confusing fields, as that was reported to be a major issue for users.
Mid Stage MS-SQL Service Request Form Page
-
In the next round of data capturing, users were very happy with auto-filling fields related to Application ID. But some services had a field called ‘FIM group’ which was not linked to App ID, so it wasn’t being filled.
-
Providing FIM groups while service provisioning was a huge problem reported in FCP 1.0 as well and with new feature of app packaging, it still persisted.
-
I had pairing sessions with the architect and the tech lead to find out whether we can figure out a solution using existing APIs.
-
We decided that all FIM groups the user is part of can be retrieved from their log-in session and displayed in a drop-dpwn on the service form (instead of them having to enter in an input box). This makes it easier/quicker for users to choose a certain service related FIM group based on the group's name.
Late Stage OpenShift Service Request Form Page
-
Some of the tooltips were considered too long and users were still ignoring some of them while missing out on crucial information.
-
I decided to move some information outside tooltips in a more stable location on the forms. This information was absolutely important, if missed could end up in an error or wrong service request.
-
I made sure only short tips were provided in tooltips. For longer technical explanations, I decided to provide information icon with on-click pop-ups.
-
For information outside direct scope of FCP, strategic links (stating "What's This?") were placed on the forms.
-
Finally I did a round of technical writing sessions where multiple pairing sessions were done with me and one of the PMs to make sure all the verbiage used was apt, technically sound yet clear.
On-hover Tool Tip
Information Icon with on-click pop-ups
Crucial Static Messages
External Links
Help on Service Forms
Navigational Overhaul
-
Based on issues reported by users as well as management’s plan to expand the amount of services provided, I needed make some major navigational changes.
-
I made some low fidelity flow diagrams and rapid prototypes. Presented them to cross functional internal stakeholders. Based on feedback, made updates, fleshed out higher fidelity version of the prototype to test with users.
User Flow
Early stage flow diagram
Early stage Rapid Prototyping
Homepage
-
Originally the homepage was inundated with all service tiles available on FCP, along with some non-crucial information.
-
I created multiple rapid prototypes of the home page with the goal of making it less cluttered, easy to find information as well as aesthetically pleasing. They were tested with users in 5-second tests in early, low-fidelity stages and A/B test in later, high-fidelity stages.
-
Eventually with ever increasing number of services I decided to provide only categories of services on the homepage instead of each service tile. E.g. platform as a service, container as a service, etc.
This homepage navigational option proved to be confusing and redundant by users.
Users were confused to see App Packages along with other services categories. SE persona didn't need to see the App Packages.
Search function was difficult to implement in MVP timeline. All search terms could not be included in time. And we still needed to show all services that FCP had to offer in some form.
Various low-fidelity home page navigational options tried in early stages
Navigational Menu
-
FCP 1.0 had repeated user feedback about user not being able to find things, especially help, service docs, how to contact FCP team, details about certain confusing fields on service forms, etc.
-
Different user-types, even though needed to perform different kind of actions, had pretty much similar goals to achieve. So I designed for an object-based navigation menu and had it tested during various testing phases to find most optimum solution.
-
The important but new feature of ‘App packages’- it was crucial to provide it in the correct place in the whole navigational flow of the product.
-
I tried out many design/testing iterations with access provided to app packages from the home page, top navigation menu, on the actual service forms and fine tuned to have it in the most optimized place.
FCP 1.0 Homepage
Mid-stage Mock-up
Later-stage High Fiedility Mock-up
Finding Help and Support Documentation
-
It was a known issue in FCP 1.0, where it was difficult for users to find support documentation for the services or to find help directly about FCP. This was especially a bigger problem for new FCP users, new Ford employees or a few users without much technical background.
-
I tried out different points of access for them throughout various testing iterations. Certain combinations on the top navigation menu and homepage locations turned out to be the most favorable locations.
-
Post soft launch, I initiated the effort of collaborating with each service team to get as much useful information and helpful links regarding their service. And designed a dedicated landing page for a centralized location for all this information.
Later Stage Homepage Mockup
Redesign Alert Messages
Better Alerts Notifications
-
I tried out many options to make sure alerts were not taking up crucial real estate on homepage, while not changing its appearance. Also it was important that users didn’t miss out on the notifications.
-
I tried out different designs in each usability testing variations. In one of the prototypes, majority of users were not noticing the alerts item in navigation menu. The ones that did, were confused by the landing page with all the alerts listed that were not leading anywhere.
-
After a couple of design iterations, I landed on a design where the users seem to easily notice ‘alerts’ icon on header due to ‘active’ status and having a drop-down on the homepage didn't take the users out of flow.
-
Having specific service related alerts on each of the service’s landing page made sure users did not miss notifications crucial to them.
Later-stage High Fiedility Mock-up
Later-stage High Fiedility Mock-up
Next Steps
Usability Maintenance
Once the community launch was done, it was time for me to create a usability maintenance plan for the ever expanding FCP.
It included:
-
Regular heuristic evaluations of the product
-
Pairing with front end developers to fix UI maintenance issues
-
Creating a standardized design system that can be used by UI developers and fellow designers, for easier communication between design and development side members of the team.
-
Have monthly meetings with PMs to discuss what design updates can be done to improve the FCP experience.
FCP Design System
KPIs for Success
Final stage was community launch within Ford for IT, Mobility, Finance, Data Analytics and other teams who need cloud infrastructure services.
-
Average time to complete service requests by users was reduced by 12 seconds..
-
Average Drop-off rate was reduced from 43% to 27%.
-
Frequency to ask for help (over Yammer/to other team members) did not reduce considerably. But most of the new quarries were regarding the new features of FCP instead of existing services and how to request them.
-
Quantity of services ordered per month did not change immediately. But metrics such as this take time to reflect values.
-
In 3 years after MVP and total 5 years after it's inception, today FCP is the platform of choice within Ford to provision cloud infrastructure.
Mind-mapping of one of the online survey results from users from various client teams post community launch