Helping Sales Sell

Dates: Fall 2017 - Winter 2018

My Role: UX Architect

Disciplines involved: Information Architecture, Interaction Design

Deliverables: Requirements, Wireframes

Context

IBM GTS Sales Essentials is an internal IBM website for salespeople in IBM’s Global Technology Services (GTS) group. The purpose of the site is to serve as a place where salespeople can go to stay up to date about GTS offerings and access resources for client engagements.

My role

In my role as an UX Architect, I accomplished the following:

  • Guided the project team out of the discovery phase and into focusing on requirements for an MVP

  • Moved projects out of discovery and into creating high-level design requirements

  • Created wireframes and detailed UX specifications for both the desktop and mobile web versions of the site

THE PROBLEM

In November 2017, I was approached by my team to take over this project from another UX Architect who had to take a leave of absence. The project was in disarray, and had stalled out during the Discovery phase. I was tasked with getting the project back on track, and guiding it through to completion.

The original home screen:

The Sales Essentials team asked for our help in redesigning the current Sales Essentials website. They wanted us to create an MVP of the new site, which was to be a stripped-down version of their ideal. Our team was asked to help them figure out what should be in the initial MVP redesign, and to create it.

The client wanted a new version for Sales Essentials done for the following reasons:

  • New CMS: They wanted to migrate to a new content management system in order to make the site easier to update and manage

  • Search: They were unhappy with their current search experience

  • Poor navigation: Users were complaining about the site being difficult to navigate

  • Outdated design: The current site design was old, and the client wanted to update the site to a more modern design

  • Personalization: The client wanted to make the site a more personalized experience, and wanted to take the initial steps to get there

  • Centralized content: Content regarding offerings was scattered all over internal IBM sites, and there was a legitimate need for a more centralized site

The project was done with a distributed team in the US and India. Most work was done remotely, so we did not have the benefit of collaborating in-person.

THE SOLUTION

DISCOVERY

The first thing I needed to do was get up to speed—and fast. A great deal of documentation had been generated in the preceding months. I quickly realized that it would take many weeks just for me to pour over it all. So, I decided to start with stakeholder meetings with key team members and the client.

The people I interviewed were:

  • The Project Manager

  • The UX Architect that I was replacing

  • The client sponsor

  • The content specialist on the client’s side

  • The development lead, whose role was interesting in that he had spent many years working with Sales Essentials, and had a great deal of knowledge about the content and end users

After those interviews, it became apparent to me that there were a few key documents I should focus on to bring me up to speed:

  • A Content Map created by the previous UX Architect that was useful in learning the types of content there was on Sales Essentials, and how relationships were constructed

  • Results from a survey of around 700 users that had recently arrived

In addition, I learned the team’s high-level requirements for the site. They still needed to be sorted through into MVP, as opposed to “future” stacks. We held a meeting to discuss which of these would be in the MVP based on the survey feedback and technical limitations.

MVP vs "nice-to-have" spreadsheet

Once this process was complete, I felt that I had enough information to start creating high-level design requirements.

DESIGN REQUIREMENTS

At this point in the project, I decided to have a Design Requirements phase. I don’t do these for every project I work on, but I chose to do them here because:

  • We needed to start focusing the project discussion on the details of how we were going to execute the MVP

  • We needed to find a way for the design team to determine the scope and complexity of the work in order to provide a refined estimate (number of pages, any imagery that might be needed)

I utilized the handling of Design Requirements as a way to initiate discussion and commence information gathering. This way, my team could begin designing screens efficiently, bypassing the creation of an epic document that required finalization before design could begin.

Since we were a distributed team, I decided to use a shared folder on the cloud to create requirements. I started by chopping the problem into manageable pieces to help focus the discussion. For this project I created two folders:

  • Modules: things that would affect several or all pages (site nav, common content modules)

  • Pages and Templates: Individual pages or templates incorporating modules and unique page-specific content

 

Requirements showing Pages and Templates folder

Requirements showing Pages and Templates folder

Example of a requirements page.

We went through several iterations on these with the client. Once the design team was comfortable with the information we had, we moved into creating wireframes.

WIREFRAMES

The wireframes for Sales Essentials were created in Sketch. I utilized the existing design standards for internal IBM sites as a starting point.

I started with the Site Navigation first in order to help verify the site structure. Afterwards, I moved to a template that had many content modules that would be re-used throughout the site. Once these were done, I moved on to the rest of the wireframes.

My wireframes were done in Sketch in order to create a shared file with our Visual Designer. I kept these at a medium fidelity with limited annotations in order to move them quickly to Visual Design as opposed to getting stuck in iterations.

Before sending my wireframes off to the client for review, I had our Visual Designer take a look at them in order to discuss any feedback and additional ideas he had. Once I had incorporated his feedback, I met with the client and dev team to discuss the designs and any feedback they had.

Early version of site nav wires

Early version of site nav wires

Home page wireframe

Home page wireframe

Service Line template wireframe

VISUAL DESIGNS

As wireframes were completed, they were handing off to a Visual Designer to flesh out further. I provided feedback and guidance throughout the process.

 

DETAILED UX SPECS

Once the comps were finalized, I focused on creating detailed UX specifications. Changes had been made to the design during the comp phase, as is typical, and I updated my wireframes accordingly. Afterwards, I created detailed specifications for each page and delivered them to the client and development team.

Detailed UX Specs for home page

I’ve included the entire set of UX Specs for download:

MOBILE WIREFRAMES

Once the detailed specifications were delivered, I moved on to creating wireframes for the mobile version of the site. It was decided to do these after the desktop version was done, as the user survey results from earlier indicated that very few users would use the site on a mobile device. However, it was good to show the development team how the site would render in a responsive way for smartphones.

I designed for the smallest breakpoint allowed according to the internal design standards (320 px).

Mobile wireframes showing site nav

I’ve included the entire set of wireframes for the mobile site for download:

Outcomes

Following the delivery of the UX & Design specs, the development team built out the site and had a successful launch. I, along with the visual designer, provided QA assistance during the development process.