Strong-Tie UXR Documentation
Research Repository

Command Palette

Search for a command to run...

Q4 2025
  • Platform Model (BIM) Viewer
  • (Preliminary Report) Project Hub Research
  • Personas
Q3 2025
  • Estimating Tools Unification
  • Outdoor Living Solutions Pro Tier
  • Director Engineering Tab
  • Roles and Permissions
  • Cornerstone Point Offsetting Discovery
  • Truss Design Seal Submittal Workflow
Q2 2025
  • CS Engineer
  • Digital Solutions CSAT/NPS Survey
  • Past Communication Research
  • Director Admin Settings
  • Director Pricing
Q1 2025
  • License and Account Management
  • Estimating JTBD Survey
  • Product Materials Catalogs
  • Truss Studio Settings / Envdata
  • Residential Construction Ecosystem
  • Cloud Director Project Creation
Q4 2024
  • Platform Discovery Research Findings
  • Director Settings
  • Truss Studio Ribbon Bar
  • Cloud Director Roles and Permissions
  • Deck Planner Pro Features
Q3 2024
  • ICS Assessment and Platform Features
  • Document Management Services
  • LotSpec for Revit
  • LotSpec for Revit User Personas
Q2 2024
  • Platform Sprint
  • LBM Estimating Digital Portal Discovery
  • LBM Q2 Customer Interviews
  • Fastener Designer Prototype Testing
  • Production Scheduler
  • LotSpec for Revit Competitive Analysis
  • Field Verification
  • Kentley Insights Truss Market Research
Q1 2024
  • LBM Takeoff Tool MVP Testing
  • Anchor Finder
  • LBM Q1 Customer Interviews
  • Customer Connectivity
  • Reporting Manager Modal
Q4 2023
  • PDP Heatmapping
  • Pipeline Modernization
  • Truss Studio Envdata
  • Enterprise User Roles Prototype Test
Q3 2023
  • Reporting Manager Parameters
  • Customer Portal Jump
Q2 2023
  • Internal UX Team Satisfaction Survey
  • PDP Navigation
2026 Simpson Strong-Tie
Q2 2025PlatformGenerative

Past Communication Research

Research by Ian Wyosnick

Executive Summary

Background

This document synthesizes insights from 12 research interviews with Simpson Strong-Tie teams across UX, Product, and Development. The purpose is to uncover how customers currently communicate, identify pain points and desired improvements, and evaluate opportunities for an in-tool commenting and notification system.

Findings Overview

Across all interviews, teams described a common pattern: communication in Simpson tools is highly fragmented, manual, and often happens outside the product experience. Most customers rely on email, Teams, SMS, and printouts to share status updates, request help, or clarify issues. While the use cases for in-tool commenting, tagging, and notifications vary by product, virtually every team identified unmet needs for visibility, collaboration, or traceability. Customers seek asynchronous, contextual communication tied to specific documents, design elements, or production tasks, (e.g. similar to experiences in tools like Figma or Jira) or even custom-built internal systems. At the same time, concerns about notification overload, usability, and information visibility (internal vs external) must be addressed thoughtfully to ensure adoption.

High level takeaways are:

1. Workflow Visibility & Collaboration Needs

  • Most communication happens outside the tools (email, Teams, printouts), leading to lost context and extra manual effort.
  • There is no visibility into project status after handoff, resulting in "black box" workflows and frustration.
  • Customers want to leave notes tied to specific documents or tasks, especially quotes, drawings, estimates, and production batches.
  • Design decisions and project context need to be saved long-term, especially for audit, handoff, or dispute resolution.

2. Preferred Communication Styles & Feature Patterns

  • Tagging and asynchronous commenting are strongly preferred over real-time chat.
  • Internal teams referenced experiences seen in Figma, Jira, Confluence, Bluebeam, and custom tools as examples for what contextual, document-anchored collaboration could look like.

3. Notification Control & Information Access

  • Notification overload is a real concern; customers want granular control over when and how they get updates, and may be resistant to having "one more tool" they have to check.
  • Customers need control over visibility, especially to separate internal communication from communication happening with their clients or external customers.

4. Infrastructure & Environment Constraints

  • Many teams lack access to input devices or modern interfaces, especially in production environments (e.g., saw stations, batch prep).
  • Lean teams don't have bandwidth for chat or live support, but value structured, traceable feedback systems.

More detail on the findings informing these takeaways can be found below.

Recommendations Overview

Customers aren't interested in another platform like Teams or Slack. Rather, they desire embedding traceable, structured communication into the places people already work with controls to match the sensitivity of the data and flexibility to match the diversity of Simpson's tools and customers.

High level recommendations are:

1. Improve Workflow Visibility & Project Context

  • Introduce in-tool commenting anchored to context - Enable customers to leave comments directly on documents, drawings, or tasks (e.g., PDF annotations, elevation tags).
  • Capture historical notes and access logs - Store comment history alongside jobs; support versioning or activity feeds for traceability.
  • Align with familiar models for collaborative design - Use interaction patterns from Jira, Figma, and Bluebeam (e.g., inline comments, anchored threads).

