How we design and build Round

With the launch of Round Health 2.0 and of our new Apple Watch App I wanted to give people a little insight into just how we bring a new part of the product to life here at Circadian.

In the software world there is a focus on the continuous deployment a development scheme (think Google Chrome or Spotify updating itself in the background). This scheme lets engineers make fixes and add features as soon as they’re ready instead of waiting for a major point milestones.

At Circadian we have been able to take this same philosophy to the product design stage of our app as well, rapidly iterating on our core product at a rate that would have been impossible even a year ago. This is largely thanks to several fantastic tools we have in our arsenal: Sketch, ReactNative and CodePush.

The workflow below should give you some insight into just how this architecture can let you design apps more quickly, try out new features, and keep them bug-free(ish).

Paper and ink wireframes

Everything we build starts with simple little sketches in our notebooks (or random bits of paper). Starting at this level of resolution lets you map out the higher level features/flow without getting bogged down in the details.

Move wireframes into Sketch

Once we’ve mapped out how we might want a new feature to look or function we take the top options and drop them into Sketch. There still isn’t too much focus of the visual design but if certain components need it to be tested this is where it’ll happen. Round has a core color palette as well as a structured visual language. Making these standardized lets you move quickly with these first wireframes but still have good level of resolution.

This is one of preliminary wireframes we developed for walking through a person’s day using the app.

The Sketch Mirror tool is fantastic for getting a feel for general layout, positioning and information density. Seeing something on the device screen is far more informative than just looking at it as an art board on your monitor.

These wireframes are also great to show to other team members and outside users to start getting an idea for how people interact with the new part of the product and if there’s any point at which some affordance or layout doesn’t work.

Prototype the interactions in FramerJS

We use a fantastic new tool called FramerJS which is purposed made for prototyping UI interactions. Framer lets you import and stitch together the various components we’ve built in Sketch in such a way that we can get a feel for how it would function in the actual app.

Since it relies on similar code structure (coffeeScript vs JavaScript) to Round itself we can quickly test out animations and drop them straight into the app. These little prototypes can also be loaded up on a phone and tested in the office and out in the real world.

Other options for interaction/flow design and prototyping that we’ve used include Facebook’s Origami, Apple Keynote, and Google’s Pixate. Each have a set of tools and resolution that can come in handy for specific cases.

Build it into the app

One of the coolest parts about Round’s technology stack is that since it is using React Native we can build and style Round Health at the same time with the same code. Using CSS instead of complex UI construction tools, or sliced image assets means components are way more transferable and changes can be made in code by the designer instead of an engineer.

Converting Sketch files to code is as simple as CSS stylin, with things like Hot Reloading the changes show up instantaneously in the app without reloading.

At this point we’ll build out the new structural components of the feature and get the general flow, buttons and inputs set up. In parallel I’ll be hopping in between the app’s code and Sketch to start turning the roughed-out building blocks into what is in the art boards and UX prototypes.

Moving to the text editor and simulator itself for this stage of design work lets us test concepts faster and spend our resources on things that, when they’re done, are ready to ship immediately.

Test for a few days in the app

Another part of continuous deployment design is that with another one of our tools called CodePush we can release updates to our beta version of the app as soon as they’re commited. This means we can always be testing the newest version of the app internally; any changes made during a meeting or test are almost immediately reflected in the “staging” version of the app.

One of the story boards we developed to tie the various screens together and walk through all the possible states the user can get into. Definitely important getting the engineers involved in this since they’ll be able to identify the edge cases far more easily.

This is the part that for me feels the closest to magic and has dramatically sped up the rate at which we can test and refine the product. We’re no longer waiting on daily builds and having to make sure we’re using the latest version, instead, when you open the app you’re seeing the most up-to-date version of what we’re working on. Everyone at the company is part of the conversation and it lets us get far more perspective on if the feature we’re building is “working”.

Tweak overall flow/UX

With the team using the freshly built and styled feature we begin recording all bugs, UX, copy and general feedback to Github Issues. Issues is another great tool we’ve been using from the beginning of development that lets us keep everything, not just technical bugs, written down. We go through the list on a daily basis and prioritize based on schedule and resources.

Again, because of CodePush we can change/fix, release and check off an issue all in a few minutes. By shortening this cycle we dramatically increased the velocity at which we can prototype which, in turn, allows us to make a much more refined product.

Start pixel polishing

Once we’ve selected the most promising version of the feature we’ll start adding in details such as new design elements, colors, typography and icons. These are the features that bump up the resolution of the product to the point where we now have a blueprint for what we want to start coding.

Wider beta testing

Once we’ve got a stable, semi-complete version of the new feature built out we’ll issue a release to our faithful group of beta testers. These folks have opted in to constantly being asked questions, dealing with weird bugs, and generally being guinea pigs for our product. The final shipping updates would never be as stable, bug free and warmly received if it wasn’t for these folks.

Analytics start coming in handy at this point in time. It’s important to know what you want to measure quantitatively and how before you test so you actually are tracking it. If you do this right you can very quickly start seeing points of friction or confusion you’d otherwise completely miss with just user interviews.

Little tweaks

With continuous deployment these tweaks can happen all the time and even after deployment. If we’ve done our job these changes aren’t big and are instead focused on making optimizations to icons, copy and flow to improve things based on feedback from the above user testing.

This is another great feature of React Native’s ease of use. While the engineers are working on finalizing the release from a technical perspective the design changes can be happening at the same time. This again speeds up the development cycle and allows the shipping product to have gone through more interative cycles.

Same screen, lots of background and layout options, all with the same code and just different styling.

Public release

After running through another internal release of the product the app is bundled and submitted to the App Store. At this point in time we also issue an external beta release, the issues that come up after this point will either be rolled into the next release.

When the build is approved we release it to the public and carefully monitor the logs and analytics tools to ensure that whatever feature we shipped is both performing how it should, and that there is user uptake of the new feature.

CodePush fixes

As we get the majority of users onto the next version of the app and our issues list fills up we start testing the bugfix release that we will remotely push to the app via CodePush. We can get a bug report from a user, fix it, test it locally and then push it to our tens of thousands of users in hours instead of days.

Do it again. And again... and again.

And eventually you’ll get to a product people use and like! Nothing ever ships perfect, but with this toolset we’ve been able to reduce the time it takes to both fix and improve things.

We’re really excited to be using some of the newer tools on the web to bring a better experience to a problem that has been around for a century. If you have any questions about any of the steps or just want to chat you can always reach us at @roundhealthco or my at @mwcrowley.