Reinventing the Sales Network

THE PROBLEM

AWS traditionally communicated with their Partners through events, direct email campaigns, and an online portal.

Our research demonstrated that Partners were getting lost in disparate information and finding it difficult to use whilst on-the-go. For the business team, there was also little opportunity to accurately measure Partner engagement or tailor content for specific audiences.

---

THE SOLUTION

The project had an ambitious target to solve a number of business challenges in less than four weeks. To manage the evolving requirements, we structured our processes around the five key areas of Design Thinking:

1. EMPATHISE

To generate the internal product demand, AWS had already spent time with the targeted users and established a number of key pain points. This was helpful to move discussions forward quickly but meant our team felt at a distance from the users they were solving for.

Any attempts to progress didn’t seem to work. We were relying too heavily on the prior knowledge of the team and our concepts were solely based on hypothesis 🤔.

Lesson 1.

To solve a problem you have to develop A deeper personal understanding of the issues.

It was essential we aligned quickly; we didn’t have the option of formal User Research due to time constraints. To develop a better understanding of the user needs, we sourced our own interviews with Sales teams. Our focus was mainly on users working in the tech sector with prior experience of the Partner Channel.

This lightweight solution was by no means ideal, but it gave the team a stronger foundation. We were then able to run short empathy building sessions and create empathy maps for prototype personas.

---

2. DEFINE

Using Affinity Mapping, we established common themes in our research and began to refine problems into short Point Of View statements. This exercise guided problem definition but more importantly it highlighted challenges from different user roles.

Lesson 2.

Problem definition and concept ideation are not mutually exclusive exercises.

We produced a large collection of statements that were filtered to remove any repetition. Clear leaders emerged in the results, which were particularly rooted in the user’s ability to simply get their job done ✅.

The objective of adopting the job story format was to encourage the design process to focus on motivation and context, and de-emphasise any particular implementation. However, at this moment in time ideation naturally begun.

---

3. IDEATE

Discussion around the primary stories allowed the team to agree that the best solution would be a centralised mobile app, with a supporting management platform and CRM integration.

Group brainstorming with stakeholders outlined a content strategy and produced five concepts that formed the vision of the ecosystem:

1. Gamification
2. Personalisation
3. Equipment
4. Engagement
5. Measurement

A modular approach to the architecture was designed to provide flexibility and support role based access control. We mapped the network of modules and features of the ecosystem within the five key concepts.

---

4. PROTOTYPE

To create a rapid prototype of the full app, our team worked in iterative design cycles around each module. Internally, our team maintained the solution structure using a central flow diagram and low fidelity sketches. Externally, User Interfaces and a style guide were shared with the business team.

Lesson 3.

Question everything. Be ruthless about what information arrives on your mobile interface.

Many of the data points for the UX already existed within AWS and had a related Desktop experience. Trying to replicate this mass of information on mobile meant the experience became text heavy and cluttered.

With strong support from the business team, we began to audit content before anything arrived for interface implementation. Under the pressure of the deadline it would have been easier to ignore this task, but it rescued a solution that was sinking under the weight of its own content 🙌.

MOBILE LEARNING

One of the critical prototype tasks was to make the AWS Learning platform simple to use on a mobile device. The Apps Learning module linked together a number of the product’s key concepts and needed to incorporate the existing AWS three tier structure.

Secondary Research showed that video and podcasts are the learning content types most suited to mobile. Through ideation and testing, the team designed a unique navigation that collapsed to save valuable space and utilised the AWS colour signposting for Products.

---

5. TEST

From lean testing sessions, we prioritised critical feedback and made refinements to the application. The complexity of the prototype meant the testing phase helped to uncover many usability issues.

Lesson 4.

Test experiences in the context of the user’s environment.

As we approached the demo, testing at the event location highlighted the internet connection affected the prototype performance. 🤔 📲 After some experimentation, the team solved the problem by deploying the Axure prototype using PhoneGap. It was a gentle reminder that contextual research is useful at all stages of product development!