Real Estate & Development Technology (REDTech) is a team of ~200 at WeWork that builds the tools powering the company’s radical expansion throughout the world. After my time leading the Journey Design team, I was asked to move into an interim Director of Design role for REDTech managing four designers and one researcher.
When I joined, the primary product was called “Stargate,” and it was stretched to a breaking point. Like many legacy codebases, it was made up of modules that were built in different programming languages, and had grown together into a brittle monolith. It was used by much of the company to track progress across our real estate deals, architecture and design construction projects, and even to track the economic health of our buildings.
In concert with Product and Engineering leadership, we decided to start to split out the individual products into stand-alone apps (built on a revamped, shared database) using React for the web apps and developing native iOS/Android versions as well. We knew that this would allow individual squads to design and build more efficiently, and that it would reduce the (very real) possibility that a change made in one code base would take down the entire ecosystem.
As a Design team, we had an exciting opportunity to break from the past, build apps that were more user-centric, and implement a new and improved design system to improve the usability and ease of building our new suite of apps. As a newly arrived design manager, I knew that I had to set a new tone for collaboration within our team and with our peers.
First, I set up separate meetings with the leads from Product and Engineering to understand what had been going well and not so well in their work with the Design team. Then I shared what the Design team had said in response about their experiences with these same teams and we discussed the differences and similarities between the two. We were able to identify some really great areas of overlap between the teams’ feedback, which I turned into a new shared process between the three teams. It included more up-front user research and opportunity ID, the establishment of product and design briefs, and formal user validation of mockups and prototypes.
We also implemented a Design Research Sprint process for longer-term initiatives and product launches. Our design researcher and I collaborated with Product and Eng leadership to identify knowledge gaps, sketch out global research plans, assign teams, and then execute on the project and its subsequent synthesis.
Coming into the role as a relatively new manager and an interim director, I knew that I had a lot to learn very quickly. I learned that approaching this sort of situation with a “novice mindset” (in my case, a real one) all but guaranteed that my peers and team members would trust me with their unvarnished feedback and input on a better process. That being said, I also found that it can be risky to pin your future on overhauling a process that’s been in place for years, because if the new process doesn’t work any better it reflects poorly on your leadership and judgment.
I short-circuited this by reminding others that we were engaged in an iterative “design process” for our design process. In other words, we were beta-testing a number of new approaches, none of which were rigid or permanent, with the goal of shipping better product with less frustration.
The new research sprints that we implemented enabled our colleagues from outside the design team to learn best practices for interviews and observation, get out in the field with users, and to arrive at much more user-focused product ideas. One key learning that I had from these sprints is that it’s often not enough to present the research results in isolation; a critical next step is to work together with the broader product and engineering teams to create new ideas based on the research, thus feeding back into the ongoing design processes at the squad level.