2. Support Structured, Asynchronous Collaboration

  • Enable visibility control for internal vs. external communication - Allow customers to mark comments as internal-only or customer-visible, with clear cues and safeguards.
  • Avoid real-time chat and instead focus on taggable, threaded notes - Customers need lightweight, persistent discussions. Not Slack or Teams clones.
  • Design consistent commenting across tools - Ensure that layout, takeoff, pipeline, and reporting teams all benefit from a shared commenting framework.

3. Build Notification Infrastructure with User Control

  • Create flexible notification settings - Support preferences for @mentions, comment replies, file shares, and system events (with digest/mute options).
  • Trigger alerts from document activity and project events - Let customers subscribe to updates when a project is ready, a comment is left, or a document is shared.

4. Adapt for Production & Low-Interface Environments

  • Build kiosk-friendly message boards and alert widgets - Enable stations without keyboards to view and acknowledge key updates (e.g., machine status, shift notes).
  • Use pre-programmed messages for shop-floor communication - Provide buttons or touch prompts for customers to send standard alerts like "part recut needed" or "machine down."

Interviews Reviewed

All interviews were conducted by Abby Burkhalter and Nixa Espinola in November of 2024.

IntervieweeSummary Doc
Cesar Suarez (Director PM)Interview Summary
DirectorInterview Summary
CornerstoneInterview Summary
Truss Studio Design + Cloud ServicesInterview Summary
ProducerInterview Summary
Spec ToolsInterview Summary
OLSInterview Summary
BatchingInterview Summary
Pipeline LBMInterview Summary
Truss Studio LayoutInterview Summary
PipelineInterview Summary
ReportingInterview Summary

Findings Details

How do customers currently take notes or communicate updates during a project?

Across nearly every tool, notes are tracked manually in Word, Notepad, Trello, or even on paper. In most cases, these notes are not tied to the project context within the software.

"They need to be kept somewhere. And to keep them, like, with the drawing, with the project would be really useful." — Marc Marcoux, Truss Studio Layout Team

"Our customers used to leave a lot of notes... it's very asynchronous... remind myself later what the customer told me." — Eric Borgerding, Director Team

"People are hollering back and forth or having to walk between equipment..." — Brian Gunn, Producer Team

What tools, media or methods do customers currently use to share notes or communicate with teammates?

Email is nearly universal. Many teams also rely on Teams, Slack, Trello, or Smartsheet—none of which are integrated into Simpson tools. This causes communication loss and extra work.

"They have to leave Pipeline to go to an email, to type out that email, screenshot everything, and send it." — Bill English, Pipeline Team

"They already use... Teams or some ability." — Jill Meems, Cornerstone Team

"We have automation in [Smartsheet] to send us an email... categorized for all the different apps we support." — Russ Anderson, Spec Tools

What kinds of information are customers typically trying to document or share?

Teams share project statuses, design handoffs, task ownership, production anomalies, and material preferences. Many comments are tied to specific deliverables like PDFs, truss drawings, or BOMs.

"Sharing the design... sharing the estimate... and sharing the BOM report." — Latha Anand, OLS Team

"Engineer... will send it back with comments as to why it did not pass." — Daniel Jones, Director Team

"What kind of material is the countertop for the island?" — Matt Shacklett, Pipeline LBM Team

What motivates customers to leave a note, comment, or alert?

Most motivation comes from the need to coordinate across roles or shifts, clarify assumptions, or capture information for later. However, adoption is tied directly to ease of use.

"If we made it simple for them, they would come." — Daniel Jones, Director Team

"Some kind of notice between... shifts... like a little message board feature." — Brian Gunn, Producer Team

"Depends on how easy it is for the user to utilize whether that they'll find that beneficial or not." — Jill Meems, Cornerstone Team

What kinds of notes or communication would customers want to keep private vs shared with others?

While many teams didn't explicitly discuss this, the need for internal vs external visibility came up in several interviews, particularly in Takeoff and Pipeline.

"There would have to be a differentiation between what's a note... okay being on the plans for external people... versus internal communication." — Matt Shacklett, Pipeline LBM Team

"The user that gets assigned will not get the option to... check me out unless has the permission." — Cesar Suarez, Director

What pain points or communication breakdowns do customers experience in their current workflows?

The biggest pain point was lack of visibility and traceability. Projects become a "black box" after handoff. Tools don't support shared comments, notifications, or historical review.

"Everything is silent, so they don't know what's happening... That is the missing link." — Cesar Suarez, Director

"It just seems like a black box... I send a plan off and then it's a black box until someday it comes back to me." — Matt Shacklett, Pipeline LBM Team

What information, communication, or notes do customers need a historical record of?

Customers want to track decisions: why a design failed, when a task was done, or what a customer requested. Some teams already archive this manually (e.g., in Smartsheet or Outlook).

