Case Study: Weld

More Images

Weld is a proactive computing project. I am again working on a product category that I find exciting. We focused on a single (successful) vertical from our previous product, email. Email as a platform gets put into the public utility category, but it is rich with data that can make or break your day.

In college I worked on the Mozilla Calendar Project. That makes me feel right at home trying to solve for calendar UI designs. That project is where I found out I wanted to work on the design side of software.

Scheduling is still hard

A very high percentage of users complained (in an informal study) that getting a meeting on their calendar takes too long. People inherently come to productivity tools with a bias, the problem is unique for every user and their habits. The first thing I wanted to tackle was how to be platform agnostic. I want users to continue to use calendar and email effectively without the pain points.

We white boarded, chatted, and sketched feverishly for a week to validate assumptions that this was the first problem to tackle. It was messy, contentious, and pretty fun. We eventually realized we were coming back to a really early sketch (fig. 1) to “proof” our newest ideas.

(fig. 1)

My earliest sketches always come back to a UI flow shorthand (ht Ryan Singer).

After this initial phase of ideation, I iterated for weeks on wireframes, flows, layouts, and UI designs. The engineering team set about building the backend to handle the product shift. We jettisoned lots of code for the other “triggers” we had built for Osito. Here are some of the UI iterations for a date/time picker. Calendar inline with email just feels right, although some of these are hastily sketched ideas.

(fig. 2)

UI designs were tricky. A colorful saying is "trying to fit 10lb of s!$@ into a 5lb bag". It was eventually wrangled into a manageable state through contextual computing.

Who knows enough Objective-C? - I do!

We built lots of prototypes in framer (before it was an app) and in iOS. This is actually where I picked up programming for iOS. We struggled to find a great iOS engineer to join the team. In the interim, I decided to learn as much as I could about UIKit. I was able to turn these prototypes into shippable code.

(fig. 3)

I built something with Xcode and it now lives in the app store. It is messy, but it works and it was so much fun to create.

Sidenote: That GIF was made with a fun little python script I built. It is dumb, but it does what I want...

We eventually shipped a scheduling app that also turned your email into a more chat-like interface. It is streamlined and fun, if not a wee-bit buggy. I’m not an engineer, I’m primarily a guy who is passionate about making software. I hope to be building more of my designs, but I am definitely more designer than engineer.


Product Design on a small team is not about camping out in Photoshop, Sketch, or some other design tool. It is about juggling 5 tools that are on fire and when you drop them everyone’s life is a little better. I think there are 10-12 pretty well hashed out designs and 3x that many concepts in the trash. But the final design always shines a bit brighter from each iteration. Finding the balance between iteration and shipping has been the toughest part of working on product at a small startup.

The app has been replaced with a newer stripped down version. The new direction isn’t a traditional app - it is an interactive agent that can be hooked into anything that is text-based communication. The new iOS app is effectively just fetching the endpoints from our web / email app.

The changes are certainly worthy of a fresh case study :).

Design Details

(fig. 4)

Calendar picker (v0.3), (v0.7), and (v0.9).

One of the only truly custom UI components was a draggable calendar picker. It had many iterations, I've included 1.5 of them here. This was one of the items that got prototyped the most. Nailing the feel of picking a time naturally on a mobile screen was surprisingly complex. After designing the "dragger" a popular calendar app shipped a very similar component.

(fig. 5)

Proposal Received flow (v1.0).

We really try to shorten the distance between a scheduling request and adding an ICS to your calendar. This is the "optimal" flow. A suggestion comes in, you add it to your calendar, and Weld sends an ICS invite on to the other party. We keep you informed of the status of that proposal via push notification.

(fig. 6)

Early welcomeflow (v0.7).

I'd eventually code and ship this - my first real foray into iOS engineering. These screens show the same headline, but the animation between hand states was advanced with a swipe. I should really make a gif of this...

(fig. 7)

Scheduling flow for multiple users (v0.5).

Our research showed that meetings for greater that 4 people are not normally scheduled over email. Weld optimizes for the most common scenarios (2-4 people).

(fig. 8)

App store screenshots (v0.9).

A finished app ;).


I designed and built the responsive website for this app as well (jekyll, sass, js, and <video>) and executed all of the marketing materials (emails, press kit, etc.). It is live for a short while longer (maybe until Aug. 2015) - I’ll try to archive it somewhere. Once the link is gone these images will serve as proof of its existence.

(fig. 9)

The site features some autoplaying video tags and some fonts from I'm in love with Whitney.

(fig. 10)

These layouts were driven by trying to optimize viewing on desktop and on mobile with the same assets. Videos are big and we didn't have the time or resources to build an adaptive site, so we opted for full responsive.

(fig. 11)

Responsive layouts of the two above pages, respectively. During development of the site the iPhone 6 and 6+ were released. I moved the main nav to the bottom of the responsive pages in an effort to make it more hittable on the larger form factor.