Turner Construction Co. manages mega-projects: construction projects in excess of $1 billion, such as skyscrapers and hospitals. Delays in the scheduled work on a mega-project site present a huge source of increased costs and reduced profit—and a significant motivation to better understand the varied causes of these delays and develop ways of preventing them or responding more quickly to mitigate problems.
At Turner, I joined a design team that was focused on reducing schedule delays on mega-projects. Our task included researching why Turner’s current progress-tracking tools were failing to deliver value and how our team might design a solution that could provide more user-targeted information and thus greater value for the company’s superintendents.
Our four-person team worked from Turner’s offices in Oakland, Calif., for five months to create user-focused desktop and mobile solutions. Our goal was to research the needs of Turner’s superintendents, design a technology that could help them perform construction planning tasks more quickly, and then present our results and recommendations to the Turner executive team.
This case study describes my work in designing a desktop prototype that led to organizational change at Turner. My most valuable contributions were to facilitate the design and strategy workshop, transform the findings from Turner’s internal research into a design project plan, design several interactive prototypes, and train the team to conduct qualitative interviews and carry out evaluative product research in the field.
Delays to the construction schedule were increasing costs. permalink
As a construction project gets underway, tradesmen enter the site, do their work, and hand off that work to the next team—from pouring concrete for the foundation all the way to completing the interior finishing and decoration. All of the hand-offs from one work team to the next are defined by the construction schedule.
The parade of trades. Construction projects run on schedules that dictate the the sequence of tradesmen and activities at the site.
When teams fall behind schedule in their assigned work, they create delays for the teams that follow, and this puts the final delivery date for the project at risk. Such delays are common in construction and pose a big problem for the industry. A McKinsey report acquired by Turner Construction showed the following:
“Schedule delays add an average of 20 additional months and 80% additional costs to mega-projects.” — McKinsey Co. report for Turner’s industry
When Turner’s executive team considered the potential risk to their profit margin on upcoming mega-projects, they were eager to find solutions that would help their work teams stay on schedule by being more responsive in mitigating any delays.
Becoming more responsive to construction delays required new technology. permalink
The speed at which problems are identified and resolved is critical to the success of any operation. Think about a time you sent in a support ticket to your IT department, and they responded that they would get back to you in 24 hours. If that problem prevented you from working, then your company stood to lose a lot more money because of your inactivity than it would have lost if IT had responded to your problem in one hour or less. Similarly, internal research conducted by Turner Construction showed that the company would lose less money due to schedule delays if the superintendents responsible for monitoring a job could respond more quickly to the problems tradesmen were having at the construction site.
A key activity on a construction site—the site walk performed by superintendents—has a significant impact on responsiveness. During a site walk the superintendent physically walks though the site to check the progress in each area and identify any problems. On mega-project sites like sports stadiums, this activity can take days to complete.
It is easy to see how the time starts to add up: a problem happens and takes days to identify, days to get reported, and even more days and several meetings to get resolved. Turner’s executives knew that the superintendents needed new tools to help them cut down the time lost in this process.
Technologies Turner had selected to solve the problem were falling short. permalink
When I joined the design team at Turner, the company had already begun trials of a third-party application to help superintendents perform site assessments faster. This application overlaid photos taken at the site every day onto a floor plan that the superintendent could access and review by computer. The thinking went this way: if the superintendent could assess the site and identify problems by clicking on photos viewed on his office computer (rather than by walking the site), he would save time, and the work team involved could respond more quickly.
This application, however, was falling short in two key areas:
While every inch of the site would be captured in photos, not every photo would need attention; only the photos showing areas that had problems would need to be reviewed and addressed. Since the tool did nothing to prioritize the areas the superintendent should direct the most attention to, the superintendent had to comb through hundreds of photos to find out where problems existed.
In addition, the application did not show which tradesmen were working on the area of the building that had been photographed. The superintendents needed to have this information included in the application so they could call the correct tradesmen and ask about any problems spotted in the photos.
To support superintendents who typically walk around construction sites to check on progress, our product would need to serve as a tool that saved time by allowing superintendents to assess progress from their office computers. Our product would improve on other solutions because (1) it would visually prioritize areas for the superintendent to review, and (2) it would identify the tradesmen responsible for each area.
The primary users for this project were Turner’s superintendents, whom we collectively named “Jack.” I got to know Jack through other members of my team who had interviewed Turner’s superintendents directly.
Known as a “super” on the job, Jack has huge shoes to fill as he manages the day-to-day operations at a mega-project construction site. He has to track the progress of hundreds of tradesmen in great detail while quickly prioritizing and resolving any problems before they affect the schedule.
“On the busy days, I’ve watched Jack answer requests on his phone every 8 seconds.” — member of Turner’s team
The demands on Jack require that he have a rare form of focus and discipline to excel at his job. I learned that it is not uncommon for companies like Turner to recruit military commanders to fill positions like Jack’s. To understand why, consider the roles that Jack must play.
Jack serves as a conduit between tradesmen and the Turner office. permalink
One of the most critical roles Jack plays is that of arbitrator and intermediary between the tradesmen that build the project and the team based in the company office, which plans, approves, and finances all project activities.
Jack’s site walks uncover problems at the job site. permalink
One of Jack’s main tasks as the site-to-office conduit is performing walking tours of the construction site (site walks) to assess the tradesmen’s progress. Jack visits areas of the building where work is not yet completed, talks to the tradesmen working there, and then documents the status of each area with paper notes and photographs.
“He’ll use whatever is available to him for taking notes. Sometimes he’ll grab some scrap cardboard, outline a $1 million change order for the project on it, then stuff it in his belt.” — member of Turner’s design team
After completing the site walk, Jack uses all the source information he’s gathered to notate the status of each area on the building plans—with attention specifically on those areas that are behind schedule or need a problem resolved. Then Jack takes his notated plans to a meeting with the in-office team, where any findings that may affect the project’s schedule or budget are discussed and evaluated.
Site walks take too much of Jack’s time. permalink
Jack’s problem with site walks is that they require too much of his time just to gather information. In addition, the Turner in-office team believes that Jack provides the most value for the company when he uses his expertise to assess progress and make decisions from the data gathered, not when he’s out walking around gathering data himself.
Therefore, to help Jack provide the most value for Turner, our design team needed to focus on a technology that would help Jack spend less time walking and gathering information and more time in the captain’s chair making critical operational decisions for the construction areas he was managing.
I worked as an independent contract designer on this project with two other contract designers. We reported to a Turner employee who was the project lead and product manager (PM). Our four-person team worked both remotely and on site at the Turner offices in Oakland, Calif.
The product manager (PM) and project lead was a Turner employee. The PM conducted the initial background user research, interviewed stakeholders, and conducted user testing with the prototypes I produced. Throughout the project, the PM organized our team’s meetings, established project milestones, and gave the final approval for my design deliverables.
As the sole UX designer and researcher on the project, I was responsible for developing the project plan for my team’s research and design, for creating research artifacts and design deliverables, and for training my team members to conduct evaluative user research in the field. I spent most of my time working with the product manager—to whom I reported and provided deliverables.
Turner hired a product design contractor with a background in construction technology applications from Autodesk. For this project, the product designer researched how well the applications Turner was using fit the needs of the superintendents and compared the pros and cons of competing products currently on the market. I worked closely with the product designer to turn our team’s research into design ideas and to hear and act upon his critiques in order to focus and enhance my deliverables.
A visual designer contracted by Turner created higher-fidelity mockups of the team’s designs near the end of the project. The PM used the visual designer’s work in our team’s presentations to executive stakeholders.
The scope of this project was limited to a desktop prototype designed for a single user. Our team had five months to research, design, and present potential technology solutions to Turner’s executive team.
We also limited the prototype’s features to those that would address a single floor of a building during the phase of a construction project that occurs after the “enveloping,” or the completion of the building’s exterior walls, the point at which the interior infrastructure work begins. The work done in this phase of a construction project is sometimes referred to as “MEP” (for mechanical, electrical, plumbing).
The main challenge for our design team was gaining ready access to the primary users, Turner’s superintendents. The superintendents spent most of their time at construction sites to which access was restricted. Only our PM and product designer had access to the sites. With fewer opportunities to test and iterate our designs with input and feedback from the primary user, we risked designing outside of the superintendents’ specific needs.
I determined that the best way to address this problem was to design paper prototypes and train the team members who had site access to test those prototypes with the superintendents. In this way, our team was able to get the critical feedback it needed to design a user-centered prototype.
At the time I joined this project, the initial design team at Turner had already spent months in research and discovery. They had observed superintendents at Turner’s construction sites, interviewed numerous stakeholders, and reviewed several competitors’ technologies that did not provide the value Turner was seeking. Yet, as this team sat on a mountain of research findings, the members were stuck as far as what to do and where to go next. What was the first problem they wanted to solve? Which roles should they focus on first?
To kick off the project and get the initial team members unstuck, I conducted a week-long design workshop at Turner’s headquarters in Oakland, Calif. My goals for the workshop were these:
Learn about Turner’s specific needs for a new technology.
Review the research the initial Turner design team had conducted.
Identify the user for whom the application would be designed.
Determine the problem we wanted to solve for that user.
Understand why Turner’s current tools were not solving the problem.
We spent many hours at the white board breaking down the hugely complex processes that underlie construction projects. I was greatly impressed by the deep expertise the initial team members brought to the meetings and also excited by the all the opportunities their research had revealed.
Outcomes from the workshop
We achieved our main objectives for the workshop. We decided on the primary user of our work—Turner’s construction site superintendents—and we clarified a set of problems we would need to tackle—the superintendents’ site-planning tasks. We also established what was missing from the current planning applications that Turner was using.
At the end of the workshop, our expanded team requested that I design an early version of the product that we could show to the superintendents. My next steps were to transform our team’s research findings into documentation that would guide my design process.
In the weeks following the workshop, I met with the product manager to refine what I had learned from the workshop. We focused on the needs, problems, and activities of the superintendents.
Capturing the provisional persona of Jack
I wanted to capture as a project deliverable all of the background research that the initial team had conducted so that we could share their efforts with other stakeholders. I translated all of the gathered research about the superintendents’ behaviors, needs, goals, and problems into a provisional persona that we named “Jack.”
I advocated for provisional personas in this project because I thought it would help me and the rest of our team stay aligned on the users for whom we were designing the application. We identified many user types during discovery, but we prioritized Jack as the first one to help. With Jack’s sole needs in mind, we could keep our decisions consistent with each other as we carried out our respective roles in trying to design the best product for Jack.
Describing Jack’s journey
The next step in my process was to distill what we knew about Jack’s site assessments into a simple set of activities and supporting tasks. By describing the journey Jack would take to complete a site assessment with his current tools (walking around with pen and paper), I could start to design the user experience Jack would have as he completed those same steps on a computer screen.
Building from the provisional persona, we outlined the three most important use cases involving Jack. Initially I represented these use cases as siloed processes to address one by one:
Comparing the progress contractors were making with the construction schedule
Visually confirming work had been completed
Managing the initial steps of a RFI (a particularly costly type of escalation known as a Request for Information).
In follow-up, the PM and I refined our conceptual model into an experience map that treated Jack’s activities as as a series of phases that had corresponding tasks. We then aligned these tasks to the features in our design that would support Jack as he complete the tasks.
I advocated for a journey map since it provided the design team a common language and visualization for Jack's experience.
In this case study, I will cover just two of Jack’s activities that the team focused their efforts on:
First, we would provide a way for Jack to review all of the uncompleted areas of the construction site that were being worked on each day.
Second, we would provide a way for Jack to see which tradesmen were working on a given area so that he could contact them and inquire about progress.
After establishing an understanding of Jack’s needs and core tasks for our design team, I began to sketch designs for a digital prototype. I decided to create an interactive prototype for Jack because I believe that an interactive prototype is one of the best ways for a team to validate whether a design supports their user’s needs.
The PM and I decided to limit the scope of this first prototype to the first step of Jack’s activities (reviewing the site), which included the following supporting tasks:
Quickly identify the problem zones on a given floor of a building.
Determine which walls in the zone are affected by the problem identified.
See a photo of the wall(s) in question to verify the problem.
Taking inspiration from Jack’s paper process
I took inspiration for my design from samples of Jack’s annotated floor plans. I could see that Jack marked up paper floor plans by shading in areas, highlighting walls, and making annotations.
In Jack’s world, progress is assessed at the level of walls. Tradesmen work on walls, and when all the walls of a zone (e.g., a room) are completed, the zone is completed. When all the zones are completed, the floor is completed, and so on throughout the whole building.
I assumed that if I sketched designs that were familiar to Jack, we could incorporate into the prototype a user experience that would be familiar to him. For my early sketches I focused on a single floor plan view that, prior to completion, had zones with different statuses or stages of work.
Creating a click-through prototype
After presenting several rounds of sketches to our team, I got a green light to continue refining with digital tools. I created low-fidelity wireframes in Sketch app and then imported my work into Framer Classic to create an interactive prototype.
The next step would be to get this prototype in front of Jack so that we could understand the following research questions: How well does this prototype help Jack identify which zone and walls need the most attention, and can it show him what the problem is by using a photo?
Restricting access to Jack: a complication permalink
With a prototype and research plan, I was ready to start testing our design with Jack, and this is where we faced our biggest constraint. The only place where Jack could meet with us for user testing was at the construction site, and the only people on the team authorized to visit the site were the PM and product designer. This complication raised a concern: How would our team be able to make progress in evaluating and adapting the application? The team members with authorized access had no experience with the digital tools I had used to create a prototype, nor did they have any experience with user testing.
I knew that to set up the team for success, we would need another tool for the job. After discussing options, I recommended that we use paper prototyping. The following assumptions informed our decision:
Jack was already using paper as a medium for his planning tasks, so the medium would be familiar and accessible if we used paper prototypes.
The learning curve for paper prototyping and testing is much lower than for digital prototypes. Using paper, I could get our team up and running quickly, and team members with access could quickly iterate the tests and uses of our design ideas with Jack.
While this design method was not a favorite at first (going back to paper from digital seemed like going backwards to our team), it proved to be quite helpful for making progress in our research and testing with Jack.
To get started, I designed a paper prototype, submitted it to my team for critiques, and made updates based on team members’ feedback. The next iteration would include more ways to filter and sort zones and walls according to their status.
We also decided to add features to the design that would help Jack with the second step of his site assessment activities: contacting tradesmen to inquire about problems or delays in the area of the site where they were working. Accordingly, the supporting tasks expanded to include the following:
Quickly identify the problem zones on a given floor of a building.
Determine which walls in the zone are affected by the problem identified.
See a photo of the wall(s) in question to verify the problem.
See which tradesmen are working in the zone that contains the problem.
Provide contact information for those tradesmen and the subcontractor they work for.
I created a prototype on paper to demonstrate how the screen space could be used to display different information that might be pertinent for the superintendent as he worked through these five tasks.
Once the team members who had construction site access felt prepared to test the prototypes and do the iterations on their own, they took the paper prototypes to the sites and conducted evaluative research sessions with several superintendents.
Iterating the design from evaluative research permalink
Incorporating more details about subcontractors
As I checked in with team members on their progress, we started to see a pattern emerging from the design iterations and thus gained greater clarification regarding our assumptions about Jack’s needs.
At first, the iterations I reviewed had expanded in the amount and types of information available for Jack. There were new ways show contractor information, organization hierarchies, activity feeds, and photo streams, just to start.
Yet in each new session with Jack, it became clearer that he did not need the additional filters, controls, or ways to manipulate the data. Rather, Jack simply wanted a visual display of information that would help him understand the status of specific walls in conjunction with the type of tradesmen working on them.
Feature creep serving another user
What the team had not seen creeping into our process were the needs of another user: the project manager. For that user, a design with multiple levels of detail regarding activities and subcontractor company hierarchies helped them track performance and plan resources. Helping Jack meant putting project management features aside and focusing our iterations on the visual identification of the tradesmen working on each wall.
Returning to Jack’s core needs
As I continued to meet with the team after their prototyping sessions with Jack, two ways to visually identify tradesmen emerged. The first way was an icon system, where each trade had a symbol that acted as a status indicator and filter. The walls would remain colored-coded based on their state of completion.
The second way was by adding color to the walls on a floor plan view according to the type of tradesmen that worked on it. In this view only the walls that were completed would be highlighted in the tradesmen’s assigned color.
This tradesmen-colored view became the favored approach with the design team after making a connection to a in-field practice used by the tradesmen themselves: paint striping. In the practice of paint striping, each tradesmen uses a spray paint with a unique color to mark walls and zones that are completed by them. The design team decided that if the same coloring system were used in the prototype, it would provide Jack the clearest connection between the prototype’s floor plan view and photos captured on site.
At this point our team concluded that the best solution to the design problem was to have the visual designer take on the assignment.
The main problem to be solved at this point was to determine a way to visually allow all of the work statuses to show in the same frame in a way that made it easy to understand the status of a given subcontractor at a given time, without having the amount of information overwhelm the superintendent. The visual designer continued the team’s iterations and created several UI mockups that were used for presentations to executive stakeholders. Not all final assets could be shown for this case study.
We finished the project within the time constraints and within budget. The final deliverable was the PM’s presentation of our research, prototypes, and mockups to the executive team. The work completed on this desktop prototype was included along with our work on a mobile prototype and a reporting dashboard for management users.
Overall, the results of our efforts were well received, but the executives decided to put the project into backlog while they decided whether to pursue further development with internal resources only, to collaborate with an outside partner that would co-fund the investment, or to try to persuade outside vendors to build these features into their existing products.
The findings from the project impressed Turner’s executive team with how much could be accomplished in such a short time by using design-driven methods. As a result, our process was used as a model to form Turner Labs , a new department that would seek out and support innovative projects throughout the organization.
Lessons learned as a designer and researcher permalink
One of the most important lessons I learned from this project is that in the future I need to ensure that access to the primary user is available before kicking off a design or research effort. An equally significant lesson was ensuring that the research question and the iterations of the design stay focused on the user’s most important tasks and to prevent “feature bloat” from creeping in and taking over the project.
These valuable lessons will play a key role in guiding and focusing my work on future research and design projects.