Lack of communication between advisory team members and no insight into their decisions leads to distrust.
CBRE’s Advisory & Transactions Services division focuses on managing the buying, selling, and leasing of property for enterprise-level clients and consulting on their Real Estate Portfolio Strategy. An advisory team focuses on crafting a strategy that incorporates the experience a client wants for their employees, cost savings, workforce increases/decreases, workforce space needs, and moving offices to different regions.
Strategies presented to clients by advisory teams can be a mixed bag. Each team member will create a deck and present their plans to the client. If a team works closely with each other and stays in constant communication about what they’re doing, it will go well. However, in many cases, they don’t communicate with each other during their planning phases.
Advisory teams face three significant challenges when they are creating and presenting a Real Estate Portfolio Strategy to a client:
• Data inconsistency: One team member may be working from updated building data that they don’t share with the rest of the team, who may not have access to the same data resources.
• Strategy misalignment: There are multiple levels to the overall strategy handled by three different user types, and they don’t communicate with each other, often leading to inconsistent and conflicting strategies getting presented to clients.
• Decision-making transparency: Each team member creates plans in various places, mainly in Excel and PowerPoint or in Software as a Service (SasS) apps. They rarely show data supporting their decisions or the other options they considered, which is especially problematic if you know the client wants a specific option they’re not suggesting.
All of these challenges are on full display when presenting to a client, which makes CBRE look inept and leads to marathon rehauls of the strategy to make the client happy. The change in direction often leads to a less fruitful strategy for the client.
• Data inconsistency: One team member may be working from updated building data that they don’t share with the rest of the team, who may not have access to the same data resources.
• Strategy misalignment: There are multiple levels to the overall strategy handled by three different user types, and they don’t communicate with each other, often leading to inconsistent and conflicting strategies getting presented to clients.
• Decision-making transparency: Each team member creates plans in various places, mainly in Excel and PowerPoint or in Software as a Service (SasS) apps. They rarely show data supporting their decisions or the other options they considered, which is especially problematic if you know the client wants a specific option they’re not suggesting.
All of these challenges are on full display when presenting to a client, which makes CBRE look inept and leads to marathon rehauls of the strategy to make the client happy. The change in direction often leads to a less fruitful strategy for the client.
TEAM MEMBERS
John DeGore: Principal UX Designer, Rahul Surana: Product Manager, Chaith Yatham: Product Manager
The Green Machine empowers collaboration and ensures consistency by having all required planning in the same system, enabling data consistency and automated handoffs and updates.
The Green Machine is a proof of concept that intends to show the value of a comprehensive strategy tool that services the needs of the different user types in one system by being a singular resource for all client data, driving consistency across workstreams, automatically communicating conflicts to relevant users, and makes it easier to show all the options that informed their decision.
Data Management lets users upload and map data independently to provide the Green Machine with the accurate data it needs to make suggestions.
The Data Management experience consists of four phases: choosing your set and uploading the data file, Column Mapping, Data Validation, and Mapping Actions.
To upload data, the user will choose a data type and upload the file. The intent is to enable data syncing between a client database and the Green Machine database in a full release. However, the user will still need to complete the other phases for their data to be available to the Green Machine planning experiences.
After the file is uploaded, the system will prompt the user to match columns required for the dataset that it cannot do independently. Column Matching connects the new data to the related data in the Green Machine database. Data Validation will prompt the user to fix critical format and system errors. Mapping Actions asks the user to confirm or fix data point matches between the Green Machine’s database and the new data. Once mapping is complete, they go to a confirmation page summarizing the data changes and can notify the Portfolio Strategy Maker if needed.
With the Portfolio Strategy Designer, the Portfolio Strategy Maker can set the overall direction.
The Portfolio Strategy Maker is responsible for setting the advisory team’s broad strategic direction for a client. The Portfolio Strategy Designer helps them set that direction.
The Portfolio Strategy Designer will start with a suggested path based on their available data. The Portfolio Strategy Maker can modify it by tweaking the strategy parameters of savings and experience at a high level and modifying the business units’ space requirements and attendance policy. The Portfolio Path is their targeted goals based on the selected parameters, and the Opportunities Preview shows them metro opportunities ranked by alignment to those parameters.
After setting the Portfolio Path, the Portfolio Strategy Maker must account for their plans for employee growth or decreases by creating Headcount Forecasts and moving or adding offices to new locations by creating Labor Forecasts. Both types of forecasts are created at the business unit level.
Finally, they’ll be able to view the target states of their new strategy, which includes the addition of the forecasts, the choices they made, and how those choices differ from the previous plan, if applicable. They’ll also see a list of the Metro opportunities and who will get assigned to them.
Transaction Strategy Makers use the Plan Generator to make Metro Strategies a reality by identifying the most advantageous way to utilize a site and getting the best deals.
The Transaction Strategy Maker is responsible for finding the right property to meet the needs of the sites assigned to them in the Metro plan and determining if buying or leasing will be more advantageous to the larger strategy.
My Sites (Transaction Strategy)
On the My Sites page, the Transaction Strategy Maker will choose one of the sites assigned to them to start working on. The site page has four tabs: Site Strategy, Plan Generator, Saved Plans, and Site Data.
The Site Strategy tab contains strategy directives cascaded to them that they can modify or set themselves if none have been cascaded, and they can do the same for Headcount forecasts for that site. Then, they’ll use the Plan Generator to explore auto-generated plans that align with the strategic direction.
Site Strategy
The Site Strategy tab contains strategy directives cascaded to them that they can modify or set themselves if none have been cascaded, and they can do the same for Headcount forecasts for that site. Then, they’ll use the Plan Generator to explore auto-generated plans that align with the strategic direction.
Plan Generator (Transaction Strategy)
Plan summaries in the Plan Generator will show a simple Supply and Demand chart, Net present cost (Cost savings), and Utilization rate (Employee experience). The sidebar has a module showing the same values for the Current plan and a Plan comparison one that shows the Net present cost and Utilization rate of selected and saved plans. The Transaction Strategy Maker can drill into a plan to see variations, and each plan has a Plan Details page where the Transaction Strategy Maker can modify them.
Plan Details (Transaction Strategy)
The Plan Details page showcases a detailed Supply and Demand chart and the Net present costs and Utilization rates for the featured and current plans. It also shows the Transaction timeline, a plan of all the transactions needed for the site to meet the strategic goals. The primary transactions are owning property, leasing space, and leasing agile space, and they each have a subset of actions.
Saved Plans (Transaction Strategy)
In Saved Plans, the Transaction Strategy Maker can view, manage, and compare their saved plans.
Site Data
Site Data allows the Transaction Strategy Maker to view and edit all the site-related data.
Once the Transaction Strategy Maker has a plan they want to commit to, they will submit it and are taken to a summary page that showcases the differences between the new plan and the current one, if applicable. The system will cascade the direction down to Occupancy Planners and notify the Portfolio Strategy Maker that the plan is committed. Unfortunately, I could not finish this last part of the workflow during my time on the product.
Occupancy Planners use the Plan Generator to optimize the seat-to-space ratio for a site that aligns with the strategy goals.
The Occupancy Planner is responsible for finding the best arrangement of seats to floors for business unit teams while accounting for hard constraints like labs or executive offices on a specific floor. A team's headcount and attendance determine the number of seats they have.
My Sites (Occupancy Planning)
On the My Sites page, the Occupancy Planner will choose one of the sites assigned to them to start working on. The site page has four tabs: Site Constraints, Plan Generator, Build Plan Manually, and Saved Plans.
Site Constraints
In Site Constraints, the Occupancy Planner can allocate team seats to the floors with the hard constraints the team needs. For example, a lab may need to be on a specific floor to handle the required equipment. So, the team that uses the lab will have their seats assigned to that floor. Assignments made in Site Constraints are locked items in the planning stage. So, the system or user cannot move them during planning. The Occupancy Planner can make constraint allocations through a list view or seat stacking chart view. The Occupancy Planner can also edit Building and Team data here. The constraints are adhered to when the system auto-generates plans in the Plan Generator.
Plan Generator (Occupancy Planning)
Plan summaries in the Plan Generator will show a simple Seat Stacking chart, the Overall adjacency score (employee experience), and Free floors (cost savings). The sidebar has a module showing the same values for the Current plan and a Plan comparison one that shows the Overall adjacency score and Free floors of selected and saved plans. The Occupancy Planner can drill into a plan to see variations, and each plan has a Plan Details page where the Occupancy Planner can modify them.
Plan Details (Occupancy Planning)
The Plan Details page showcases the Overall adjacency score and Free floors for the featured and current plans. You can also view all the seat assignments for all floors the Occupancy Planner is responsible for at this site. They can view and modify seat allocations through a list view or a seat stacking chart view. Both utilize dragging and dropping or a form to reassign seat allocations. The Teams sidebar lets them search for a team and show all the allocated and unallocated teams. It also shows details about the team. The Occupancy Planner’s goal is to align the Overall adjacency score and Free floors with the larger strategic goals by optimizing seat allocations. The Occupancy Planner can also edit Building and Team data here.
Build Plan Manually is a Plan Details page with no allocated teams outside the hard constraints, and the system cannot optimize it.
Saved Plans (Occupancy Planning)
In Saved Plans, the Occupancy Planner can view, manage, and compare their saved plans.
Plan Summary (Occupancy Planning)
When the Occupancy Planner has a plan they want to commit to, they will submit it and are taken to a summary page that showcases the differences between the new plan and the current one, if applicable. There will also be a list of the chosen and saved plans with their Overall adjacency score and Free floors. Once they’re ready, they can confirm the new plan, and the system will notify the Portfolio Strategy Maker and the Transaction Strategy maker that the plan was committed.
Understanding the contexts of how the Green Machine would be used and by whom was vital for creating the Product Road Map.
Collaboratively creating in-context user scenarios increased stakeholder buy-in, drove product team alignment, and identified knowledge gaps.
When I joined the project, I found the Primary Business Stakeholder, the driver behind the Green Machine concept, had all these great ideas but stayed too high-level and used industry vernacular with the expectation that the rest of the team would be able to fill in the blanks. The problem was the Product Team expected to build the application was made of people who were not subject matter experts and needed concepts thoroughly explained to them.
I planned and facilitated a cross-functional workshop through Microsoft Teams and Miro to collaborate on narratives with the product team, user representatives, and business stakeholders to help them better understand the user needs driving the Green Machine Concept and the functionality the application would need. They could also provide a starting point for creating the Product roadmap and feature requirements.
We discovered reoccurring themes that we turned into core concepts, which became the early drafts of product roadmap features.
Core Concepts draft
Core Concepts
Creating these 16 narratives gave the team realistic scenarios to align the team, help build empathy, and educate others.
• The Primary Business Stakeholder now had a structured way to discuss feature expectations and requirements with the Engineering team and business partners.
• The Product Managers had a basis to start from when developing the data science team’s user stories.
• The Data Science team had more context for how the application would function.
• The Product Managers had a basis to start from when developing the data science team’s user stories.
• The Data Science team had more context for how the application would function.
We intended to turn these narratives into storyboards but realized there needed to be more clarity about who our users were first. Many participants were confused about the different types of users in the narratives, leading to a persona workshop.
The persona workshops identified 3 core-user types and 4 insights that confirmed the Green Machine as a market opportunity.
I planned and facilitated another cross-functional workshop through Microsoft Teams and Miro to collaborate on creating personas for the Green Machine to provide the team with clarity into user types. The workshop included the product team, user representatives, and business stakeholders as participants.
We identified 3 personas as the core-user types.
From those personas, we uncovered 4 insights that confirmed that the main features of the Green Machine would address market opportunities.
Insight One
Data quality is universally poor. Nobody has a consistent way to cleanse, manage, or analyze it. Leading to a lack of historical data to track against and an insurmountable amount of individual Excel files.
Data quality is universally poor. Nobody has a consistent way to cleanse, manage, or analyze it. Leading to a lack of historical data to track against and an insurmountable amount of individual Excel files.
Opportunity
The Data Management feature will create a centralized source for cleansing and managing client data and a historical archive for future analysis.
The Data Management feature will create a centralized source for cleansing and managing client data and a historical archive for future analysis.
Insight Two
Teammates are not staying in sync with each other and their direction, leading to misaligned strategies.
Teammates are not staying in sync with each other and their direction, leading to misaligned strategies.
Opportunity
The Green Machine will notify advisory team members when new plans are committed and inform them of any impacts to their responsibilities.
The Green Machine will notify advisory team members when new plans are committed and inform them of any impacts to their responsibilities.
Insight Three
All the analyses used to create strategy proposals are done manually. Anytime there is a change, everything needs reanalyzing and reformatting, and it’s always time-consuming.
All the analyses used to create strategy proposals are done manually. Anytime there is a change, everything needs reanalyzing and reformatting, and it’s always time-consuming.
Opportunity
The Green Mahcine’s planning tools do all the heavy lifting for analysis. The user can simply enter the new or changing data point, and the Green Machine will update the plan.
The Green Mahcine’s planning tools do all the heavy lifting for analysis. The user can simply enter the new or changing data point, and the Green Machine will update the plan.
Insight Four
All strategy projects start with a data dump and little direction, creating significant ambiguity for the team.
All strategy projects start with a data dump and little direction, creating significant ambiguity for the team.
Opportunity
The Green Machine will utilize the data and strategy parameters entered to auto-generate plans that meet the project's goals that users can explore or modify, giving them a starting point and cutting out a significant amount of time.
The Green Machine will utilize the data and strategy parameters entered to auto-generate plans that meet the project's goals that users can explore or modify, giving them a starting point and cutting out a significant amount of time.
While we had user representatives in the workshop, I interviewed 2 representatives of each persona to validate them. Now that we had a clear vision of our users, I integrated them into the narratives to create storyboards.
Product Strategy Maker-focused storyboards helped the business secure pilot partnerships with 2 clients.
I integrated the narratives, core concepts, and personas into 4 storyboards for that Primary Business used to help sell the value of the Green Machine and secure pilot partnerships. The people they needed to convince on the client side were Portfolio Strategy Makers. So I turned the “Comprehensive Strategy” narrative that served as an elevator pitch for the Green Machine and 3 Portfolio Strategy Maker narratives that focused on features the Primary Business Stakeholder knew would resonate with the clients into storyboards.
Before I could finish turning the narratives into storyboards, my priority shifted to developing conceptual wireframes to support the Engineering team.
Conflicting expectations and a lack of solid leadership required me to evolve how I collaborated and led me to drive feature definition.
I designed the Data Management flow as low-fidelity wireframes to move fast, but it required much iterating to define requirements.
The first user flow I worked on was Data Management, and the request was to keep it low-fidelity because this was just a concept, and we needed to move fast. I gathered requirements by iterating on the wireframes.
The Primary Business Stakeholder gave me a visual loosely defining the workflow expectations, and I created some initial wireframes representing a framework. It took a few interactions to get it to a place where it could be a functional interface. The Product Manager, Primary Business Stakeholder, and I collaborated in Microsoft Teams and Figma to identify requirements, and the Primary Business Stakeholder created diagrams in PowerPoint on the fly to answer my questions.
Initial diagram provided by Primary Business Stakeholder
Diagram created in collaboration session
Requirement diagrams
Early Data Management iteration
When we reviewed the Data Management wireframes with the Engineering team, they expected high-fidelity wireframes that met brand standards and covered every possible experience variation. Which was different from the direction leadership wanted to go.
To meet conflicting expectations, I started using CBRE’s design system to create wireframes for the Product Strategy Designer user flow.
To thread the needle between Business and Engineering, I started using CBRE’s design system to create high-fidelity concept wireframes. However, I only created the minimum number of wireframes needed to validate the concept. The CBRE design system provided documentation that covered most of the variations needed at a system level, like notifications and error handling.
This time, the Primary Business Stakeholder had very low-fidelity wireframes created in PowerPoint for product strategy planning at the start. However, they were generally sparse in detail, and I didn’t always understand the intended outcomes. I created some initial takes that represented what they laid out, and we started iterating through Microsoft Teams and Figma again. We were having trouble visualizing what the overall product strategy would look like.
Requirements collaboration session featuring Primary Business Stakeholder wireframes
After a couple of rounds of iteration with little progress, the Primary Business stakeholders started showing me the single-use CBRE applications they had taken some inspiration from. One of these tools, the PortfolioTransformation Calculator, stood out. It was simple, and the stakeholders said it was effective and loved by clients. So, I used it as the basis for the Portfolio Strategy Designer. Utilizing the form and chart interactions tailored to the Green Machine and added in the Opportunities Preview section.
Requirements diagrams and initial Portfolio Strategy concepts
Wireframes based on the Portfolio Transformation Calculator
We hit another rough spot when we reviewed these wireframes with the Engineering team. Even with a functioning click-thru prototype, they needed help breaking the user steps into features and functions.
I started using Story Mapping to fill the requirements gap for the Engineering team and cut down on design iterations.
We were agile, and I was told not to worry about having thorough documentation, but it became apparent that the Engineering team needed it. So, I set up collaboration sessions with the Product Manager and Primary Business Stakeholder to create Story Maps for Data Management and Portfolio Strategy flows to supplement the Figma prototype and track all the steps the users take and the associated inputs and outputs. Then, set up sessions to create a Story Map for the next prioritized flow, Occupancy Planning.
Data Management and Portfolio Strategy Story Maps
Occupancy Planning was not the subsequent step in the overall advisory team strategy, but our pilot clients wanted to test the algorithms that would support it. It made sense to work in parallel with the Data Science team on this. The Story Map for Occupancy Planner wasn’t perfect, but getting roughly 70% of the requirements upfront through it and having multiple Occupancy Planning applications in the market to analyze cut our iteration time in half. It also became a resource for the Product Manager to reference when writing the Engineering User Stories, helping shift the larger team to be more user-focused.
One of the big things I learned through the competitive analysis was the seat stacking chart interface, while being the standard, makes it hard to view relevant data. I addressed this by having a list view in addition to the seat stacking chart interface. Once I got the design in a place the Business and Product leadership were happy with, our next step was to conduct concept validation testing.
Early Occupancy Planning concept wireframes
Through concept testing, we validated Product Strategy and Occupancy Planning flows and uncovered some significant gaps in Occupancy Planning.
I planned and moderated concept validation testing for Product Strategy and Occupancy Planning. Both concepts had a 100% validation rate across participants. We learned that some of our labeling choices could improve and that users were interested in how scoring worked. In Occupancy Planning, we uncovered significant gaps in the data points they needed to create Occupancy Plans. The structure of the experience was good; I just had to find a way to insert all the new data points.
Story Mapping and creating a formalized UX backlog made incorporating the missing Occupancy Planning data smooth.
The previous times I collaborated to create Story Maps, they weren’t as in-depth as they could have been. That was a mistake I rectified in the update to include the missing Occupancy Planning data points. I would need it to be thorough to support the development of the UX backlog. Up to this point, the UX backlog of User Storie represented a to-do list created by the Product Manager with no requirements or insight into how it fits into Features and Epics. The lack of clarity in the backlog had to change to help with the continued need for more detailed documentation from the Engineering team and to support bringing on additional designers to help.
The Story Map for Occupancy Planning became more detailed by including the new data points. To save time on iteration, I validated the user steps and where the new data points would sit with the users: Occupan Planners, Including the users in Stor Mapping, ensured we didn’t miss anything this iteration. The user steps in the Story Map became the User Stories for an “Update Occupancy Planning” Feature in the UX Backlog.
Updated Occupancy Planning Story Map
I always had a loose set of UX Epics for the product, but that wouldn’t be enough to support other designers. So, I decided to create Epics and Features and populate them in the shared backlog. The initial Features of an Epic were:
• Story mapping to identify inputs/outs and step
• Design concept workflow
• Usability testing
• Emerald design consult
• Story mapping to identify inputs/outs and step
• Design concept workflow
• Usability testing
• Emerald design consult
I would use the Story Map to create User Stories for the “Design concept workflow” Feature. “Usability testing” and “Emerald design consult” had default User Stories for creating the test and prepping for the consult but would generate additional ones depending on each outcome. I also created a process for handling new features and refinements.
UX Epics & Features
Process for handling new features & refinements
This structure made it easy to create User Stories that new designers could pick up with little help and provided a through-line from inception to execution for the Engineering team. It also provided Project Management with even more detailed User Stories they could transition to support Engineering stories. I tackled a few of the structurally impactful User Stories for Occupancy Planning. I divided the rest between UX Designers who had part of their capacity allocated for the Green Machine, freeing me to focus on the flow for the Transaction Strategy Maker.
Reusable interface patterns created in Occupancy Planning and an improved Story Map significantly reduced design time for developing the Transaction Strategy Maker flow.
This time, I ensured that every relevant data point was identified and validated in the Story Map before I started designing. To prevent that time-suck, a rehaul would cause us to have a big miss like in Occupancy Planning. I even recreated a separate part of the Story Map for the Transaction and their relationships. These relationships are complicated because a follow-up action to one of the core three actions (Owning, Leasing, Leasing Agile Space) is primarily optional. So they have to be accounted for, but they don’t have to be enacted when the time comes. Having clarity around the data made it easier to design.
Transaction Strategy Story Map
I created a user flow hierarchy in Occupancy Planning that worked for Transaction Strategy and intended to use it in Metro Strategy. I reutilized the Site, Plan Generator, and Saved Plans pages with slight modifications to show the relevant data points for Transaction Strategy. In addition to two new pages, the Plan Details and Summary pages needed new designs that matched the Transaction Strategy Maker’s needs. The Product Manager and Primary Business Stakeholder had designs for the Plan Details page that they wanted to use, and I combined the best of both to do an initial design. We went through a round of interaction and got it to a place everyone was happy with. I had started working on the Summary page but was laid off before finishing.
Product Manager Concept
Business Stakeholder Concept
Transaction Strategy concept iterations
Post Project Assessment
What went well?
After realizing I needed to help with requirements, I started utilizing Story Mapping and made improvements each time I did one, ending with a version I will take to every project I work on. It helped bring the ambiguity of the different user types and their needs into focus in an artifact that empowered execution.
Collaborating with the Green Machine team members and user representatives was critical in creating those Story Maps, and they all were happy and willing to participate once they saw the benefit Story Maps provided. I had a Business partner with a strong vision but needed help making it a usable experience. They didn’t always agree with my methods or direction but trusted me enough to give it a chance. That willingness, combined with their collaboration, led to 100% validation for the concepts we tested and helped me design a reusable user workflow framework that made the experience better and easier to build & maintain.
What could have been different?
I should have stepped up and helped with structured requirements sooner. I asked to start using Story Maps early on, but I should have just pushed forward. Having a structured and defined UX backlog from the start also would have helped. Being the only designer on the product for most of the time meant I was always at max capacity, and having that backlog would have made it easier to manage and given the larger team insight into what I was doing.
What would have been next?
The Business decided to outsource Engineering for the product. We lacked an artifact to map all the data handoffs between user types, and it caused problems for the Engineering team. I foresaw this being a problem with any new Engineers that would be product on. So, while finishing up Transaction Strategy, I started creating an artifact to map all the data handoffs between user types.
Another thing that required documentation was how plan histories would be saved and managed; it was a vital feature that got pushed to the back to focus on releasing faster, and the engineering team was not accounting for the impact this feature would have in future releases. After finishing the data handoff mapping, my next step would be to focus on that while designing the Metro Planning flow.
We also kept a backlog of experience improvements that would have been implemented after the initial release of workflows for all user types.