"You do have a project that was closed one year ago... and they need to review why those decisions were making." — Cesar Suarez, Director

"Some of these things have three hundred and forty four items... it's not like there's a ton, but it's not small either." — Russ Anderson, Spec Tools

When and why do customers need to go back and reference old notes or comments?

Primarily to explain decisions, validate handoffs, or follow up on customer questions. Production and estimating teams also use history to support QA and dispute resolution.

"That way, if somebody says like, hey. You guys didn't build this truss..." — T.J. Krol, Producer Team

What would customers want from an in-tool commenting or annotation feature?

Teams consistently referenced tools like Jira, Figma, and Bluebeam. They want click-to-comment, tagging, and notifications, ideally scoped to a specific job, drawing, or document.

"Like Jira, has a comment box on the page." — Daniel Jones, Director Team

"In Figma, you can tap somewhere on the screen and it'll add a comment right where you want it to be." — Brett Cipperly, Reporting Team

"If we allow the customers to tag a particular design element, that will also be valued." — Latha Anand, OLS Team

What concerns or drawbacks do customers anticipate with in-tool communication features?

Concerns include notification overload, complexity, and the risk of exposing internal messages to customers. Many requested digest options or user-controlled settings.

"Don't want to turn Director into a noise box." — Eric Borgerding, Director Team

"Without having some sort of visual or intentional cue... it can become difficult... 'oops, is that note gonna be out?'" — Matt Shacklett, Pipeline LBM Team

"It should be as noisy as someone wants it... others may want it quiet." — Brett Cipperly, Reporting Team

What do competitive tools (such as Procore, MiTek, Alpine, etc.) offer, and what do customers like/dislike about their approaches?

While Procore, MiTek, and Alpine were not always mentioned by name, customers referenced key features found in tools like:

  • Oregon Truss's Trespass (in-app async messaging)
  • MiTek (real-time saw alerts)
  • Jira/Figma (comment threads, tagging)
  • Trello (structured task logging)
  • Bluebeam (PDF markup)

"They made their own called Trespass. It had interuser chat... directly integrated into the system." — Eric Borgerding, Director Team

"MiTek... pop-up on the saw... real time... recut requested." — Chris Calabrese, Producer Team

These references point to a shared expectation: Simpson's tools need to support structured, embedded collaboration, without introducing unnecessary complexity.

Recommendation Details

Based on the full synthesis of 12 interviews across Simpson Strong-Tie teams, here are detailed recommendations to guide design and product development of communication, commenting, and notification features.

1. Introduce In-Tool Commenting Anchored to Context

What to build:

  • Commenting that's tied to specific documents, designs, or elements (e.g., elevations, PDFs, trusses, BOMs)
  • Support for tagging teammates with @mentions
  • Optional threaded conversations, similar to Jira or Figma

Design guidance:

  • Start with structured comments, not chat
  • Ensure comments are discoverable and visibly anchored to their target object
  • Include timestamp, author, and ability to resolve or delete threads

2. Enable Visibility Control (Internal vs External Communication)

What to build:

  • A simple toggle or tagging mechanism to mark notes as "internal-only" or "shareable with customers"
  • Warnings or visual cues before sharing externally

Design guidance:

  • Internal notes default to "private to org"
  • Show visibility labels clearly on each note
  • Admins should have visibility over all comments for governance

3. Build Flexible Notification Infrastructure

What to build:

  • Notifications for:
    • @mentions
    • Status changes
    • Shared documents
    • Alerts for system errors (future-proofed)
  • User controls for digest mode, mute, or urgency level

Design guidance:

  • Notifications should appear in-app and via email, with centralized preference settings
  • Consider future use of SendGrid or similar platform for delivery

4. Capture Historical Notes and Access Logs

What to build:

  • Comment history stored alongside the project
  • Optional versioning or activity feed for shared docs and reports

Design guidance:

  • Include filters to sort or search comment history by project, user, or date
  • Export logs as part of compliance-ready report formats

5. Design for Low-Tech Environments (e.g., Producer, Batching)

What to build:

  • Message boards or comment widgets visible on kiosk displays
  • Pre-programmed alerts (e.g., "Machine down", "Part recut needed")
  • Shift-change messaging

Design guidance:

  • Consider role-based messages or boards (Sawyer vs Table Worker)
  • Allow batching tools to trigger lightweight notifications, not full chat

6. Align With Mental Models from Familiar Tools

What to build:

  • Use patterns from tools like Jira, Figma, Confluence, and Bluebeam
  • Avoid real-time chat (Teams, Slack) unless clearly needed

Design guidance:

  • Lean into "document-centric collaboration" rather than inbox-style messaging
  • Create consistency across tools (e.g., commenting UX in Layout, Pipeline, and Reporting should feel familiar)
Additional Resources
Other documents and resources related to this research
Confluence Page
← Back to Research Repository