CASE STUDY: Jibe, an iOS app

How we built the app, from idea to App Store

Over the past few months, Rhombus (my Startup-as-a-Service company) has been working with Yolanda Askew and The Legacy Group on a clever app designed to challenge how groups of friends share photos.

The app is called Jibe.

What is Jibe?

Jibe is an app for groups of friends taking photos together. On Jibe, you join intimate groups who take, experience, and share photos as a single democratic collective. These groups are made for particular events, particular groups of friends, or particular shared interests.

Within a group, when photos are taken, the photos are instantly shared with all the members of the group. The group has one collective, real-time Camera Roll. Jibe users no longer need to share photos over text, email, iCloud, or downloaded from Facebook.

When the group wants to share a photo outside the group, the members must vote on the photo. If the group votes “Share”, the photo can be shared externally by any member. If the group votes “Don’t Share”, the photo is locked up in the group forever.

The group — not the individual — has complete control over every photo.

Sounds cool, right? Download Jibe on the App Store.


CASE STUDY: How Rhombus builds apps

The rest of this post isn’t a traditional press release. Instead, it’s a detailed look at how Jibe was built (from idea to App Store) and how Rhombus works with non-technical entrepreneurs to build stunning mobile apps.

1. Start with an explicit problem

Rhombus’s best clients almost always start with an explicit problem, not an app idea. The difference is subtle, but important: An “app idea” is typically a predefined solution to an unspecified problem (for example, “Airbnb for parking spaces” or “Uber for puppies”), whereas an “explicit problem” is something tangible that a not-yet-defined app can potentially solve (for example, “It’s really frustrating to find parking in the city” or “I love playing with animals, but it’s too much responsibility to own a pet right now”).

Working from a problem (and not a solution) consistently produces better apps with stronger identities and missions.

So, when Yolanda (from The Legacy Group) approached Rhombus with a clear, personally-felt problem, we knew this was going to be a strong partnership.

“Sharing group photos is hard.”

Yolanda articulated two clear problems around “sharing group photos”:

  1. After a party or corporate event, she wanted to easily aggregate the photos she took with her friends and coworkers. She found her current method quite frustrating: When she sent out a Dropbox link, very few people actually uploaded anything. When she asked each person individually for their photos, she ended up with a big mess of photos via text, email, Facebook, iCloud, etc.
  2. She didn’t feel like she had control over the photos she was in. With her friends snapping photos on their phones, Yolanda ended up in dozens of photos that were posted to Facebook, Instagram, etc. regardless of whether or not she wanted them to be.

2. Explore the many ways to solve it

Over the next week, we explored all possible ways we could solve Yolanda’s photo sharing problem. Nothing was off-limits.

After narrowing down the field, we settled on three interesting app concepts:

Option 1: The Tech Solution

We could create an app that has access to your phone’s Camera Roll. Then, using facial recognition software, the app would determine which of your friends are in which of your photos. Automatically, the app would forward the relevant photos to each of your friends, without requiring any work on your part.

Option 2: The Corporate Solution

We could create an app to help corporate legal teams more efficiently get employees and corporate event-goers to sign “photo release forms”, or perhaps sign “micro-releases” photo-by-photo after the event.

Option 3: The Social Solution

We could create an app that lets groups take photos on one collective Camera Roll. Then, if someone wants to share a particular photo, the group members would need to vote. The majority vote would rule.

Then, we picked one.

We were excited about Option 1, especially because we thought the technology would be really interesting, but ultimately we decided against it. Option 1 didn’t actually solve the problem — there would still be multiple instances of photos, and photos would still be aggregated from multiple places. It would all just happen a little bit more magically.

Option 2 was certainly the least sexy, but definitely presented a real business opportunity: All big companies use photo release forms at some point, and many of these companies still use paper forms a lot of the time. It’s likely that these companies would be willing to pay for a more effective and elegant solution.

Even though this option presented the most immediate path to monetization, it was only tangentially related to Yolanda’s problem. So, we scrapped this one too.

Option 3 remained, and we both really liked it. It very directly addressed Yolanda’s explicit problems, and offered a genuinely fresh take on group photos: The concept of “democratized sharing”.

We picked Option 3.

3. Detail the solution

With the basic premise in hand, it was time to detail the explicit functionality of the app in a contained document. We would use this document to iterate on our thinking, and ultimately inform our design decisions later on.

Functionality Overview v1

Through this exercise, we determined the key “screens” of the app, and the mechanics of how each screen would work and flow together.

The “Main Groups” screen

