Monk to help turn ideas into words
A product designed to help people get more comfortable with writing and sharing articles.
While taking a course with Cornell Tech called Product Studio led by Greg Pass and Leland Rechis, my team and I got the opportunity to work with Medium to help their users publish high quality articles with reduced time to write and minimal distraction. The following is product journey of our team along with demo of the product.
Challenge by Medium: How might we help people turn their ideas into words?
Defining the Users and Problem
Before jumping into the problem and solution, we wanted to learn more about the topic and define our users and their niche issues. We started doing research on the kind of users medium has such as people who write, people who share and people who read. As we are focusing on the writers, we divided that group into multiple categories such as professional editors, business owners, promoters and people who write to share ideas with no other incentives.
As we decided on our targeted user group we wanted learn more about their act of writing and sharing. We started asking questions such as who are they? What is their background? What kind of interaction do they perform in order to write a good article? Why do they write articles with no incentives? Why do some people share and the rest don’t? These questions helped us frame our end goal and define the problems we want to tackle.
As we started answering our questions, we made a list of all the problems that our users face and narrowed down to few that we want to focus on as we had mentioned in our previous article and below.
Distraction
When you have an idea it is usually something that needs to be developed through an online research. In our user research, we found that most people capture their ideas in online/offline notes and then start researching on the web for further information that can help reject or approve their idea. However, we also found that many people notice that when you continue researching you can easily get distracted by either social networks or another interesting information on the web. Distraction is a big deal when it comes to writing. Some might say that distraction is the enemy of writers because it creates a chain reaction leading to serious time consuming and reduce productivity.
Lack of time
Writing takes time. Writing on Medium takes, even more, time because you want people to have the incentive to read your articles and share them so you have to make it super engaged (big wide beautiful high definition photos) and very informative (relevant quotes and online statistics). In our user research, we found that writing on Medium intimidates many people because they don’t have enough time to ensure that their article would be good enough to be shared a lot.
Laziness
See the above paragraph and add Laziness to the equation. Yes, people are lazy and want immediate, fast and high-quality results. This scenario is not possible when it comes to writing on Medium.
Lack of confidence
One of my favorites writers on Medium is Jon Westenberg. Not only has he published one of the best articles ever but also somehow manage to deliver high quality, well-written articles every couple of days. When you see such talent on Medium you get to think How can I be more like Jon?
Potential Solutions
As we decided on the problem we will be solving, it was time to find the potential solutions. We each did our individual research on the solutions that are already in the market to get inspired and learn more about the possibilities. Later we performed an exercise where we sketched out 6 different solutions in 60 seconds. It helped us think faster without overthinking our solutions. Later each person picked his or her favorite solution from the 6 sketched solutions and sketched it out in further details similar to a storyboard and pinned it on a white board as shown in the pictures below. Each member took the time to absorb all the ideas and using a sticker we pointed out the ideas that we liked the best. This helped us narrow down to the three best ideas on the board.
Picking the best solution
As we had three good solutions, it was time for us to pick the best solution to prototype and test. Each solution was explained in details and we realized all of them had a lot in common and each solved different problems mentioned above. We sketched out the 3 solutions on the board to find a match between them. They were all focused on the current minimal and beautiful interaction that medium has while solving the issue of pushing a writer from draft phase to sharing phase. The main two interactions they had in common were keeping users in Medium’s platform while they are writing and researching and made it easier to populate articles with rich content in lesser time.
Prototyping
As we moved to the prototyping phase we decided to storyboard our idea to understand the user flow of our product.
Storyboarding helped us understand the different kind of interactions users will have and design them in our prototype to be smooth and easy. We want our users to perform research while writing without leaving the Medium’s editor and so we decided to use medium’s existing user interface and add a tooltip “light bulb” to it which will help people perform research based on their highlighted content. Following is a demo of our first prototype.
The user can select an entity from their paragraph and ask the system for more information on it by clicking on the tooltip. Our system will fetch data on that particular entity from the internet and present it to the user within the editor, the user can either drag the data in her article or save it for later use on the side bar.
Testing the Prototype
Our prototyped product offers information from different online sources.
It was time for us to interview our users and see their reactions. We decided to interview five people and along with that write a medium post to target medium users and gather as much as information possible from different user groups. We had over 2000 reads on our article along with comments and emails encouraging out product. We had a critique session with industry experts and professor who gave us positive and constructive feedback.
Building and iterating
After testing our first prototype we got feedback on the interaction that it was not very smooth because users had to click multiple times to find information. The space used for displaying information was not wide enough for users to scan through it. It could feel intrusive as the information tab was within the editor. We got a lot more feedback and decided to reiterate on the product and build the minimal and most important interaction of it.
We decided to leverage NLP (Natural Language Processing) API to help pre-select the entities in the editor and suggest the kind of data users should looking at while doing research or adding content. It helps users think faster and with more confidence as she will have an assistant with her all the time providing her with good content feedback.
Testing and iterating … again
We did user testing on our second demo and got feedback on various aspects of the product. People wanted it to be an individual product so that they can use it writing for anything. There were concerns about citing the sources. We decided to build our system independent of medium and as a product by itself. We call it Monk, because it allows users to be in a zen mood to write better, faster and efficiently.
“Demo Video coming soon”
Tech stack
We used basic HTML and CSS for our front-end on angular.js framework. We used Node.js to communicate with the backend and we experimented with IBM Watson NLP API and Google NLP API to find our entities.
Lessons learnt
- Users are always right.
- We had multiple crazy ideas which helped us vision a better approach, so no idea is ever too crazy or stupid.
- It is always good to have people from different backgrounds since they all think differently and generate more ideas.
- Planning is very important even for 30 minutes meeting.
- Becomes friends with your team before you start working, it will help in the long run :)
- You can never iterate enough, because you always learn from your mistakes.
Thank you Adam Gavish, Christopher Abi-Aad, Zephyr Liu and Eric Chien for being amazing team member.
Our github repository | We followed The Sprint methods | Our previous post.
Follow me on Twitter or shoot me an email (nisanoshin@gmail.com).
Always looking for feedback and cool projects to work on.
