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.

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

The value of the concept was interesting but the problem wasn't defined. I began interviewing freelances to gather insights around their everyday pain points.

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

The signal that I initially sought to find in the interviews was around communication:

• What is the real pain behind (mis)communication?
  
• Is this a common pain point?
  
• How severe is this pain?
• Who is it that experiences this pain?
• How are people 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 pains facing most 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.

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

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.

With our prototypes, we were also interested in adoption, and gauging desirability and usefulness. We made a series of ads to A/B test different messaging sequences.
‍

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.

We had a working app with our initial feature set, user management setup, but without payment integration. We launched with our 346 beta group.

Sign ups during the first week of launch

Motivation started to root itself. We had built something people were willing to pay for. We received a lot of comments about how much, if any, would people pay to continue using our app.

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

Feedback from users

App Screenshots

Mobile Nav Menu

Integrations

Logic for NLP

Landing Page

Onboarding Sign up screen

Onboarding Sign up screen

Add Event Component

Public URL Timeline

Style Guide

Pitch Deck