Everything in one place, everyone on the same page

Product Roadmapping Software for Creatives
2016, omelo.com
🎩 Founder / Product Designer
🕗 2yrs
🤝 1 designer, 2 developers

Overview

Omelo elegantly compiles communication (emails, texts, chat) into a sensible, one page, beautiful timeline.

By displaying a streamlined view of current project status, upcoming milestones, and project history at a glance, clients and contractors can stay on the same page.

TLDR: The design was a hypothesis around the feasibility of a vertical timeline for project management. Something ....

The One Page Wonder

Omelo started when I failed to keep a project clear to a client. To remedy this, I decided to send a monthly status update to my client, in a well designed single page PDF document (See image).

The results were crazy. My client loved it. She sent it to other coworkers and it quickly spread throughout the office. I decided to push this communication further and started exporting project summaries each month via email.

Omelo

Everything in one place, everyone on the same page

16 Month Project   ●   Product Design + Product Owner
Overview

The One Page Wonder

Omelo elegantly compiles communication (emails, texts, chat) into a sensible, one page, beautiful timeline.

By displaying a streamlined view of the current project status, upcoming milestones, and project history at a glance, clients and contractors can stay on the same page.

TLDR: just read it 😜

Color and icon signifiers to help user orientation

Omelo was born after failing to keep a project clear to a client. To remedy this ambiguity, I decided to send a monthly status update, in a well designed single-page PDF document.

The first PDF that I sent the client before the next stage of the project started

The results were unexpected. My client loved it. The timeline quickly spread throughout the office. There were less questions about progress, less anxiety, but most importantly, I had their trust.

I learned that a small effort towards communication was a huge value add.

I continued iterating the balance of informational value and overload. I explored "Right Timed Notifications" where I sent project summaries each month via email.

An email outlining a sequence of the upcoming milestones

Research

The Problem is Scope Confusion

The solution was interesting but the problem wasn't defined. I started reaching out to other freelances to gather insights, starting with a long list on interviews.

The initial set of interviewees and the schedule, done in Google Sheets.

Constructing the interview template informed what problem I needed to understand around communication:

  • What is the real pain?
  • Is this a common pain point?
  • How severe is this pain?
  • Who is it that experiences this pain?
  • How are contractors circumventing this pain?

Here's a snippet of the interview template with questions and the $10 feature test. As shown, this interviewee added "blocker/resolved" functionality to make it clear where client's were blockers were present.

These interviews exposed the initial problems most commonly facing freelancers:

  • Scope confusion (lose track, off track)
  • Alignment of expectations and assumptions (afraid to talk in contract language)
  • Software disrupts flow (Cognitive overhead - PM software is too heavy, both for client and freelancer)

We found that most clients working with a freelancer have worked with only a handful of other freelancers. This revealed that confusion was caused by lack of experience, not by malicious intent.

Because clients were new to the creative process, they weren't intentionally adding "scope creep" which is a primary challenge described by freelancers. They were just new to the process.

Freelancers didn't understand this about their clients. We then clustered insights about freelancers:

  • Typical Day - most don’t have one!
  • Hate confrontation - difficulty charging for scope additions
  • Reason for quitting freelance as a profession is dealing with challenging projects, mainly scope challenges.
  • Never fire client, rather make them happy and eating time cost
  • Lose track and get off track

Insights about clients:

  • Low project experience for client -> the majority of clients haven't built 4 websites, shipped 3 apps, or branded 5 companies.
  • Clients are more confused than are creepin'
  • Revisions are planned, tweaks are not - tweaks are where troubles occur
  • Client assumes to pay for deliverables, not process

When scope creep happens:

  • Length of project phases: granularity of tasks
  • During "Creative leaps"
  • Revision / tweak surplus
  • Undefined role / feedback requirements

These insights brought actionable steps to discovering product-market fit.

Define

Discovering the Value Proposition

We clustered the insights into categories. Then we assigned points to each category to inform the problem we were solving.

Design Challenge: Improve communication on service based projects
Pain Point: Scope confusion makes contractors work more and earn less

There were two angles we could tackle: Roadmapping (forecasting future assumptions) or Communication Tracking (passive tracking using integrations)

Sketch of a conceptual diagram depicting the two routes that directed the product strategy.

We found 3 areas for communication: Proposals, Deliverable progress, and Communication Tracking.

