Backstop for Outlook
Product Launch: Bringing CRM functionality to the Client's Inbox
Redesigned Backstop for Outlook Plugin
Calendar Functionality for Backstop for Outlook
Summary
For this project, I organized a cross functional team to build a new tool for a contractual obligation to a prospective client. This effort resulted in the client signing for a significant amount of seats beyond what was initially discussed. Additionally, by rolling this tool out to more clients, we are able to begin sunsetting a tool built on older technology that requires significant development effort to maintain, and expand the value that clients received from our platform overall.
Defining the Problem
Previously, my company had a tool that could take certain activities from a client’s Outlook and attach them to records within our system. It was built as a “Thick App” , meaning it had to be directly installed onto a user’s system. This was difficult for users to install and update on their systems due to security requirements, and difficult for our developers to update and troubleshoot.
Loss write up which directly mention Outlook tooling
Loss write up which directly mention Outlook tooling
It also was not able to handle the actual creation and modification of records within our system, which was a major requirement for our client. Since a lot of important information and documents came to them via email, they were looking for a workflow that didn’t require them to leave the context of their inbox. In the past, we had lost potential clients due to a lack of a competitive Outlook tool.
Previous Installation Process
Sending emails in the previous app
Creating meeting notes in the previous app
Team Formation
Since this project had a tight deadline to meet the client commitment, it was important for us to get moving right away. The first thing that we needed to do was to organize ourselves as a team so that we could begin making progress.
First, I reached out to the product manager and I set up a Now/Next/Later Kanban board in order to help us get a rough priority of things that needed to happen. One thing that was clear was that we would need to learn a lot more about the framework we would be working with in order to understand what was possible. We also needed to get a rhythm going with the development team to keep us aligned throughout the project.
We set up a twice weekly standup that included the Dev lead, UX lead, and Product Manager, and used the Now/Next/Later board to help us strategize what needed to be done in the short term to get us to medium term and longer term goals. Each lead would give an update on their progress and ask any questions they had for the other functions. Then, they would be responsible for divvying any tasks up among their team. Since I was the UX lead on this project, it fell to me to define the UX strategy and to pass tasks on to my 2 other UX team members.
Now / Next / Later Notes
Discovery
One early and important task was to understand what specifically we were supposed to build, and what problems it needed to solve. Since this was for a prospect in negotiation rather than a current client, it presented an opportunity for us to impress the client and increase the contract value, but also carried some level of risk. We met with the sales representative and the internal stakeholders who were involved in the negotiations to understand what the basic requirements were.
Background review of Sales Process
Next, we needed to understand the microsoft outlook add-in framework as best we could. Microsoft had announced plans to phase out the technology that the previous app was built on and move to the new framework, so the decision to use the newer technology was an easy one. It also had the advantage of being web based, which made it much easier to install, update, and troubleshoot.
To learn what it could and could not do, we searched online and read the documentation for the framework. We also looked at an analysis of similar apps which had been conducted by another team member. This would form an initial base of approaches we could use to solve our client’s problem.
Competetive Analysis
Initial design variant with popout
Initial Design Variant with Panel
Entity Selection Concept
Design Round 1
Once we had an idea of what approaches we could use, we needed to put something together that would allow us to get customer feedback early on in the process. This was an opportunity to show this potential client that we were listening and responding to their needs as well. We decided that we would build out a high fidelity prototype in Figma that we could go through with them. Since we would be showing them this early in the process, we could afford to make significant changes if needed.
I worked with my UX team to produce a rough research strategy document and two rough prototypes that illustrated different approaches to solving the problem. We reviewed these with our cross functional team, and decided to move forward with an approach that leveraged a modal for the interface rather than a side panel. We then tailored the interview script and the prototype to tell a story based on the requirements we had gathered and our understanding of the client’s process.
First Client Demo
A few weeks after we began, we met with our client to show our progress and get their feedback. We wanted to be able to show a clear vision of the workflow that included results so that they could envision the solution within their process. We also wanted to leave enough room in the design to incorporate their feedback, since we expected our first ideas would have shortcomings that we had not discovered.
Using the script and prototype we had built, we walked the client through a scenario based around the use case as we understood it. We began the exercise with a few questions to get them to tell us more about the need they had and their current process, and to establish a benchmark. After we walked through the process, we asked them to rate the solution on a scale of 1 to 5 to get an understanding of how well it met their needs and what things could be improved.
As we had expected, the first version of the solution needed improvement. After gathering and discussing the feedback as a team, we agreed on action items to move forward.
As far as the design, the client did not like the popout form factor, and instead preferred to have a side panel within their inbox. They also found some terminology confusing, and wanted to be able to see their due diligence steps within the tool.
Additionally, by conducting this interview, we identified a number of potential enhancements that could expand the usefulness of the tool. Creating records was helpful, but occasionally they would need to update records that were already created. Additionally, seeing related records in context would allow them to make decisions quicker and speed up their process.
Images from the First Client Demo
Panel Concept Mockups
Wireframes to illustrate refined concept and flow
Design Round 2
Now that we had feedback from the client and action items that we had agreed on as a group, it was time to get to work on solutions. In order to get all aspects of the team moving, I created wireframes that incorporated the latest feedback. The developers could use these to begin building functionality, and I could pass them on to a member of the UX team who specialized in UI and interaction design so that they could be brought in line with our UI standards from other platforms.
In addition, we needed to get feedback from other clients. While the impetus for this project did come from a specific contract negotiation, we wanted to make sure that our solution would help other clients with similar needs as well. I worked with our PM to create a research plan and script that would allow us to get their feedback as well.
A few weeks later, we were ready to go back to our initial client with a new and improved product.
Image from the second client demo
Second Client Demo
For the second demo, we were able to show a working prototype in code that hit the MVP requirements we had identified before. The client was so happy with the fact that we had listened to them and built a tool that would save them time that they actually jumped out of their chair during the demo. We asked them to rate the solution on the same scale as we had used in the last meeting, and they gave it a perfect score. Ultimately, this client would end up signing for a significant amount of seats beyond the initial scope of the contract.
Further Feedback
Now, it was time to test our solution with other clients, and get feedback on the enhancements we were considering. We decided that it would be best to demo the MVP in the actual code that had been created and use Figma prototypes to show off features we were considering.
Through this process, we learned that our solution fit some client types better than others. Specifically, the solution was built around the needs of our “LP” or Limited Partner Clients, but lacked some features to make it useful to our “GP”, or general partner clients. Additionally, some users of the previous software relied heavily on the calendar integration, which was not yet built out for the newer version.
We used this information to help us refine and prioritize our backlog. Since it was more important to our business to prioritize growth within our LP client segments, and since the previous app was still functional, we prioritized the features that would be net new functionality over having feature parity.
Beta Program
Once we understood what the priority of our backlog was, it was time to begin forming a strategy to increase our client adoption of the tool. The first step would be to conduct a beta program with a handful of clients so that we could stay in close contact with them and spot any issues that arose as more people used the tool and received periodic updates.
We reached out to a mix of LP and GP clients, and after meeting with them and demoing the tool, came away with 10 Beta candidates. Right away, we spotted a potential issue - some clients did not have the requisite permissions to install add-ins into their instance of outlook. We quickly developed a script that could be used to tell their IT team what they needed to know in order to get the software up and running. Luckily, since this was a web based application, once it was installed, there was no need for the IT team to intervene further to receive updates.
We kept in contact with our beta users in order to identify and fix any bugs that came along, and kept an ear out for their feedback. After they had been using the software for approximately a month, we reached out to set up a meeting and get ratings on the same questions that we had been asking throughout the process. Our beta testers rated the tool 4.5/5 , indicating to us that it was ready to be rolled out to a wider audience.
Image from the second client demo
Roadmap Development
Throughout the process, we were continuously building and releasing more features based on the feedback we had heard. Our beta testers were a great source of knowledge as we went from idea to prototype to code.
Typically, every opportunity I had to get in front of clients, I would try to have a few research questions on the agenda. This way, in addition to getting ratings on the current functionality, we could continually learn and ideate to make the tool better. Based on this feedback, we made the choice to prioritize areas of new functionality to get a broader section of clients using the tools, and pursue feature parity with the old app as a second priority to allow us to begin sunsetting it.
Most feature ideas started out as a discussion within the cross functional team. We would discuss something that we had heard from a client, and come up with ideas to address it. I would work with the other designers to ideate on possible solutions as lower fidelity comps, which could then be brought back to the team for discussions around feasibility and which solution worked best. As things were developed, the UX team members were responsible for reviewing the work done and pointing out any corrections to the UI that were needed.
For research sessions, I would usually recommend an approach and begin the structure of any document used. Then, it would be shared with the team, and all team members would be encouraged to add research and interview questions, which we would then triage together in order to have an interview script that hit key points while allowing us to explore questions as they arose and have ready prompts to learn more about our clients. Members of the Dev, PM, and UX teams were usually present for most interviews, and I specifically encouraged my UX colleagues to observe research sessions.
Wider Rollout and Promotion
Once we felt confident that we had squashed all of the bugs, ironed out all the kinks in the experience, and built a robust enough feature set for wider adoption, it was time to begin rolling the tool out to a wider audience. To do this, we needed to coordinate with several other departments.
Throughout the development process, we had shared occasional progress updates at our regular company wide meeting. Now, It was time to announce the release of the tool. We gave a presentation that outlined the capabilities, release date, and benefits to our clients so that everyone internally could know what was coming, and certain departments could expect us to reach out.
The first team we coordinated with was our marketing team. Since this tool was going to be available on the Outlook Add-in store, we needed to create a listing that explained its utility in a way that was in line with our brand guidelines. We also needed to create collateral for our sales organization to use when presenting the tool to clients and prospects.
Next, we met with our client care team. We demo'd the tool, and showed them the documentation that we had created for installation and troubleshooting.
Finally, we conducted demos with our sales organization, which consisted of our sales team and our relationship management team. By letting them see it first hand and ask questions, we could help them understand which clients it might be a good fit for, and give them answers to the questions their clients would ask.
After the release date had come and gone, we continued working with our marketing team to broaden the awareness of the tool among our clients. I gave live demos of the tool at our annual user conference, and the PM on the team gave live online client-facing sessions that ran through different use cases.
In the first 2 quarters after release, we grew usage steadily, reaching over 300 monthly active users.
Handoff
Once the product had been successfully developed and launched, it was time for me to spend time focusing on other initiatives. The cross functional team was in a groove of meeting regularly, metrics were established for OKRs, and the development pipeline was running smoothly. I had brought in another designer to interface with the team over the course of a few months, and she was able to step in and take the reins.
Ultimately, the project had gone from a client initiative to a major value add that was very popular among our clients. It helped us land one of the largest contracts in our company history, and then branched out to provide more value to other clients and keep them happier with our software.