How might we create a system that powers the entire business, and cover the needs of all internal employees, as well as power publishing capabilities for all devices - including web, mobile, voice and chatbot.
In 2016, REX was experiencing rapid growth. The company was at the point where it needed to scale versus test lot of hypotheses. As a result, the company had outgrown its MVP-homegrown CRM/CMS that powered the platform. The tool was buggy, and hard to use and incomplete in terms of feature set. Agents were resorting to Excel Spreadsheets, Email and Slack—which is typically the sign of an unmet need in an organization. We had to determine the needs of the system, and work with tech on whether it made sense to buy or build software, or a combination of both.
The goals of the project were to help internal employees improve productivity, and integrate all the communication with a seller, so each agent would better understand history and better coordinate efforts.
WHAT I DID:
Project Leadership, Business Systems Analysis, Feature Definition, Ethnography, Usability Testing, Service Design, Information Architecture and Interaction/UI Design.
The first thing to unpack was the needs of the users and what tools they were using. Doing semi-structured research with Agents, Marketing, Customer Success Reps and Product, we were able to determine what features were needed. We plotted the service blueprints of each type of user, and identified what types of features they would need, and how they would integrate with one another.
The next challenge with this was to figure out a concept of the relationships of the systems and data objects, and the types of systems needed. Working with the development team, we investigated analogs (types of systems and software that currently exist) and compared our needs to current systems out there. There was no way we could create all the systems we needed at once, so we broke it apart several ways, and decided on 4 main chunks - Publishing CMS, CRM for Sales, Project Management for Home Selling, and Scheduling. The communication issue would have to be broken up in terms of pre-conversion versus post conversion; communication that belonged to the “home” was associated to the project and communication with the customer went into the CRM, while reporting would be handled in a different application, and subsequently out of scope.
We ideated on concepts and relationships at first. Seeing as the system was very complex, we needed to get a handle on information priority an how it would relate to the user needs. We did concept mapping to organize concepts and data. Once we had some models, we took key flows and ideated on how the page flows and architecture might work.
Next, we got down to page level wire framing and prototyping that was tested with the different agent user groups. Collected feedback for planning and integrated changes.
Then we created a release plan and created a series of prototypes for rapid testing. Seeing as the agents were all in the same location as the product and design team, we were able to move fast, doing several iterations, making improvements, and prototyping. In the meantime, we were documenting flows and service blueprints to illustrate how the improved application would change process flow. Our roadmap started with feature parity, and then integrated one key piece of functionality with each release.
Release plan was broken into themes after we had discovered needs and roles within the system
The final product of the first batch handled basic CRM features, while we used a Slackbot to test the scheduling flow.