History tracking meant automatically track when one uploads an Invision document, pushes a github build, made a payment through paypal, and so on. This was considered "activity tracking."

The other was forecasting, or roadmap planning. Roadmap planning helps client understand what is needed, what is expected and the penalties if those deadlines are not met.

We spent a good chunk of time thinking through which of the two routes was best for our MVP. What it came down to creating the most value with the least technical effort. Since "roadmap planning" didn't require time consuming integrations (we used Sendgrid) all while providing value to the pain (scope creep), we choose that route.

A desirable product would be:

  • Non-derivative: doesn’t replicate any features of other existing products (Slack, Asana, Basecamp)
  • Minimal Input: balance between usefulness and input time
  • Lightweight: does one thing really well, focused and small (most of these folks don’t want the power of Asana or Basecamp)
  • Visual: for both user and client. Visualized progress for client, translating between contractor and client

Our audience was both the client and the freelancer so we made storyboards to map out each user journey.

Storyboard of a user type and their journey to fully adopting the app

The storyboards revealed major assumptions that we were able to test, mainly concerning marketing messaging and top feature requests.

When I navigate my timeline, I want to see only what's blocking so that I can quickly email my client to resolve
Prototype

Building the Vertical Timeline

Breaking from the horizontal convention made sense since the majority of roadmaps were gantt charts, with horizontally navigation. This was a differentiator but also served in usability.

Usability studies showed that users favored a vertical scroll for its natural ergonomics. A timeline that was vertical had more natural interaction, more visible real-estate (optimized for mobile), and a huge feature request: zoom. Users needed to quickly zoom in and zoom out, seeing the big picture and small details which one click.

A series of "How might we" questions guided the design:

  • HMW auto-track project activity from multiple platforms for a contractor?
  • HMW help clients understand the project’s process?
  • HMW avoid breaking flow / adding distration?

On the left is the iterations of input event to the timeline. The right is iterations of the add functions interaction.

For every solution we found on the vertical timeline, there were 5 other problems.

Problems included: How is time read, chronologically or reversed? Does padding between two dates represent time or does padding have no meaning? How do multiple milestones for one day work? How do integrations get added on an individual milestone, versus employed upon the entire timeline?

Screenshot of a screencast during a usability test

We found critical errors after weeks of usability testing. We video recorded every test and went back through it.

Principle helped make prototypes quickly. The prototypes weren't full functioning but we just needed to complete a flow and that worked fine.

Early explorations of desktop UI

Once we fixed the UX errors, we built a live prototype using Meteor.js (a powerful testing bed for rapid prototypes)

View live demo at https://bit.ly/2VjyQtr

We learned users interacting in unique ways with our prototype. For example, when someone wanted to do an IFTTT, they would use brackets. If they wanted to tag a stage, they would use parenthesis. We could use this to design how integrations and tagging worked.

Iterations of the timeline with events and integrations

Questions emerged from these statements like: who to market to, what type of freelancer, who would pay, what features are essential for v1.

We found that we could make prototypes for testing desirability and usefulness of the product using facebook ads, social media launches (betalist), and interviews.

What to test: adoption, desirability / usefulness, and usability.

Screen shots of the various marketing prototypes (not testing the actual product) that informed the messaging and value offered. We made a decision and wanted to gauge the desirability so we made a series of facebook ads. Those ads further taught us what was valuable about the product.

Launch

Just Ship it

It's never easy to ship. Either you are too early or too late. This was a case of the latter. But we had a working app and we decided to ship without our stripe integration.

Sign ups during the first week of launch

Motivation started to root itself. We had built something people were willing to pay for:

I'd be pleased to pay 50 Euro per month, plus VAT

Feedback from users

The product UI / UX was well received. We successfully were able to hit our product objectives.

Here's the screens we launched with:

The iOS app screen shots

Prototype of the natural language parsing

The product had great traction at launch. It was looking promising and we had a lot of excitement and validation to the year of building we did.

The unfortunate turn was when some unseen life circumstances caused the team to split.

Things learned

  • Branding was a big time suck; the first iterations did the job
  • Use open source timelines for Proof of Concept
  • Find money to build; give it two years of building

The last effort was fundraising. With enough development force, we could really push out the features that made omelo shine.

Here's the pitch deck.