Design teardown: Resource Guru

Startups only have so long—and so much funding—to gain traction, so early design decisions make all the difference. Here’s what we learned from building the minimum viable product (MVP) version of Resource Guru, a fast, simple way to schedule people, equipment, and other resources online.

Only a few baby turtles make it past the breakers

As a brand-new startup, we’d already prototyped our ideal product, but limited funds meant we’d have to cut features for the initial launch. Deciding what stays and what goes can be a painful process—but it’s one that you can use to your advantage, if you do it right.

For V1, we’d have to focus on solving the problems of enough people that we could stay afloat. From there, we could get feedback and iterate. As Jennifer Aldrich points out in “App release planning: don’t build a wall, build a cottage,” for V1, you should:

Release a very small, beautifully executed app, with limited key features. Make it a functional, useful starting point.

As we built Resource Guru, we found that early face-to-face contact and user testing with a clickable wireframe and Silverback helped us understand the essential requirements. The feedback we got helped us make more informed decisions on UX and features—and reassured us that people actually needed our product.

Early face-to-face contact and user testing with a clickable wireframe and Silverback helped us understand the essential requirements.

The problem: scheduling is broken

Anyone who’s worked in a creative services agency has put in more than their fair share of evening and weekend hours. And while pulling your team together to create something amazing can be exciting, morale plummets when late nights and weekend work become the norm.

Poor resource scheduling is the usual culprit. If everyone’s time were scheduled efficiently, they wouldn’t need to work outside normal business hours.

Some companies use tools like Basecamp, Trello, and Podio to manage their tasks, but none of these tools let you schedule people’s time. At some point, you need to know when people are available and when the work is actually going to get done.

What’s wrong with calendar apps?
Apart from poor visibility, normal calendar apps force you to book specific times, e.g., 9 a.m.–1 p.m. That’s because they were built to let people schedule meetings—not heads-down time.

Sometimes, you just want to book someone for 4 hours and let them decide when that work gets done. It was very important for us that people could make both non-specific duration bookings (e.g., 4 hours) and time-specific bookings for meetings.

Solutions: tackle the real-world complexities head-on

We knew this going in, but testing confirmed it again and again: scheduling is complex. If a tool doesn’t account for that complexity, it becomes ineffective. Here are some of the real-world problems we ran into, and the features we built to solve them.

Don’t mess with convention
When we launched, the “New Booking” form above looked like this:

We made 2 UX improvements that made a big difference. The first was minor—to include “Client” in the “Project” drop-down so projects became nested elements within clients. Just makes sense, right? The second change proved much more powerful. And it’s a perfect example of how, when you design in your own bubble, you can get it wrong. Not to mention the power of copy in user experience design.

When you add an event to a typical calendar app, you make the booking from Time A on Date X to Time B on Date Y. But with Resource Guru, you make a booking from Time A to Time B or a booking of C hours D minutes on every working day from Date X to Date Y.

The 2 methods sound similar but are conceptually very different. You can see a “Repeat until” link in the image above. That’s because any multi-day booking in Resource Guru is effectively a booking that repeats daily. But calendar apps have taught users to expect a start and end date and to understand repeat bookings differently. The difference made our customers think and in many cases caused confusion. A simple change to “From” and “To” has reduced friction considerably.

Don’t avoid the difficult bits—they stick around
Businesses rely on reporting data for billing and to make some very important decisions. Because people can join a company at any time and their availability can change at a moment’s notice, we decided that historical availability tracking would be key for reports. This way, when you report on a period of time, utilization will remain accurate, no matter when people started at your company. It would have been much easier to ignore this, but we’ve found that tackling these difficult, real-world problems head-on has helped to differentiate us from our competitors.

Listen to the squeaky wheels
When we launched in 2012, you couldn’t move bookings by dragging them. But our customers spoke up—loud and clear. We had no choice but to completely re-engineer the calendar to make this a reality. This simple usability improvement has led to one of the biggest lifts in metrics we’ve seen to date.

Of course, adversity often presents us with opportunities—and this one helped us develop our API with bookings integrated from the get-go.

Think about integrations early
Giving users the ability to easily integrate your app with other software can put your business on a totally different trajectory, so why stop at an API?

Last year, Podio proposed an integration designed to let their customers schedule more effectively. We were delighted at the opportunity, but it meant building webhook functionality—no trivial task. Webhooks let an app send real-time updates to other apps (rather than having other apps continuously check the API for updates).

So we had to choose between building webhooks or other priority features. In the end, we decided that this investment would not only open up immediate new functionality—see our DIY integrations with Slack and email—but also pave the way for all future integrations. The proper Slack integration we’re working on now has been much easier because of the foundations we laid with webhooks.

Fear feature bloat
Once you launch, you’ll get hit with the temptation to add every feature people request. This can be a real mistake and can quickly lead to feature bloat. Let a feature request start shouting at you before you consider including it. The more you can declutter your interface for everybody, and please power users with progressive disclosure, the better.

How InVision fits into our design process

We’re working on a big new feature around vacation planning and absence management and InVision has become an indispensable tool for developing new features like this. We use it for 3 distinct purposes:

1. Design collaboration
Designers upload initial designs to get stakeholder feedback. Comments, notifications, and versioning make it really easy to arrive at finished designs.

2. Spec documentation
Once we’ve finalized designs, we duplicate the project and add comments around specification, e.g., “This logo needs to link to the homepage.”

3. Functional collaboration
Engineers inevitably discover the corner cases you missed once they start programming. This leads to a third round of comments, often resulting in a few final design tweaks.

Ideas are easy—executing them is difficult

The time we spent researching and iterating on features was time very well spent. When you iterate on a feature, it should either have the effect of increasing clarity thereby improving your conversion metrics or making your app more sticky thereby reducing churn—preferably both. So talk to your customers and don’t avoid the difficult problems and you’ll have every chance of getting your startup off the ground.