To be a student means dealing with managing tasks and events for your day-to-day life. While there are many physical and digital solutions out there, it can be overwhelming trying to find a way to balance everything on your plate on top of keeping track of your to-do lists and schedule.
With doc-it, we aim to reduce stress and anxiety by providing a space where important events and tasks can be documented (or doc’d) in the one place that students often spend the most time on: the web browser.
To validate the problem, we interviewed 5 students from various majors and class years.
These were some of our research findings that we found:
Our research majorly in the form of user interviews validated the need for such a tool which is easy to use and students can find all their productivity needs in one app thereby decluttering their online space.
So how do we help students feel more at ease and successful in their daily life while allowing them flexibility? With the data that we collected from user interviews, we narrowed down our scope and started devising a plan to answer this question.
A possible solution is a way to have a centralized place for tasks, calendars, email management, and events where students can see the relevant information with respect to their tasks and is very easy to access for students. Also, the idea would be to have an online tool as most students would spend their time online for their work.
For our solution, we decided we would have just one tab dedicated for all the productivity needs. We wanted to keep the tab simple, straightforward and easy to use so that the users don’t spend time trying to figure out the app. In addition to that, we decided that we would not keep any login requirements for the app to keep things simple.
See below for our final feature list and the value it provides to the users.
After our first iteration of low-fidelity sketches, user testing was conducted on several students. What we found during this iteration was that clarity and visual cues was key in understanding what was happening on the page.
Low-fidelity digital wireframes
All of the feedback was then incorporated into our second iteration of design. Here, we found that students were very clear on how to progress through each task and thought it was straightforward and familiar.
First digital implementation of design
At the same time as testing the low-fidelity digital wireframes, we had also conducted user testing on the first live version of our app. This was a total 180 from the low-fidelity mock-ups test as students felt the “create event” modal was too small, they wished there was some sort of notification or pop-up that alerted the user about deleting an event, and the to-do list entry was confusing to figure out.
Second implementation of design
The second implementation tied the two interfaces together and made it a cohesive page. Once again, we tested again on another student who was vocal about what she liked and didn’t like about the app. For example, she rarely if ever uses a to-do list but is obsessive over her calendar and wanted the ability to hide the to-do list section and make the calendar bigger. She also wished, similar to previous users, that the deleting and updating event actions were more involved processes to make sure she’s not overriding the events on accident.
Final High-fidelity Figma design
This final design incorporated much of the feedback that we received through each of the user tests.
The hardest part came at the end, when we were turning our React project into a Chrome extension. This was not something we had done before, and because our project needed a more complex, non-vanilla React starting template, we had to experiment without the guidance of good tutorials.
For scaling Issues:
Some key developer takeaways are to test everything. Test if your proposed tech stack will work the way your product is planned (e.g. we planned to create a Chrome extension, which does not work with a backend server); test if your designer’s ideas are feasible (i.e. can you code what they designed). And test your MVP on users ASAP. Even if only the design or functionalities part of the MVP is done, test it on people!!
We will continue the development of our app but with lesser bandwidth on the team. As an MVP, the app is designed to be a web app but there’s a huge inclination towards making a chrome extension from the current version as the usability of the app is best suited as an extension.
We learned that every user has their own way of dealing with the app. Some users would like the blue color for their tasks, some won’t. For development of the app there were some difficult decisions made like not integrating the google calendar for now as the app serves as a bridge from using easy local apps like sticky notes to powerful apps like google calendar.
All in all, it’s important to keep the product vision intact and improve the product based on the feedback that you get.
Co.lab experience was very helpful to understand the nitty gritties of being a product manager. It was also very much validating for me as a career choice. My top two learnings are:
Being able to work together as an actual team was the most important takeaway from the Co.Lab experience. I’ve worked at start-ups where my role as a designer was talking to myself, consulting people who weren’t necessarily the right person to talk to and it felt so lonely and like I was on the wrong path. Collaborating on a product from start to finish and having that open communication along the way with Amit, our PM, and Long and Hugh, our developers, really reignited my passion for designing.
I had the chance to truly Co.Lab(orate) with my group, I had never experienced this level of involvement, communication, and teamwork before. It was a pleasure to work with my group because everyone was so invested in our project, as well as being able to learn from everyone and grow in our respective roles.
It is a great experience to learn how to work a development team, collaborate with product manager, designer, and other developers. Then, I learned a lot in project management, for example, how to make a whole project into many small tasks, and arrange the estimated time and assignee for each task.
Many of us were working in a team developing a product end to end for the very first time and it was an enriching experience knowing how the product progresses over time with inputs from various stakeholders.