The idea for ImThere was born in July ‘05 out of necessity—it was a chore finding fun stuff to do around town. Fifteen months and many pots of tea later, we launched a service that we had hardly even tried to use. Soon after, we began questioning if it was what we even wanted.

Last June we finally launched the ImThere we had envisioned over two years ago. We are now finally able to find stuff to do that we wouldn’t have known about otherwise.

And So it Began…

Development of ImThere seemed clear-cut. The functionality was outlined and broken up into the site’s distinct pages. We let our designer and two developers figure out how best to design and architect the site. Once we prioritized the functionality to be developed and the pages to be designed, we created a weekly schedule providing a roadmap to launch. We appeared to be off to a smooth start.

What Our Team Began With
What Our Team Began With

Our first glimpse of ImThere came three weeks later, when our designer uploaded his first pass at the main page. It looked great. That, combined with our excitement seeing ImThere for the first time, resulted in joyous expletives. Once we calmed down and compiled actual feedback, we had a list of items like:

  • “The green arrow submit buttons are too bright and distract a little”
  • “Let’s change Weekly to Daily on the featured venue/artist”
  • “It looks like the View More links for Important Events and Hot Events have different font weights”

Valid feedback, but completely focused on aesthetics and nitpick-y details.

Revisions of the Main Page
Revisions of the Main Page

As the design progressed, the developers were hard at work on the back-end. From content targeting to popularity algorithms to exotic data handling, we had very lofty goals—all to be included in version 1.0. Even seemingly simple things turned into intricate projects requiring custom code, rather than using what Ruby on Rails, the ImThere platform of choice, provided.

With three months of the back-end work complete, designs began to be applied to the website. Despite the immense back-end functionality, the front-end appeared extremely basic. The event, venue, artist, and user pages were pulling data from the database, and data could be entered through crude forms. But it was a start, and we were thrilled to finally have the developers working on something we could see. However, given the back-end functionality still needed for the launch, the front-end work moved sluggishly.

Logged In Users Saw a Different Main Page
Logged In Users Saw a Different Main Page

Another three months later, even though the website was shaping up, our position was similar. Entering data was a chore, and there were too few ways to interact with the website. Even so, we felt the time had come to release something. We rushed to flesh out the remaining pages and smooth things out as well as we could. As time ran short, we began cutting the visual elements that were not yet coded. Finally, after a 30-hour marathon coding session, we launched.

Kicking it Out the Door

When a launch finally arrives, an indefinable feeling runs through everyone involved. It’s a mix of excitement, relief, and anxiety over what happens next. In our case, the anxiety turned to eerie silence as we saw people leaving the website soon after arriving. Truthfully, we couldn’t blame them. Since many of the planned interactive features were scrapped to get ImThere out the door, there wasn’t actually much to do. And since we couldn’t add content until right before the launch, there wasn’t much to see either. Our team even struggled to use it and found little value or enjoyment.

Warning Users About What They Were Getting Into
Warning Users About What They Were Getting Into

Over the next two months we slaved over the code to add missing features, develop new ideas, and fix up the remaining bugs. The website became unquestionably better, but people still weren’t latching on. Not only that, we were even still forcing ourselves to use it. It was a bad situation; no one was falling in love with it no matter what we tried.

There comes a time when you have to accept things just aren’t working, and you need to take a step back to figure out what’s really wrong. After just a few months, we had reached that point.

Taking a Step Back

At first, we were confused as to what the problem was. We had successfully implemented the functionality we had originally defined, and the few remaining missing elements couldn’t explain the state we were in. The website looked great, so that couldn’t be the problem either. After dragging ourselves away from development for the first time in nearly nine months, it dawned on us what had happened—we had taken a feature list and developed it into a website.

What we built had very little flow to it and felt forced. Each page seemed so disparate from the others that users couldn’t get the big picture, let alone find reasons to use it. It felt like a bunch of random features bundled into the form of a social event-themed service. The problem became even more apparent when we struggled to recall what the original vision was. The feature list not only dictated the design and development, but also became our guide to describing ImThere to others. We were in trouble.