On this screen, users could see which groups they belong to, search for groups or people, create a new group with their friends, and click into a particular group (onto the “Single Group” screen)

The “Single Group” screen

On this screen, users could see the photos taken within the group, take more photos, edit the group settings, send a “Group Huddle” notification (to facilitate a group photo), or click into a particular photo (onto the “Single Photo” screen).

The “Single Photo” screen

On this screen, users could view individual photos, vote whether or not a photo should be shared, view details on the voting process, or share a photo (once the voting finishes).

Voting Mechanics

We determined that once the first person votes on a photo, a 24-hour countdown starts. If all members of the group vote (or a majority is reached) before the countdown ends, the photo is “Shared” or “Not Shared” depending on the majority vote (a tie = “Not Shared”). If the countdown ends before all members vote, then majority rules (based on those who voted).

Other Screen and Considerations

Additionally, we detailed the onboarding, notifications, settings, and user profiles screens. We also described how all screens fit together, what happens during edge cases (no groups, no photos, no signal, etc.), and generally how the screens should be laid out.

Linear Wireframe

To supplement the Functionality Overview document, we also put together a visual representation (via a linear wireframe) to better represent our spacial thinking.

Linear wireframe v1

4. Name it

While working on the features and functionality, we found that the app was very hard to talk about without a name. So, naturally, we needed to name it.

We went through a bunch of names — Troop, Unison, Cluster, Scoop, Ally, Consensus, Unanimous, Agree, Common, Opt, Cahoots, Unum — but ultimately settled on Jibe (which means “be in accord; agree”).

We liked the meaning, the simplicity, and the way it sounds. It’s a distinct word that feels fresh, yet familiar.

Jibe.

5. Find a design language

With the functionality defined and a name agreed upon, we were ready to start exploring the “design language” for Jibe.

We started by capturing Yolanda’s vision.

Since articulating or conceptualizing final designs can be challenging, we asked Yolanda instead to describe how the app should feel, and her general preferences around colors, etc. Here are some things Yolanda had to say:

“For the feel, I would like something fun and cool, but not cartoonish. I would like the user experience to be interactive, and give the user a sense of empowerment because they are part of the collaborative process. However, I want the process to be simple.”
“The colors that appeal to me are vibrant colors that pop but do not cross over into the neon realm. I also don’t want the color scheme to come across too girly.”
“If I had to choose between colors, I would go with a color that is not already overly used in other Apps. For example, if powder blue is the most popular color, we might not go this route. I would like my App to be appealing and to stand out. Looking for something that catches the eye without being obnoxious.”

We also determined that the main color elements of the app should come from the photos themselves — which meant we wanted to create a visually simple interface that supports the photos and occasionally features an accent color to highlight key actions.

With these preferences captured, we were ready to hire a designer and start creating some mockups.

Hiring a designer

Unlike other companies, Rhombus builds “custom teams” for every project, depending on the needs of the project. For example, if the project requires significant artificial intelligence, we will hire a team that specializes in this area. If the project requires real-time video, we’ll hire a team with this specialization. If the project requires a particular stylistic look, we’ll hire a team that has matching design sensibilities. With this flexibility, we are better able to create awesome solutions and teams on a project-by-project basis.

The hiring, managing, and paying of these “custom teams” are all done behind-the-scene by Rhombus. That way, our clients can focus on strategy and vision (instead of project management). We call this model “Startup-as-a-Service”, and we think it’s really powerful.

Therefore, with Yolanda’s input captured, Rhombus reviewed a number of design portfolios until we found a talented designer that was a good fit, had significant experience designing social apps, and whose style matched Yolanda’s vision.

Time to design

Once hired, the designer put together some rough mockups for the primary Jibe screens. These designs mainly featured an overall dark look, with purple and turquoise accent options.

Very early Jibe mockups.

I then reviewed the mockups, combined some of my favorite elements, and cleaned the designs up slightly. These designs weren’t meant to be final, but simply an attempt to capture early design thinking.

I then discussed these mockups with Yolanda.

Yolanda liked both accent color options, but we ultimately agreed that the purple color was more striking and original in the social space. We also agreed that the dark theme felt too heavy, and that the photos got a bit lost against the black background. So, we decided for the light theme, but with the purple accents.

With this decided direction on color, we started crafting a more consistent design language that we could scale across the entire app. We decided on a white navigation bar, a light grey background, and the purple accent color. We also stripped the design of many of the details overlaid on the photos to really let the photos themselves shine.

This is what we ended up with:

