×

Drop me a line.

Email: colinazeltine@gmail.com

I’m currently open to full-time product, ux, and ui roles in the the following regions:

• San Francisco Bay Area
• Milan, Rome, Florence
•Paris, Lyon, Marseille, Nice
•Berlin, Amsterdam, Rotterdam

Blueprint — A Web Application Framework

Product + UI + Front End

Blueprint (BLUE) is an in-house built, complete design and engineering framework for building a set of proprietary single page web applications.

Blueprint Hero Image

Role

As the principle designer within a cross-functional team I conducted user research, designed the user experience & interface, and developed the modular front end components.

Project Goals

To replace Simpson Strong-Tie's outdated native & web applications.

A sampling of various SST applications.

Problems with Existing Applications

The desktop-only interface was dated and in need of a refresh, unintuitive to use, & difficult for their engineers to build.

Poor User Experience

Infrequent updates caused an accrual of design & tech debt which resulted in a poor user experience for both engineers and end users.

Legacy application user flow

Wasted Space

Extraneous components such as the site’s header pushed the top of the applications down 300 pixels and a massive footer provided little value to the users, while lending to content overflow challenges.

Squandered prime screen real estate

Not Built for Mobile Responsive Web

The legacy applications received their last major update in 2014 when mobile adoption was at it's infancy among Simpson Strong-Tie's users. From 2014 to 2019 they saw an increase of 32% in mobile usage.

The Calculate Button Chokepoint

The “Calculate" button had become a user chokepoint by gating outputs if any required inputs were absent. Errors also occurred due to out-of-range or invalid inputs.

The bane of all existence

The Input and Output Relationship

The input and output sections both typically overflowed below the fold, which proved problematic for clients using an iterative approach, as they would often lose their place.

Legacy application input section

Legacy application output section

Pre-Research: Low Fidelity Wireframe Sketches

Initial layout hypotheses explored user flows and interactions within the application before my team was given bandwith for research, due to the lack of engineering resources. Whiteboard sessions attempted to tackle issues such as the input/output relationship and proper abstraction of input sections for mobile.

Initial whiteboard session of application interface

Whiteboard mockup of global messaging

Whiteboard mockup of pagination detail

Whiteboard detailed mockup of table of contents

Initial Concepts

  • A table of contents to tackle the massive amount of inputs found in most apps
  • Global & local messaging and feedback to house suggestions, updates, warnings, or errors.
  • Pagination to focus the user on a small set of form inputs, which could be well represented on a mobile device.

User Research

Qualitative research was conducted through one-hour user sessions of 6 super-users & subject matter experts.

User research interview notes

Research Findings & User Goals

  • Homeowners desired structural stability within their budget, leading to an iterative 'back & forth' workflow
  • Builder/Contractor sought the cheapest code compliant building solution, and utilized an iterative workflow
  • Product specifiers sought structural stability & had the most comfort within the apps, leading to a linear workflow.
  • Structural Engineers behavior and motivations encompassed any combination of the previous three

User Journeys

Two separate methodologies emerged for how the four user groups utilized the applications.

A Linear Workflow for users who filled out all required inputs to the best of their knowledge and then received the results... or no results.

An iterative workflow in which users would fill in the required inputs, receive their results, then edit the inputs to achieve the desired outputs through trial and error.

  • Structural Engineer - Either/Both Workflows
  • Specifier - Linear Workflow
  • Builder/Contractor - Iterative Workflow
  • Homeowner - Iterative Workflow
User Journey

Research Findings

Compressed Icon

Condensed layout preferred

i/o-icon

Ubiquitous input/output desired

Keyboard Icon

More keyboard accessability, less mouse

Desktop Computer Icon

75% used desktop computer

print-icon

PDF printing desired

User Icon

Personalization desired

UI/UX Implementation

The Workspace

The Blueprint workspace was crafted with a 100% width to feel more like a native application, and the main site’s header and footer were removed as metrics indicated users were unlikely to utilize them once an app session began.

Desktop Layout

User research supported viewing input and output sections concurrently, so they were laid side-by-side for desktop viewports with independent scrolling on the y-axis with a horizontal “resizer” button for further workspace cutomization.

Tablet Layout

For tablets in portrait orientation, input & output sections stack vertically. Tablets in landscape default to desktop orientation.

Mobile Layout

Mobile devices are limited to one section at a time. Users can switch between sections by toggling an “I/O” (input/output) button on the lower right of screen, as right-handed individuals make up nearly 70% of the population.

Blueprint mobile interface

Navigation

Desktop

The header is fixed, minimized to 50px, contains application actions, application branding and global branding.

Mobile and Tablet

Mobile and tablet navigation is contained within a hamburger menu, and lacks the upload and download features due to an iOS technical inability as of when the framework was developed, which made up 70% of our user base.

The Reset Button

According to legacy app metrics, the reset button (to return the form inputs to their default values) was the second most commonly utilized button after the calculate button. As such, the desktop UI maintains a reset button in the navigation and the mobile UI features a reset floating action button placed above the input/output button.

The Happy Path

In order to facilitate quick results output, it was necessary to preset the application with a happy path that would be guaranteed to deliver a valid result. I used this opportunity to preload the inputs with what our structural engineers determined was the most common scenario asked by our customers to ensure an easy starting point for the users.

Themes, Modes, and Customization

Themes

Applications utilize five branded colorways to indicate which product line they support and a sixth non-branded colorway for additional flexibility.

Connectors
Pumpkinhead Orange

Lateral Systems
Deep Purple

Fasteners
Dull Blue

Anchor Systems
Poolside Green

General
Rust Orange

Default
True Gray

Light mode app header variations

Modes

Light and dark mode are natively supported for both desktop and mobile OSs.

Dark mode app header variations

Customization

Light or dark mode can be customized to override the current system settings.

Users are able to configure the app to their prefered orientation for the input and output panes in desktop viewports.

Users can customize local font size to small or large, with medium being the default. Font size customization is removed on mobile due to mobile OS user preference overrides.

Customization settings are stored in local storage for future browsing sessions.

SCSS Methodology

The UI was built with SCSS utilizing a top-down architecture of modifier classes applied to the <html> tag to allow theming, modes, and customizations.

An altered version of BEM (Block Element Modifier) methodology was employed for consistency without the overly long and repeated class names, e.g., .dropown__label .-focused.

SCSS files were scoped to the individual React components to decrease page weight.

Dark mode app header variations

Style Guide

The Blueprint framework’s styles, icons, and React components are presented within an internal-facing style guide built on the React Styleguidist library utilizing markdown files. The style guide displays the props and api for each component as well as a live playground for app engineers.

Additional functionality was built to enable engineers to change the mode and theme of the style guide.

SST Blueprint style guide

Conclusion

This project concluded with the launch of Blueprint's first beta application, Post-to-Foundation Designer (PFD) in Q1, 2020.

For more visual examples of Blueprint's interface, or to view a portion of the responsive icon set I built for Blueprint, please hop over to my Dribble profile.

Thanks for reading!

< Back