Case Study: Sales Stimulation App
Disclaimer
Information, data, and graphics may have been altered in the following case study to ensure compliance and non-distribution of sensitive information. This case study aims to showcase the process more than the final product and its contents.
The problem
Very large corporations have a wide range of offerings and thousands of employees. Such a size can create difficulty in sourcing the experts needed to support sales initiatives from a local to a global level. Additionally, agile organisations, constantly improve, update and widen their offerings to sell cutting-edge products and solutions. This can make it harder for the sales teams to keep up with what sells on a regional and global level.
Our solution
CAST is a sales stimulation app designed for employees working in sales. It aims to increase the performance of the sales team by:
1. educating sales teams about all offerings
2. connecting them with the right experts
3. helping them track their sales meetings and progress towards their goals
All the above, while giving crucial information to the leadership team about performance and sales trends on a local, regional and global level.
The process
Alternative Kick-off workshop
Organising a full day workshop proved out to be quite a challenge. There were many senior stakeholders across the world and we didn’t manage to get one day that everyone could meet in one place. We still needed to clearly understand the business objectives, the target audience, the content needs, and the goals leadership had before we could frame an MVP and create a project roadmap.
Workshops like these are a great way to get everyone on the same page early on in a project. A full day of collaboration with the stakeholders is invaluable in helping us understand their goals, current pain points, and how we can help them improve their business but in that case, we had to come up with alternatives.
The stakeholders are comfortable with excel so we created a shared spreadsheet where we added questions about our users and user groups, their day-to-day work, the user goals and a wish-list of features our stakeholders wanted to see. We were incrementally answering questions on a personal level over a period of almost a month to ensure engagement and did several meetings to review everything together, group and prioritise features, making sure we are all in the same page and ready to start with the design process.
Stakeholder & User Interviews
At the same time, we started arranging 30 min stakeholder interviews while focusing mainly on the users. The interviews helped us understand that different stakeholders had different goals and we would need to bridge a lot of differences to create a common vision. We also used the data we collected in order to later create a set of features that we prioritised into a roadmap.
User interviews were the game-changer. Initially, the project sponsor and client was aiming at a small number of sales teams that are responsible for Platinum partners.
These users were confident about their expertise on what the company was selling and along with their super heavy schedules we started thinking that the app we were trying to build would face significant adoption issues.
While interviewing our users we realised that the project sponsors missed to identify that there was a potentially much larger pool of salespeople to whom our app could be more useful. Our initial potential userbase gave us more contacts and so we did more interviews.
The second round of interviews showed that the plan we were aiming to build was also needed on a local level, where smaller teams work. We were aiming to create an advanced directory of experts and a tracking tool but we had all the elements to also make it an educational and planning asset.
Download User Questions (pdf)
Creating a core team
It took around two months before we had inputs from all the stakeholders and users. The project manager and I conducted a total of 18 interviews with stakeholders from across the world and 15 interviews with potential users that initially were not in our plan. The thing that was clear was managing such a big number of stakeholders would be hard so we created a core team that would continue working on the project.
That’s how we ended up with a Product Owner, a Project Manager, a Product Designer (myself), a Project coordinator (sort of scrum master) and 2 Developers.
Ten months later the Project Manager left the company. I volunteered to absorb their responsibilities. We also got a part-time developer that was responsible for security, servers and integration with Single-Sign-On.
Synthesizing our data
While interviewing we were taking all notes on Microsoft Forms. In that way, we could analyse the quantitative data easily and we had a database with all comments and soundbites as well. That speeded up the creation of charts and gave us an idea of how things were progressing. We continued with adding on Miro an affinity map. The whole team worked on spotting the patterns and from them, we created the personas focusing a lot on the goals and pain points of the users. We drew a Journey Map where we allocated the pain points and we identified the opportunity areas where our work could be useful.
It is important to state here that while creating the Journey Map we identified an opportunity area that none of us had foreseen. We realised that Sales Teams need to start partnering with Subject Matter Experts from their planning days. And our app had to cater for this.
IA challenge
Early in the project, we came up with the challenge on how to structure all information.
Specifically how we would structure and group the following:
With a first look, Option 2 looks cleaner and well organised. This would be a fundamental decision on the product though so we had to test it.
I did some rough sketches of how the different structure could possibly look like and we used them to do a card sorting game with few of our actual future users.
I started by asking to have cards shorted in groups they think they make the most sense and most of them did seem to organise them similarly to Option 2.
Then, together with our future users, we mapped a journey they expected they could have in the web app according to their day to day responsibilities and needs.
There was where the situation changed a bit. Users’ journeys were in most of the cases within either the accounts, the countries or the regions area and very rarely would move across these three. Moreover, when moving from Regions → Countries → Accounts, users would possibly need to update the location — and do more steps for this reason.
That’s when we realised that Option 1, would actually save more time for the biggest amount of users.
Hotline
We managed to get the beta version of the application to 5 teams with a total of 25 users within 2 months. And that was a great success for us.
Apart from analytics, we wanted users to be able to reach us with quick feedback when they wanted to. That’s why we added a small footer that was fixed to the screen and always visible with a link: “Something not working?”.
This was a mailto: link directed to my inbox. Initially, it was not used at all but after sending a couple of emails asking for it to be used I got a total of 10 emails in the next few months.
This small button, apart from saving us a couple of times from quite some trouble, helped us identify potential users for our usability tests.
Usability Testing
Testing the initial prototype with 5 more users helped me refine the design. Here are three of our findings and how I worked on them.
1. Users miss the filters completely
It was clear from all participants that filters were hard to be found. They were very important though. Users would have to search through capabilities with names they probably wouldn’t know.
All of the capabilities were 54 and they were expected to increase over the next year — possibly even triple. As search would be most useful to users that knew what they were looking for we needed to cater for the users that were there to find capabilities on specific domains or with specific business status per account.
Solution: We stopped hiding the filters. We added them on the left side of the page along with the search bar and later included them in the onboarding.
2. Users don’t understand what’s “In focus”
The majority of users would have to see a very large number of capabilities and only focus on a maximum of 12 out of them at a full fiscal year. Users would have to find the capability every time they are working on it before they can input or find the needed information.
We needed to make a shortcut for them to the capabilities they were working on. And that’s what “In focus” was supposed to do.
Users though didn’t seem to grasp the content. When we tried to have “In focus” showed, they couldn’t find the rest of the capabilities and when we had all the capabilities shown many of them didn’t find “In focus”.
Solution: “In focus” capabilities would be prioritised and grouped on the top of the page.
3. Metrics were creating confusion
Metrics are a secondary element that is needed mainly after a couple of months of use of the tool. In the initial design, they were occupying a significant amount of space. Many users got drown to them and were wondering how they work and what they did.
We didn’t want the tool to be a team performance tool but the metrics were needed in order to identify trends and users to be able to compare how capabilities are selling across accounts.
Solution: I made metrics more discreet and we added explanations on hover. On a later stage, we hid the metrics during the first month of the FY. The time that metrics wouldn’t make as much sense anyway.
Google Analytics
We used Google Analytics to get a sense of which users and how our tool was used.
The biggest surprise we got from Analytics it was that were more users than what we expected that were using mobile platforms to reach the tool. Users with good news about a prospective partnership wanted to log it in the system and fill it in quickly. Many users were using the app to quickly locate the name of an expert and suggest it to a work partner. Both use cases were use cases we had underestimated in terms of how often they would occur. Additionally, they were very promising when it came to the adoption of the tool.
Screens
Results
In FY19 we managed to get 320 accounts on the tool. 100% of the capabilities within the projects were matched with experts that contributed to the sales process.
The tool got 2000 unique monthly visitors on April, May, and June of the first full FY in use. 600 unique visits were from users looking for educational content.
There was a 21% growth of successful sales meeting within these accounts from FY18 to FY19.
Future
We are constantly working on improving the project. Right now we are working on streamlining the planning process on the tool, creating personal profiles for the experts and improving the way educational materials are shared.
Learnings
At the initial stages of the team, we had a lot of pressure to deliver a product as fast as possible. This resulted in many sleepless nights and working weekends and most importantly the loss of the whole team working on the project. I was the only one remain in the company within this time. I put a case forward and apart from being the sole Product Designer I was also the Project Manager. This experience taught me a lot. I now always include developers from a very early stage — even from the sketches. I consult them, get to know their opinions and do all the arrangements and push backs on a one-to-one basis. In that way, there are no surprises when we go at a meeting and people don’t get overwhelmed with a design they are not able to deliver.
Users sometimes have no time even for a great product. As designers, we need to find the exact moment our products will be more helpful and start engaging them from there. In this case, this was the sales planning period. Context and engaging the users at the right time can make or break a product.
Clients know when there is an issue to be solved but they don’t always know what is the exact thing to be solved. As a designer, my job is to challenge the problem statement before jumping on the solution. That’s the only way to increase the value delivered. In this case, the original request was to find a better way to safely share an MS Excel that turned out to become a global internal tool.
Thank you
Thanks for reading my case study. See more on MikeMark.com, follow me on Twitter or connect with me on LinkedIn.
