Design

Intro to Integrations

May 24, 2015

Several weeks into building Cushion, I started thinking about integrations. Obviously, I was ahead of myself, but I knew integrations would play a vital role in the success of Cushion. Having been a freelancer for a few years at that point, I was aware of the “usual suspects” of freelancing services, and I knew that most freelancers were tethered to these services after years of use. I also knew that many of these freelancers weren’t head-over-heels for them, but the services were so engrained in their day-to-day that convincing these freelancers to jump ship entirely would be an exhausting, uphill battle. Fortunately, this was never the plan.

From the beginning, I wanted Cushion to be more than another equal alternative, feature-matching against every other service. I’ve always seen it as a valuable addition. Instead of trying to make Cushion into an all-in-one Swiss army knife, I could let other services focus on what they do best while Cushion provides a new angle on the same data. Rather than interrupting a freelancer’s workflow, Cushion could be an extension of it—a sidekick to the other services.

A few months went by and I became impatient. I kept thinking about how I’d need to build integrations eventually, so why not get a head-start? “Too soon”—the words of a wise developer in my studio space. He was right, but I was too impatient. To give you an idea of how laughably early this was in development, users couldn’t even change their password yet. I was blind to what Cushion needed at that moment and too focused on what Cushion could do without for now—this is why project managers exist. I spent a few days on integrations before thinking to myself, “Too soon.”

Several more months passed and I got the itch again. This time, instead of trying to build an entirely custom system for integrations, I decided to take a half-step by integrating with Zapier, a service for communicating between APIs. Since Zapier would be doing most of the heavy lifting, I could achieve the functionality I was after by writing a few workflows, like “create an invoice in Cushion when an invoice is created in [another service]”.

At first, this seemed like a step in the right direction, but as I spent more time with Zapier, I knew it wasn’t right for Cushion—I recognized the burden I would be placing on the users. In order for them to integrate Cushion with their existing services, they would need to first create an account in Zapier. Then, they would need to navigate through Zapier, learn how Zapier works, and complete several steps to set up the integration. I would need to write thorough documentation and answer support emails for using Zapier. This wasn’t ideal for anyone.

Simplicity is one of Cushion’s guiding principles, and sending users through hoops on another service is anything but simple. That route is simple for me, the developer, but not for the user. There’s a reason people pay for services—they want to lighten their workload. If this weren’t the case, we’d all be satisfied using spreadsheets. Instead of sending users somewhere else for integrations, I should assume the burden and build a system where the burden is non-existent to the user. Enabling an integration should be as easy as a single click.

I scrapped all the work with Zapier and took a break from integrations for another month. When I returned, I knew exactly how to approach them. Under the hood, I would break the system into four specific parts—services, recipes, authorizations, and integrations.

After establishing the internal structure of integrations, I started to design the exterior. I began mapping out the pages I would need:

It didn’t take long for me to realize that I was thinking too much like a developer. Just because I have four models for integrations doesn’t mean each model needs its own index and instance page. I took a step back and started thinking in terms of what I would expect. For integrations, I should be able to view:

Next, I considered how to structure these lists. I definitely don’t think each one needs its own page, so I thought about how I could combine them. Since integrations are first and foremost about the services, I could use the services to organize everything into two pages—an index page for services and an individual service page. These pages would include more than just the services, but I’d use the services as a top-level category.

intro-to-integrations-services

When arriving at the main integrations page, I should see a list of services to authorize. If I haven’t authorized a service, its button should say “authorize” and clicking it should take me through the authorization flow for that service. If I have already authorized a service, it should say “view” and clicking it should take me to that service’s page.

intro-to-integrations-service

After authorizing a service, I should be redirected to its page, which should include my existing authorizations, integrations, and available recipes for this service. On this page, I should be able to enable/disable integrations and de-authorize the service.

intro-to-integrations-integrations

Then, after enabling an integration, the main integrations page should include all of my existing integrations across all services as well as the still-available services.

This layout feels right to me and I couldn’t be happier with how it turned out. Let it be known that I went through a dozen layouts before arriving on this one, so it wasn’t as clear cut as it appears. While figuring out the layout, I also narrowed in on an overall design that matches the rest of Cushion.

integrations-subscriptions

Thinking about how to display the grid of services, I decided to revisit the subscription page design. With services only needing a single action button for authorizing, I found that the block design I used for subscription plans would work perfectly.

intro-to-integrations-service-blocks