The good news was that it was easy to see everything we had done wrong:

  • ImThere was built and designed around a feature list
  • Aesthetics were the focus of the design, with little thought put into actual usability
  • Coding the high-concept back-end consumed nearly all of developer time
  • We tried to do too much for a version 1.0 website, and didn’t have the focus to pull it off
  • We never really tried using the website before launch, due in part to its incompleteness

Taking those missteps resulted in a myriad of problems:

  • ImThere felt one-dimensional and lacked continuity, preventing it from being useful or fun
  • The purpose of ImThere was unclear to users
  • Users would have to adapt to using the website since few things were intuitive
  • Much of the advanced back-end was left unexposed in the front-end

Our brand new website was fatally flawed. It just felt wrong and no amount of Band-Aids could fix it. Furthermore, in the meantime, a number of other social event services launched. When ImThere was originally envisioned, none existed. Now, in addition to problems with the website, much of our originality was lost. Our next move was obvious.

We had to scrap it.

That was remarkably hard to do after putting so much effort into something that had barely seen the light of day. We knew we would have to reinvent and completely rebuild ImThere, while being cautious not to repeat the same mistakes. Of course all websites iterate and iterate, but we had to do it in an extreme way. And do it we did.

Getting it Right

Before telling the team to scrap everything they had coded and designed, we first wanted a plan that was solid, realistic, and fully thought out. We began by focusing on the useful and fun qualities, which fortunately came together quickly. Our efforts also focused on overcoming the limitations of launching city-by-city, which our initial plan called for. A solution did come to us, and ended up being the cornerstone for the new ImThere. We would support “locationless” events in addition to local ones, which could include things like movie premieres, the release of the iPhone, Talk Like a Pirate Day, and even virtual events. These events could be relevant to anyone, allowing a ‘net-wide launch and providing ImThere an identity distinct from our new competitors.

Feeling confident about our refined and solidified vision, we set out to really plan it. This time we were determined to avoid the same traps. We locked ourselves in 24-hour coffee shops for a couple of weeks and extensively planned out every page. We would keep sketching out each page until we had it just right, and flesh out wireframes in the fantastic OmniGraffle application.

The First ImThere Wireframe
The First ImThere Wireframe

A big theme for the new website was reusability. Many elements like feeds, content streams, listings, and timelines were shared on pages throughout the website. Our event, venue, artist, and user pages shared the same base which was then tweaked for their individual needs. Other pages worked similarly; determine the necessary elements, and then tweak the page for its specific purpose. This process allowed the developers to perfect common elements and rapidly build out pages. It also allowed us to reduce the number of interfaces a user had to become familiar with.

Throughout development, we anticipated the various ways a user might use ImThere. For each page and feature, we thought about how a user would discover it, use it, and continue on through the website. When we were done, ImThere felt fluid, open, purposeful, and fun! We went from thinking “we want to use a service like ImThere” to “we want to use ImThere.” It provided reassurance that we were doing things right this time.

The differences were obvious; this time we had:

  • Developed a complete idea, not just a list of features
  • Wireframed every page of the website, forcing us to work through the flow and usability
  • Took development time into consideration and found ways to avoid spending months on just the back-end
  • Took a step back before development started to make sure this we had what we really wanted

We had to build the first version of ImThere to know to do these things. The lessons we learned were worth every second spent and the new ImThere could not exist without them. Looking back can be tough, but you later realize you had to take the steps you did. Fortunately, we realized our mistakes quickly enough to have the time to take our next step.

Take Two

Next came getting the team onboard with the new vision and getting their feedback. Their opinions were extremely valuable, especially since it was completely fresh to them. Everyone on the team was on the same page and embraced the opportunity to have a second shot at making ImThere the service we all wanted.

