I currently work full-time at Benjamin West. Benjamin West is a leading procurement management company for commercial real estate. We help specify, source, manufacture, and install the furniture, fixtures, and equipment ("FF&E") that goes into buildings like hotels, resorts, offices, and senior living facilities.
From 2012-2016, Benjamin West experienced year after year of exponential growth. For much of 2017, the story seemed similar: months of lucrative project awards put us on track for another year of record business, but as mid-year approached, our executive team began to notice a few red flags: employee turnover - while still low by industry standards - had increased slightly, revenue from one important client segment fell against projections, and in an effort to streamline our bidding process as capital projects in the real estate industry exploded, we were struggling to fully understand the profitability of each project we worked on. While the company's performance was still historically strong on paper, there was a sense that something was lurking below the surface, so we began discussions to understand why these issues were becoming problematic all at once.
As we dove into each concern, a common thread began to appear: our proprietary project management application, called "RPM", was either a direct cause of some of the concerns we heard from clients and employees, or it was unable to help us answer our most pressing questions despite functioning at the core of our business. While many of our clients had told us that RPM was the best software they'd seen in the industry, it became clear to our executives that "best" could still be better, and they asked me to lead the project to understand what better might look like.
We anticipate the following conservative outcomes based on analyses developed during the research phase, and early tests with the new application:
UX Research & Design: Dave Stein
Visual Design: Brian Smith (FullStack Labs), Analdo Gomez (FullStack Labs), Dave Stein
Development: FullStack Labs
Internal Project Lead: Dave Stein
I set out to understand our problems by meeting with our project management, accounting, and business development teams, as well as our clients and vendors (furniture manufacturers), and by taking a deep dive into every aspect of our process. This involved many hours of group sessions, individual interviews, and technical discussions - both internally and externally.
As part of the process, I developed user profiles, process diagrams, workflow charts, and ultimately delivered a presentation to share my findings.The entire research phase lasted nearly six months.
The research phase generated a significant amount of findings that allowed us to answer the key questions surrounding our employees' and clients' concerns, as well as our own corporate needs.
As part of my research, I surveyed our employees on their overall well-being and job satisfaction. Despite the turnover we'd experienced, it turns out that most employees really enjoyed working at Benjamin West - except when it came to dealing with RPM. After further investigation, their greatest concerns were almost all related to fundamental UX and UI elements:
For instance, the most common workflow for any member of a project team is to log emails, phone calls, and other communications related to the progress of a given item. This happens hundreds of times per week, per employee, and yet this process required navigating through five different screens just to log a single message:
Although clients were generally satisfied, a number of common concerns arose, especially among our repeat clients:
In fact, the very first issue our clients' raised - our inability to provide the data they needed - stemmed from one of the issues our employees raised. When making important decisions about how to categorize data they entered into the application, our project coordinators were being forced to make decisions that they had neither the authority nor experience to make. For example, take the following specification for a "couch":
In this instance, most coordinators would've made the wrong decision at no fault of their own, mainly by categorizing this item as a couch when the costs should more likely be allocated to pillow fabrication and fabric (usually put together by a different kind of manufacturer). The end result - selecting the wrong product type and wrong manufacturer - meant our business development team would likely give our clients incorrect pricing data and vendor recommendations. A lose-lose-lose for our clients, our employees, and our company.
As mentioned earlier, our executive team was focused on better understanding the profitability of any given project. While we were profitable as an overall business, project-level performance was less clear. Together, we determined that the following elements would help us understand and capture a project's full profitability:
With these findings in mind, I developed core values that would ultimately drive the project's re-design. These values were based on playing to the strengths of the existing system, addressing its weaknesses, and delivering outcomes that were desirable to clients, employees, and executives.
This included the following insights:
The most interesting part about articulating these values and drivers was realizing how the fundamental goals of our processes had been abstracted away by the software's approach to accomplishing them: we work on equipping buildings with FF&E, but through the application, this task became about completing forms, not furnishing properties. In order to help our clients open their doors on time, we worry about dates, but the application was taught to only notify us when deliveries are late. We procure physical goods, but the application was built to process items as documents and reduce them to lines within reports.
My hope was that by identifying these underlying drivers, we could learn to focus again on the core aspects of our business.
I relied on our findings, values, and goals to inform every stage of the design. As shown below, this included sketches, wireframes, and multiple iterations of a prototypes built and tested within InVision before going into development.
Since we didn't have the capacity to develop the application in-house, we used our high-fidelity prototype to bid the project to development agencies. We ultimately decided to work with FullStack Labs, based in Sacramento, CA. In order to stay consistent with FullStack's development approach, I collaborated with their design team to build a final prototype using the MaterialUI library (based on Google's Material design system).
Here are some images of the final design:
To demonstrate how we solved just one issue raised during research, here's the tool we implemented to resolve the heavily nested message logging functionality (previously 5 screens deep, shown above). Now, project managers are able to access the message log via the nav bar, and can navigate to project-, purchase order-, and item-specific notes from a central window, or open directly on related notes from a number of quick access features located through the application.
In addition to the main application and vendor portal, we're delivering a consumer-style client portal that will focus on key concerns like cash flows and cash balances, approvals, and real-time reporting. I hope to share some details on that product and design process in a separate case study soon.
To learn more, please visit www.benjaminwest.com