Assemble + iSqFt (2015-16)
The Assemble + iSqFt integration project marries two complementary services. Assemble provides access to Building Information Model (BIM) data (that answers questions like how many square feet of carpet do we have to install). iSqFt helps general contractors (GCs) describe jobs and solicit bids from subcontractors (subs). Assemble and iSqFt are always looking to reduce risk for GCs and subs. Providing BIM data to subs during the bidding process would speed up bids and make them more accurate, so both companies had a natural interest in an integration of Assemble data into iSqFt's bidding platform.
I was tasked with defining and designing this integration, to be delivered in 9 months from the start of the project.
“We simplified the initial product during the early stages, focusing on the value proposition, and delivered it 4 months ahead of schedule.”
The following describes some of the major deliverables and decisions I made along the way. For this project I did some product management in defining the problem space and guiding the team during implementation, the UX and visual design, helped code some of the UI, and defined the general approach of how developers should integrate our data in their products.
Defining the Project
Personas
We already had a few personas defined that we use for all our projects, so this part was easy—we just had to create the Sandra character. The following are high-level descriptions of the personas we were focused on with this project:
Dave
Dave is a preconstruction manager at the GC. He manages bids and the information provided to the sub during the bidding process. Dave is familiar with Assemble.
Roger
Roger is a sub, consuming information for use when bidding on a project in iSqFt. He is familiar with iSqFt, but not Assemble or 3D models and related information.
Sandra
Sandra is a developer at iSqFt who will write their side of the integration. She knows JavaScript and the components used by iSqFt, but doesn't necessarily know much about Assemble or the libraries we use. This is one of those often-overlooked personas that might make or break the feature; if a developer can't easily integrate with your product, you have no integration.
Guiding Story
Dave's company, Jackson Builders, is taking on a building project for which they need floors coverings installed. A few subcontractors will be invited to bid on the work. Dave gathers documents to share with bidding subs. He creates a view in Assemble that isolates the floors and related parts, and then He turns on sharing for that view. Dave adds the project documents and the Assemble view to his project in iSqFt, and then he invites the subs, including Roger.
Roger goes into the iSqFt project Dave invited him to, reads through the docs, and can better understand the context and scope of work using the Assemble view of the 3D and related building material data. He notices that there is limited mobility in the space in a few rooms where his installers will work. He adjusts his labor costs accordingly, and both parties avoid unexpected changes later in the project.
User Goals
Dave can provide 3D and inventory data to Roger to communicate a more accurate representation of the job.
Roger can better understand the complexity and size of the job so he can provide estimates quickly and more accurately.
Sandra can add the Assemble integration to her company's product with minimal development time.
Exploring Early Ideas via Wireframes
I began working on the Assemble and iSqFt side experiences by wireframing in Balsamiq. The focus of this stage was to start getting feedback about our initial ideas and assumptions from internal folks and target customers.
Wireframes: Dave Shares a View in Assemble
One of the early assumptions was that we would need to expand our view permissions in Assemble so we could offer outside access to Roger. I built some wireframes that started there, exploring a few levels of security that I thought would make sense and cover the basic ask:
The feedback I got was that it seemed more complex of an interaction than necessary, and development and I could tell how much work it would be to support this level of security. Delivering this project late was not an option, so I worked with the product manager to simplify the initial offering, more tightly focused on the user goals. The only real concern of our customers security-wise was that they wanted data to be explicitly allowed to be used outside of Assemble. I simplified it to this:
This made sense to people and required way less work by our development team. Most importantly though, it completely supported the user goals and value proposition.
Wireframes: Dave Adds a View to iSqFt
Dave had to be able to add the view to his iSqFt project. This it turns out it is a pretty straightforward design problem. The design below stayed reasonably consistent throughout the process (other than a few minor changes I won't bore you with here). We provided a way for Dave to sign into Assemble, find the project he wanted to share views from, and then select views to share in iSqFt.
Wireframes: Roger Loads a View in iSqFt
iSqFt already had a document viewing experience, so we just had to fit our views into that experience. Basically the list of views is on the left in iSqFt, and the Assemble integration loads the view in the document viewer.
A concern of mine, still to this day, is that because Roger is not necessarily familiar with Assemble, he may not know how to navigate a 3D model and he might miss important areas of concern or complexity in the Assemble view. I explored a feature that would allow Dave to create saved viewpoints or perspectives in the 3D viewer and mark them up to help guide Roger through the model to complex spots.
This is one of those features we decided against for the sake of expediency. It was not absolutely necessary to achieve the goals of the project, but it is something we want to follow up on in the field: Does Roger catch what Dave is hoping he catches in the 3D view? Is Roger able to navigate a 3D environment effectively? Do we need a quick intro to navigating in the viewer?
Prototyping to Refine and Handoff
Once I got buy-in I moved to Sketch to refine the look and feel and then Invision to communicate and solidify the approach. I've provided some mockup examples below, but you're also welcome to walk through the prototypes in Invision.
Dave Shares Views in Assemble (Invision)
Dave Adds Views to iSqFt (Invision)
Roger Loads a View in iSqFt (Invision)
Kicking Off Implementation
Once we refined the prototype and UI elements, I guided our team through breaking down the project into tasks. I usually group all tasks into the user activity (using the persona) that task supports. So for example, Dave shares a view in Assemble would have implementation tasks like, Add a Share button to a view that opens the shared view modal, Toggle on sharing in the share modal, and Display guidance for Dave to add views to iSqFt.
Once we have those tasks, we can prioritize them, making sure that if the activity, e.g. Dave shares a view, is fully supported before we decide we can cut an item for v1. In this case, if push came to shove, we could rely on our sales team for the initial limited engagement for teaching Dave how to add his shared views to iSqFt and could deprioritize the guidance screen.
In absence of an available UI developer on this project, I helped with design implementation. To keep some separation so I didn't get bogged down into code, I created Code Pens of the design that the dev team could drop into the product. I usually design review each piece of UI and refine it with the developer before it goes to QA. Code Pens help narrow the gap between design and implementation, and in so doing cut down on endless iterations and design reviews. When I rely on static mockups, I have to go through endless iterations with a developer, and at each step having to markup the work like this:
Improving the Integration Experience
This was Assemble's first real marketed integration, and iSqFt's development team was embedding our product in theirs. We wanted their work to be as little and as easy as possible so it would cut down on implementation time and be easier for us to iterate over time. I came up with the implementation approach of asking them to include a single JavaScript file in their page, hosted by us (so we're in control of versioning for bugs and other changes), and then call just a couple of commands to get the information they need to embed our product.
Simply add the script to your page like this:
<script async src="http://site.assemble.com/api/js/share-view.js"></script>
And open the share dialog like this:
assemble.shareViews(callback)
As a result, we create and add a modal with an iframe inside, and then we take care of the rest: to authenticate, display projects and views for Dave to choose from, and finally sending the chosen views and tokens to load those views back to the calling code. Knowing how people like to interact with js in different ways, the developer can either use a promise to handle the results of view choosing, or they can send in a callback that we'll call with the results. The less you require integrating developers to learn, the more smoothly an integration will go.
The rest of the integration work to have Roger open a view is similar and just as simple. They just have to tell us where to put it in the page, and send us the information for the view they'd like to show.
Results
We slimmed down the requirements so we were testing the specific value we were trying to test with this integration idea, and we got it into the market months earlier than planned. We have sold a few of these integrations, and are currently testing with a few more customers. We subsequently integrated with another product, Procore, in this way, which is getting even more attention, and we're working on yet another similar integration with Oracle P6 (for project scheduling).
