Benjamin West

Building a Full-Service FF&E Procurement Application



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.

Like one of our manufacturers, there was a moment when we realized our small problems could become something bigger.

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

Research Process:

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.

Coordinators at both the project- and accounting-level are the most significant users in terms of time spent within the app, but their directions and objectives are driven by the goals and concerns of directors and other executives throughout the company.
While project management and procurement-specific workflows informed the majority of the existing app's functionality, the intricacies of our accounting processes were a challenge to fully grasp: they help us work within the funding schedules of major publicly traded REITs (real estate investment trusts) and provide us with a major competitive advantage in our industry.


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.

Employee Findings:

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:

Client Findings:

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.

Executive Findings:

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.

Design Phase

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.

Hand sketches for nearly every major view in the application helped me to gain a full understanding of its data and scope.
Throughout the process, I also relied directly on data from the existing application to inform interface decisions like the average number of purchase orders per project, or the typical length of a specification identifier, which is provided by the project's interior designer.
Low-fidelity wireframes were useful for quickly iterating on the application's structure.

A high-fidelity prototype was built to get rapid feedback on specific workflows and layouts that differed significantly from the original version of RPM.

Final Design

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