Often times, Rhombus and our clients will iterate many times through different designs, but (in this case) we quickly landed on the above design style. Yolanda really liked the focus on the photos and the limited distraction from the rest of the interface. The purple accents added a bold, but not overpowering, touch. The simplicity nicely complemented Yolanda’s vision for the app.

Jibe had quickly found its design language.

4. Scaling the designs

With a design language in place, the next step was to scale the designs across the secondary screens. We designed 66 screens in our first pass:

We reviewed the designs with Yolanda, captured her feedback, and iterated on the designs until we were happy.

The next step was to continue scaling the designs to support all of the edge cases. This required designing another 85 screens.

A lot more screens.

Along the way, we continued to iterate and improve on the designs of key features.

The Camera

We reworked the Camera screen a few times before it felt right.

Firstly, we decided to invert the original colors of the Camera button, so that the resting state was purple and the clicked state was white (this better approximated how a physical button would look). We also added a purple stroke around the button to add a little bit of interest. Finally, we replaced the flash and “reverse camera” icons with the actual words, and moved them to the bottom. This gave the Camera screen a more open, elegant design (especially with the much cleaner top navigation bar).

Group Settings simplification

We also decided to simplify the Group Settings screen.

We first removed the “End Date” option, which we felt didn’t add anything meaningful to the experience. Then, we removed the toggles, since the information they communicated was redundant (If the user inputed data, the field would be “On”; If the user didn’t input data, the field would be “Off”).

Lastly, we removed the option to set the location via Apple Maps, which we felt was an unnecessary complication. Instead, users set the Group’s location via a text label, which we think better suits potential entries (many of which aren’t explicitly on a map).

Cornermarks and Color bars

We wanted to create a design system that would make it easy for Jibe users to understand the “state” of a given photo. There are four possible states: 1) Voting finished and the photo is sharable; 2) Voting finished and the photo is not sharable; 3) Voting in progress; 4) Voting hasn’t started.

We determined that States 1 and 3 were the most actionable to users, so we specifically call those out (see below). For photos that have been made shararable, we give them a purple “cornermark” on the Single Group screen, and a purple bar (when users swipe through the photos). For photos with voting in progress, we use a gray cornermark and gray bar.

Although we never explicitly explain what these colors mean within the app, it only takes a user a few minutes to intuitively learn the system.

Cornermarks and Color bars

With the designs finished, we were ready to start the engineering work.

6. Writing specs & designing algorithms

Before writing any lines of code, it was important that we documented the underlying engineering decisions. Firstly, we had to determine how the overall app should be architected, how we deal with slow internet connections, how we optimize data loading, which prebuilt iOS classes we leverage, which third-party tools we use, which feature we need to build from scratch, how screens animate during transitions, how we deal with saving data, how we validate user-inputed content, etc.

We went screen-by-screen and documented each of these decisions in the Engineering Spec. We knew some of these items might change while we actually implement the functionality, but it was important to have a strong architecture in place before jumping in.

The Engineering Spec v1

During this process, we also needed to design the back-end algorithms that underly Jibe’s main interactions and data presentations. These algorithms would dictate how search results are sorted, how lists of users are sorted, how lists of groups are sorted, how notifications are generated and sorted, and so on.

A few examples of Jibe’s algorithmic questions

With the specs written, the architecture determined, and the key algorithms designed, we were ready to hire the engineering team and start the actual app development.

7. Building the app

Like with the designer, the engineering team was custom-built specifically for Jibe. This allowed us to create a hyper-specialized team with experience in real-time photo distribution, social graphs, search, and interface animations. The team included an engineering lead, three full-stack engineers, and a quality assurance engineer.

After hiring the team, we broken down the project into individual tasks, estimated the required time for each task, and reassembled the tasks into a dozen one-week Agile sprints.

Sprint planning and estimates

Then, we got to work.

After completing each weekly Sprint, we built a test version of the app and I recorded a video describing all the new functionality. We then shared the build and video with Yolanda for her review and feedback.

We implemented all feedback, fixed any bugs, and then moved onto the next Sprint.

Weekly videos for Yolanda

12 weeks later, the app was finished, fully tested, and ready to be submitted to the App Store.

8. Submitting the app

Once the final build for Jibe v1.0 was ready, we only needed to do a few more things before submitting the app.

We prepared the app icon.

Created screenshots for the App Store.

Filled in all the remaining information on iTunes Connect.

And then finally, after months of work, clicked the big blue button…


Max Deutsch is the founder of Rhombus, a Startup-As-A-Service company, based in San Francisco. Rhombus works with non-technical entrepreneurs to build stunning mobile apps, like Jibe.

Learn more about Rhombus here.