Nick Dauchot
Product Designer
Made with

CONSTRUCTION SOFTWARE RESEARCH AND DESIGN

Employers Love Seeing Your Thoughts and Process

My Role: UX Designer

Project Duration: Six Months (2018)

Client: [confidential]

Methods: Competitive Analysis, User Interviews, Personas, Mental Model Diagrams, Prototyping, Storyboarding, Contextual Inquiry, Affinity Diagramming

Output: Findings and Recommendations Report, Prototyping

Synopsis: A large insurance company was interested in understanding the experience of estimating construction projects and how software might be used to assist in the process. In order to understand this, we scheduled interviews with real construction workers based upon two segments. These two segments provided insights into the estimation process from both commercial and independent contractors, whom had very different needs. The output from this project was a prototype for a software platform called which was designed with every step of the estimation experience in mind.


PROBLEM

Bidding is... Complicated

Bidding on construction process involves a lot of paperwork and data-crunching which could be automated by a computer. Poor estimates on construction projects can lead to low profits, damaging a contractor's business and reputation.

APPROACH
CONSTRUCTION SOFTWARE

Research: Competitive Analysis

I started out this project by creating a project strategy. The first step in the strategy was to get an understanding of all of the competitive products in the market that were geared towards helping construction workers bid on projects.

The competitive analysis took the form of a spreadsheet. The spreadsheet was used to get an understanding of all products and features within the competitive space. This data helped provide us with enough of an understanding about the space to generate a research plan for user interviews.

CONSTRUCTION SOFTWARE

User Interviews / Contextual Analysis

We ran sixteen interviews with construction workers from two behavioral segments. During these interviews we asked the participants to walk us through their process of placing a bid. We also gathered a pool of qualitative data related to variables of goals, needs, attitudes, behaviors, and frustrations.

These interviews along with the competitive analysis provided us with enough data to begin to formulate a strategy for product design.

CONSTRUCTION SOFTWARE

Personas

We first needed a tool to help us represent the data from our research. I coded all interviews based upon previously mentioned variables. I then mapped affinity between our two segments which helped me generate two user personas based upon our segments. These personas would be used to represent the end users of our design. 


CONSTRUCTION SOFTWARE

Mental Model Diagram

Using the data from our contextual inquiries, I helped build a mental model that would be used to represent the mental spaces that took place throughout the process of creating a bid. The mental model included high-level mental spaces as well as towers within those spaces to help identify patterns of thought or behavior.

After the mental model was finished, we were able to generate a list of differentiating and must-have features that our solution needed to provide in order to help our end user's (represented through the personas). We were then able to move into designing our product.

CONSTRUCTION SOFTWARE

Storyboarding

We started by combining the data from our personas and mental model diagrams to generate a narrative about a construction worker bidding on a project. The narrative included our newly identified opportunities, the experience of bidding on a project, as well as components of our personas. This helped us as well as our stakeholders visualize the journey our customer's would take with our product.

Once the storyboard was finished, we moved into designing the software itself.

CONSTRUCTION SOFTWARE

Software Design

We brought a team of real construction workers and a visual designer together to begin rapidly prototyping and testing a software product. This software was designed for desktop devices in order to support the long task of bidding on and managing products. We were able to test the software on real construction workers, and iterate on it as necessary.

Once the software was in a good place, we presented it to the project's stakeholders.

RESULT

Confidential


LESSONS

Recruiting

One of the biggest problems that I had in this project was with recruiting. A task of mine over the summer of 2018 was to recruit all of our research participants (16 construction professionals). This was during one of the hottest and healthiest Summers in Cleveland's history. I ended up calling over 200 construction companies and was able to schedule 16 (after a ton of push and shove), but it was a stressful and time-consuming process. Using a recruiter would have saved us time and would have brought in highly qualified participants. By cutting corners on recruiting costs, I'm afraid our team did more damage than good, and brought us participants whom in the end hardly fit our screening criteria. We had the budget.

Focus

Many times throughout this project, I felt the need to explore other opportunities while trying to design a product. Lack of focus on the software product we set out to design might have made our final result less desirable. For example, we invested a large sum of money and time to design a safety software platform, and spent a lot of time designing sacrificial concepts. Focus on the software we had planned to create might have created a better end results.