Both design and development went dramatically smoother the second time around. It was more clear what needed to be built which sped everything up and made for more realistic scheduling. Wireframes allowed for more design time to be spent on usability and less time on what needed to go where. Once the look and feel of the website was nailed down, the remaining pages went through relatively few revisions compared to pages for the first website. We were able to do this not only due to the wireframes, but also to sharing elements across pages. Towards the end of development, we even had the luxury of tweaking the design, which we had no time for even after launching the first ImThere.

Revisions of the New Main Page
Revisions of the New Main Page

Visual results began shortly after coding. We were able to carry over some back-end code, reducing the time it took to start on the front-end. This allowed us to start using the website very early on, which had been one of the biggest problems before. For the first time we could find out what worked and revise what didn’t. On the first version of ImThere we weren’t even able to add events until the last week of development, but now we could begin adding, modifying, and interacting with content months before launching the new ImThere. Around this time a bug tracking service called Lighthouse was released, which made reporting bugs enjoyable and manageable. It allowed us to report, prioritize, and track every little thing that wasn’t quite right.

From 0 to 3 Weeks
From 0 to 3 Weeks

We ended up launching this past June, which was later than we had hoped. However, it was to allow us to add little features we wanted and polish the website, not to develop rudimentary functionality. About a month prior to launch, we let a variety of people in for a private beta. This was something we hadn’t even dreamt of doing with the first version. During the final month, we fixed all known bugs, finished the last of the features planned for launch, and tweaked and tweaked everything.

Once Lighthouse reported 0 remaining pre-launch tickets, we launched the new ImThere—the ImThere we all wanted.

Easing it Out the Door

After pushing the elusive launch button and drinking the obligatory champagne, we found ourselves on our laptops, sitting around a table at one of our developer’s houses. We weren’t frantically fixing bugs to keep the website from crashing, nor were we trying to code last-minute features. We were simply using ImThere and enjoying it.

As the first batch of users rolled in, we interacted with them and watched how they were using the website. They filled out their profiles, commented on events, sent messages, just explored around. No one left right away. From a statistical standpoint, our pageview to unique ratio was very favorable. That is a good sign, because even without stellar uniques, having people stick around means you are doing something right. All in all, our launch went as well as we could have hoped, and it seemed that we were finally on track.

Getting the User Page Right (old -> wireframe -> new)
Getting the User Page Right (old -> wireframe -> new)

We quickly got off our post-launch high and went back to work. For the first time, we had a solid base to build upon and could begin making forward progress. Our work over the next few months consisted of:

  • Gauging initial user response and improving the areas that needed it
  • Building the features we had put off until after launch
  • Evolving our existing features to make them more useful
  • Getting the word out to start building up our userbase

As we worked we would frequently take a step back to ensure we were on track and sticking to our vision. After our first time around, it was very important to make sure we didn’t waste a second working on the wrong thing. We were now focusing our work on strengthening the identity of ImThere, something we had failed to accomplish before. Since ImThere was designed in an open way to support a broad scope of content, it was challenging to make the value of the service immediately apparent to users. That concern drove our early focus on building utility-based features, like an invitation system, so prospective users could quickly find value. The hope is that once they sign up and begin using ImThere, they will see the big picture.

With a few post-launch months under our belt, ImThere was ready for the masses, and our next set of big ideas.

Where We Are Now

Over two years later we finally have the fundamentals in place and can enjoy making ImThere great. We are now faced with a new set of obstacles: reaching more users and demonstrating the value of the service to them. We also must keep looking into the future for ideas to maintain ImThere’s uniqueness and rapidly develop those ideas into realities. No matter how satisfied we are, standing still can never be an option.

Redesigned Signup System Based on User Feedback
Redesigned Signup System Based on User Feedback

The team is already working hard to evolve the very essence of ImThere. At the center of this evolution is the one key idea still missing from the original vision. Implementing this idea couldn’t have happened or even re-entered our minds without building the open, community-driven service we have now. With those fundamentals in place, the idea that began our journey returned, and proved to be a solution for our current obstacles.

ImThere Today
ImThere Today

This further demonstrates that if something isn’t working, you need to look back and figure out what got you excited in the first place. That is how we put ImThere back on track and why we have full confidence that it will soon be a success.