I swapped out the plan prices with the service icons and replaced the plan names with the service names. Below each name, I included a two-word description for each service to balance everything out. If a particular service is ever down or having issues, I could re-use the ribbon alert to indicate activity if I need to.

intro-to-integrations-secondary-service-block

I also designed how services will look as I build more integrations for Cushion. For less-common services, I condensed the block, so that two services can fit aside each other in a single row.

intro-to-integrations-secondary-services

I’m not a fan of integrations pages that are treated like a dumping ground, with the most useful integrations buried beneath obscure services used only by one user. I’d like to establish a better hierarchy, so the primary integrations will sit at the top as square blocks. The less-common services will then rest below them in rows of two. This way, all of the integrations are available for browsing, but the more frequently-used ones will be more prominent.


I couldn’t be more excited about integrations in Cushion. I feel like every integration brings Cushion one step closer to being a household name in the freelance world. By automating the data input process with auto-import integrations, users will be able to visualize their schedule and budget with a single click. I have trouble sitting still in my seat just thinking about this!

Expect to see more posts about integrations in the near future. This one originally included the authorization process and the differences between integrating with FreshBooks versus Harvest, but as you can imagine, it was a bit long-winded. Until next time.

Share this on Twitter or Facebook

Archive

  1. Funding Cushion
    Story
  2. Hiring a Team of Freelancers
    Story
  3. Taking a Real Break From Work
    Story
  4. Slack as a Notification Center
    Dev
  5. Document Your Features
    Story
  6. 300
    Story
  7. Vacations
    Design
  8. Offering Discounts
    Design
  9. Waves of Traffic
    Story
  10. Less Blogging, More Journaling
    Story
  11. Retention Through Useful Features
    Design
  12. The Onboarding Checklist
    Design
  13. Spreading the Word
    Story
  14. From Beta to Launch - The Subdomain
    Dev
  15. From Beta to Launch - Sign up
    Design
  16. From Beta to Launch - Messaging
    Design
  17. Launch
    Story
  18. Authenticating with 3rd Party Services
    Dev
  19. Intro to Integrations
    Design
  20. Inspiration vs Imitation
    Story
  21. The Emotional Rollercoaster
    Story
  22. Designing Project Blocks
    Design
  23. Everything in Increments
    Story
  24. Deleting Your Account
    Design
  25. Designing the Subscription Page
    Design
  26. Rewriting the Timeline
    Dev
  27. Restructuring the Individual Project Page
    Design
  28. Project Blocks
    Story
  29. Redesigning the Homepage
    Design
  30. Multiple Timelines
    Design
  31. Archiving and Estimate Differences
    Design
  32. Multiple Financial Goals
    Design
  33. Zooming in on the Timeline
    Design
  34. Currency
    Dev
  35. Preferences, Accounts, and a Typeface Change
    Design
  36. Sending Out the First Email
    Story
  37. Currency Inputs, Notifications, and Invoice Nets
    Design
  38. Dots and Lines
    Design
  39. Calculating in the Database and Revealing Tendencies
    Dev
  40. Improved Form UX
    Design
  41. Cushion is Online
    Story
  42. Schedule Timeline Patterns
    Design
  43. A Slimmer Schedule Timeline
    Design
  44. The Schedule Timeline
    Design
  45. Plugging in Real Data for the First Time
    Design
  46. Transitions and Project Lists
    Design
  47. Death to Modals
    Design
  48. The Individual Project Page
    Design
  49. Estimated Incomes and Talks with Other Freelancers
    Story
  50. Statuses to Lists and the Paid Beta
    Story
  51. The Timeline
    Story
  52. Invoice Terminology
    Dev
  53. Modal Forms
    Dev
  54. Wiring the Backend to the Frontend
    Dev
  55. Balancing Design and Dev
    Story
  56. Timecop, Monocle, and Vagrant
    Dev
  57. Going with Ruby and Sinatra
    Dev
  58. Ditching local-first and trying out Node.js
    Dev
  59. Switching to AngularJS
    Dev
  60. Building the Table with Vue.js
    Dev
  61. Clients, Projects, and Invoices
    Dev
  62. Introduction
    Story

Ask a Freelancer

A podcast series where experienced freelancers answer questions about freelancing.

Listen to the Podcast

Talking Shop

An interview series where we talk to freelancers about important topics in the freelance world.

Read the Interviews

Running Costs

Take a close look at the costs that go into running a web app and why we use specific services.

View the Costs

How It’s Made

Follow along with the journal for insight into the overall experience of building an app.

Read the Journal