Why My First App Worked
Hint: it wasn’t because of the code.
Just over a full year ago, Jason Laster (@jasonlaster11) approached me at the end of the term with an idea for a project. Dartmouth’s student government was looking for web developers to create an online database of all the organizations on campus, and he had responded to the job offer. Even though I had never worked on a web application before, and knew only simple web programming at the time, I jumped at the opportunity to get involved. If anything, I told myself, this short, 3-week project would give me a leg up on Ruby on Rails before I started my internship at Art.sy that summer.
A year after that initial conversation, we launched DGD — short for the Dartmouth Group Directory — to campus, and the launch was more successful than any of us could have imagined. Just a week after we sent the initial email out to all undergraduates, over half of the student body had visited the site and were spending upwards of 5 to 10 minutes browsing each group’s pages, a statistic that is considered outstanding in the fast-paced world of the internet.
By the end of it all, I had learned a whole lot more than simply how to code a database-driven website. While I won’t pretend that getting undergraduate students to use a free service is that similar to launching a real product, the biggest lessons learned ended up being about marketing. Surprisingly enough, what ended up actually getting real users had little to do with how perfect our code was, and much more about conscious design decisions that impacted our final site and how it was presented.
Solve One Real Problem
Soon after agreeing to the project, I learned that Jason didn’t take the job just for the money or for the technical challenge. It turns out that he had actually tried a similar project in his freshman year, except that it was much more ambitious. It was intended to be a full-fledged social network for Dartmouth groups, where each group had a page, and students could follow group updates and have profiles of their own. But even after making strides in addressing the technical challenges behind creating such a service, it never took off. He eventually scrapped the project, thinking that there simply wasn’t a need for an app like he created.
We learned with the success of DGD that there certainly was a need for a group database. But even with a need, a lack of focused design prevented DGD’s predecessor from being successful. It simply tried to do too many things at once without clearly defining exactly what it was intended to solve. On the other hand, when we first discussed DGD, we were very clear about the goals of the site and boiled our ideas down to their essentials. DGD would be nothing more (and nothing less) than a searchable database of organizations, each with a text description.
But of course web apps are typically much more complicated than that. Even DGD has grown far from that initial goal. The key rule is that complexity can’t come before functional simplicity. Now, each group in DGD gets its own page, complete with a full HTML what-you-see-is-what-you-get page editor. But that feature did not come before we had simple group descriptions fully functional. You can still see the remnants of that decision in the code base: even though we now think of groups has having pages, the model that deals with the pages is still called Description. (Yes, we should probably get around to changing that.) Designing a huge web app around a complicated and poorly defined problem is destined to lose momentum and result in a disjointed product. A simple solution to a simple yet real problem that can be iterated on is a much more sustainable model.
Find Out Who Matters
As much as this was a painful realization, it has become very clear to me that the general public does not care about or trust the lone developer. Even if you are an expert coder and designer, and you’ve defined and solved a very real and important problem, simply throwing your app on Heroku and posting a link to it on Hacker News and Reddit has a very low chance of driving significant and lasting traffic to your app. There are certainly exceptions to this rule. But the simple fact is that the average person doesn’t know you. Their lives are going pretty well as it is without your service, and who are you to tell them otherwise? You’re a complete stranger.
If someone they know and trust is telling them to use a service, however, it’s a completely different story. As it turned out, being partnered with Dartmouth’s student government was essential to getting people to use and contribute to our app. Not only did Student Assembly have the ability to send out emails to all undergraduates advertising DGD, but also they had the authority of a ruling campus body to add legitimacy to our project. We found another strategic relationship with the webmaster at Dartmouth — luckily Jason knew the webmaster well and was able to secure the dgd.dartmouth.edu domain for our app, but only after a month of negotiating.
Looking at a Google Analytics dashboard, it’s hard to fully comprehend that each and every one of the total page visits was an individual sitting at his or her computer and experiencing your product firsthand. Even for a small web app like DGD, with weekly visits now settling in the hundreds, it would be impossible to connect personally with every visitor. But you cannot neglect the human side of your visitors. Your app has a life outside of the closed world that you create — people talk about it, have opinions about it, and have other things they’d rather be doing than using it. People would prefer to interact with other people over a soulless machine, so you have to make an effort to not lose the human element.
To address this, we first made real world rewards for using the app. DGD is a community directory, so the number of pages and the quality of those pages depends entirely on people’s willingness to write about the groups in which they participate. People don’t really like writing essays. But they do like gelato, especially the best gelato in the United States. So we offered $10 Morano Gelato gift cards to the top 10 contributors to the site after the first week, and got over 50% of our content from that marketing push.
There are also many tools available for interacting personally with your users. We chose Intercom and loved it. It allowed us to track the email addresses of the Dartmouth students signing in, and send them welcome emails suggesting that they add content. It’s easy to overdo emailing your users, but we got a lot of positive feedback about the few emails we did send. People are often surprised that you even have a record of them visiting your site, and respond well to personal messages thanking them for visiting and for contributing content. Of course it helped that the emails were coming from a fellow Dartmouth student, and people might be less receptive to random emails from developers. But Intercom allows you to send your users messages through the app, which can be much less intrusive and is a great way to keep connected.
Be Your Best User
No amount of automated integration tests can make up for actually using your site on a regular basis. I’m far from the first person to point this out: see this awesome post from the Art.sy engineering blog and this short yet sweet post from the creator of Forrst. Actually becoming a user of your site will allow you to see how all of the separate features you’re working on come together to create a hopefully coherent whole experience. It’s important to try your best to think like an average user, rather than a developer, however. Initially, our page editor was built around Markdown, a clear choice for those already familiar with blogging syntaxes. But we soon realized that the average user would much prefer to use a simpler HTML page builder with a live preview of the results. (We used wysihtml5 and loved it.)
Sites with user generated content have another reason for their founders to be active — if not the best — users, at least in the sites’ early stages. Sites like these have a classic chicken-and-egg problem: the content needs to come from the average citizens of the internet, but people are less likely to contribute to a site that doesn’t already have a lot of content and readers. You can have exponential growth in users and contributors, but not without a starting spark of content to get people interested. That content has to come from you and your team. We seeded DGD with content from already existing organization’s websites scattered across the internet, and as a result provided a great service from day one. The first contributions were from organizations that edited their already existing pages, and soon after, groups that never had a web presence started creating pages.
This is far from an exhaustive list. Nevertheless, these four elements are essential best practices we discovered through making and marketing DGD and should be on your mind as early as possible during the design stage. We spend a lot of time learning how to engineer fantastic solutions to the world’s problems, but these efforts can fall flat if you forget the less tangible human element that governs whether or not people will realize just how great your product is.