For Challenge 10, we built Artix — an iOS app for sharing links with groups. We were inspired to build Artix after encountering the same problem over and over again: within different in-person conversations about a variety of topics and with a variety of groups, we kept finding ourselves referencing interesting things we’d seen in the news or recently read, and saying something along the lines of “I just read this awesome article I’ll send it to you guys later.” Not only was it far from a guarantee that the article would actually get sent (and often only after much prodding), but even still the articles would almost always get lost in a sea of other messages on a variety of platforms. Going back and finding these articles was an arduous process that entailed checking various email groups and accounts, text threads, facebook posts, and slack channels. Similarly, we couldn’t entirely blame the senders given that sharing articles with a group was a similarly unpleasant process. After looking at this problem more carefully, we also found that although many groups were separate, often we would want to share similar articles with our roommates, our classmates, and our colleagues but in established different paths. After querying our friends, we found they had encountered similar problems. Unfortunately, the solutions usually favored not sharing articles at all instead of dealing with the sharing burden, a sort of sad result for intellectual curiosity and knowledge-sharing in a university context. One last observation that shaped our first prototype was that many people (ourselves included) tended to have an article-saving method of choice, be it their Safari Reading List, an app like Instapaper or Pocket, or even something as lo-fi as keeping every article open in a different tab on Google Chrome. None of these methods talked to one another, and none of them had the social capabilities we were after, so we decided to try building a solution ourselves.
In a few brainstorming sessions we came up with the basic list of features we wanted to include and how we wanted the app to look. Initially we kept the list as short and the design as simple as possible, to get to the proof of concept stage as quickly as we could. Given that our collective experience with full-stack iOS development and design was fairly limited, we were both extremely excited about the opportunity to learn more and improve our skills. At the same time, we wanted to get something out there as quickly as possible to collect feedback and iterate.
Without repeating too much of what we wrote in our competitive landscape document, we found that most existing alternatives are social-media based and require using broad strokes — it’s very easy to text an article to one or two people or post an article on your newsfeed to be seen by hundreds…anything in between requires a few more steps. Our most interesting realizations came while actually in the field, speaking to as many people of as many different demographics as we could.
We first asked interviewees general questions about their article reading, finding, and sharing habits, to get a general sense of patterns both in general and among specific groups (high school/college/grad students, professionals in different industries, etc). We were specifically interested in how often people read articles (a sort of baseline measure of the size of the problem we’re addressing given that if someone reads no articles, they would by definition have no need for an app that helps them find or share these pieces). For those who did read articles fairly frequently (the vast majority of our interviewees), we then delved more deeply into how they find these articles, whether they share the ones they like, and if they share them what methods they used.
Simultaneously, we also probed into the “why”s involved in the article reading and sharing processes. We figured that the better we could understand the psychological and emotional reasons underlying why people read articles and — more importantly — why they want (or don’t want) to share these articles with friends or colleagues, the better we could build something that fits their underlying interests and disrupts the current process of article sharing, rather than making slight improvements on what currently exists. To this end, we tried to ask as many open-ended questions as possible, to foster idea generation.
One surprising revelation we discovered after experimenting with how we approached strangers was that having a prototype on which our interviewees could ground their comments actually increased the number of interesting ideas and features that people would mention. This was a bit counterintuitive since one would expect that people would be reluctant to insult something you’ve already put time into, but we found that having a prototype in fact helped people more quickly wrap their heads around the idea of a standalone article-sharing app (admittedly not the most complex concept), which then allowed them to brainstorm better solutions. This direct feedback on our prototype was immensely useful, as it gave us actionable insights as well as big picture guidance.
In general, we found this step of market research to be rather fascinating, as it gave us an opportunity to test our own hypotheses with those of our potential users. To be completely honest it was also more difficult than expected — for whatever it’s worth another lesson learned is that people in Harvard Square don’t particularly love being approached by strangers.
After fixing a few bugs, cleaning up the design, adding a few more features, and configuring the backend, we then spoke with Beth, who impressed upon us the importance of building out a user journey to better understand how people would truly interact with our app. This was an eye-opening conversation, revealing that, despite the interesting takeaways that we found during our market research, we had in fact only scratched the surface. That advice and our resulting conversation led to the following User Journey, which we separated entirely from our current Artix iteration and brainstormed strictly with pen and pencil. To translate what we’d drawn into something slightly cleaner we first played with Keynote, then settled on realtimeboard.com. The result is below:
Comparing this journey to our existing build, we once again entered the iteration phase, resulting in the following features:
1. Register as a new user
2. Authentic users through login
3. Create group from your Contacts
4. Edit / Leave groups (via swiping right to left on a group)
5. See which user added an article
6. Click on articles to read them inside app
7. Add article to group via copied link or directly from clipboard
8. Save articles to a personal list (via swiping right to left on an article)
9. Delete articles from your personal list (via swiping right to left on an article in your personal list)
Many of these features involved non-trivial design decisions. For example, we spent a lot of time discussing who should be able to edit a group. At first we thought only the creator should have control, but after exploring different methods we settled on the GroupMe approach in which everyone has equal access, to most closely replicate the dining hall dinner conversation feeling we’re pursuing.
With more time there are definitely features we hope to develop, such as public groups that can be followed or joined, topics tagging, and comment threading, but we would love to hear all of your feedback on both design and functionality! A screencast of our most recent build of Artix in use can be seen below, and if you’re interested in getting on the current version send us an em
ail with your phone number, and we can add you to the TestFlight group!
