diana
bloom
The Four Seasons
The Four Seasons Hotels & Resorts were losing market share to aggregator sites like Kayak and Hotels.com.
They wanted a solution that would .
Project Duration: 2 Weeks
Project Team: Diana Bloom, Kimson Doan
My Role: All tasks shared throughout the project
Deliverables:
-
Executive brief
-
Interactive Prototype
UNDERSTANDING PROCUREMENT
The first step in the project was to quickly educate ourselves on the procurement process and figure out how the pieces and parts fit together. We interviewed the client, then took steps to deepen our understanding by:
-
Talking to other people we knew who were involved in procurement
-
Surveying remote procurement specialists
-
Conducting card-sorting exercises
The card-sorting exercise helped us see where users tended to group activities, and through this we developed an "ideal" workflow.
Hover to scroll, click to enlarge
The three card sorting exercises helped to inform the "ideal" flow which allows a degree of flexibility and freedom throughout the process.
Process flow through vendor selection (user 1).
Process flow through vendor selection (user 3).
The three card sorting exercises helped to inform the "ideal" flow which allows a degree of flexibility and freedom throughout the process.
HEURISTIC ANALYSIS & USER TESTING
Once we clearly understood the steps and requirements in the workflow we started evaluating the application. We dug in and did a heuristic analysis, then conducted two live user testing sessions.
What we found:
-
The deal setup process lacked feedback and direction, and didn't inspire confidence in the application
-
The interface lacked consistency and cohesion
-
There was no contextual help
-
Users had no freedom during setup
Hover to scroll, click to enlarge
Susan owns a business and has used RFQs to request quotes for services and supplies. Based on her feedback, we were able to identify where the system fell short in helping users understand why they were taking certain actions. She provided many insights about weaknesses and opportunities for improvement in the process.
Matt provided feedback that reinforced the need for clarity on the deal page once the setup flow was completed. He wanted to go back through the setup flow to make changes because it wasn't clear what functionality was available on the page.
The heuristic analysis revealed areas of strengths and weaknesses. In this evaluation 100% is excellent and 0% is poor. We found the biggest area of weakness are in help and documentation, error recognition and prevention, visibility of system status, user control and freedom, and match to the real world.
Susan owns a business and has used RFQs to request quotes for services and supplies. Based on her feedback, we were able to identify where the system fell short in helping users understand why they were taking certain actions. She provided many insights about weaknesses and opportunities for improvement in the process.
PROTO-PERSONAS
Now we had insight into the problem areas, and before we started sketching we wanted to make sure we weren't missing any high-level needs. To address this we created three proto-personas with different backgrounds, viewpoints and experience levels based on our understanding of the target audience.
This underscored the need for efficiency, flexibility and user control.
Hover to scroll, click to enlarge
Key goals are highlighted, and from this we identified the flow and interface requirements to meet these goals. Proto-personas will be developed and fleshed out as the product gains traction and more users.
Key goals are highlighted, and from this we identified the flow and interface requirements to meet these goals. Proto-personas will be developed and fleshed out as the product gains traction and more users.
SKETCHING SOLUTIONS
As soon as we felt we understood the process, the problem, and the high-level needs, so we got down to business and started sketching. To keep the project in scope we limited our design focus to:
-
Deal setup flow
-
Deal page
-
Dashboard page
The client provided us with mockups from an in-progress UI redesign. We used these to underpin our solution, which evolved over multiple iterations through user testing and client meetings.
Hover to scroll, click to enlarge
Our original idea was to use a "funnel" model similar to what exists, but to expand the functionality and add more in-app guidance. Progressive disclosure was used to reduce the impact of multiple form fields.
To address the need for efficiency, we introduced the idea of providing pre-formatted, editable templates based on the deal type. We also added non-question requirement fields and colleague input capability.
Action cards are also included on the dashboard page where the user can respond in-line. "Create a Deal" and "Add a Vendor" buttons were also added to the dashboard as these are high-level functions that require visibility and easy access.
Our original idea was to use a "funnel" model similar to what exists, but to expand the functionality and add more in-app guidance. Progressive disclosure was used to reduce the impact of multiple form fields.
USER FLOWS
Our first design iteration consisted of a "funnel" - a series of steps that were required before the user sees the deal page. We shifted strategy after meeting with the client, who felt the deal page was still too hidden and wanted to see a different approach.
The user flows illustrate the original and final redesigned flow through the setup process.
Hover to scroll, click to enlarge
The original flow took users into a non-optional setup "funnel" that had no obvious way out.
The new user flow only has one mandatory step in deal creation. Once the deal is named, the user enters an optional setup wizard that steps them through the flow in a modal overlaid on the deal page.
The original flow took users into a non-optional setup "funnel" that had no obvious way out.
FINAL DESIGN & PROTOTYPE
The final design concept consists of an overlay on the deal page that highlights the steps users take to set up a deal, while allowing them to see page details and exit at any point.
We also rearchitected and optimized the deal page by:
-
Placing the requirements tab first since this is the most important information for team members
-
Combining public and private discussions under one tab to eliminate confusion and free up screen real estate
-
Displaying the activity monitor separate from the tabbed area
-
Adding action "cards" to the dashboard and activity monitor to allow users to take actions in-line
When the design was finalized, we created an interactive prototype using Axure.
Hover to scroll, click to enlarge
The original mockup of the deal page provides minimal guidance to users in the form of a set of tooltips. There were originally five tabs, with activity first and separate public and private discussion tabs. Buyer and vendor team information was displayed in a panel on the right, which could be hidden.
Modals walk the user through the process, familiarizing them with the layout and functionality of the deal page. Save and Exit can be used at any point in the setup process. The only required field is the deal name. The Activity feed appears at the right and is always visible. Action cards appear here, enabling users to respond to actions without leaving the section they're on. Requirements and Responses were left separate as user testing indicated it might be confusing to combine them.
Action cards can be responded to in-line. The cards on each deal page are exclusive to the deal. Cards on the dashboard are global.
The original mockup of the deal page provides minimal guidance to users in the form of a set of tooltips. There were originally five tabs, with activity first and separate public and private discussion tabs. Buyer and vendor team information was displayed in a panel on the right, which could be hidden.