A Better Way To Journal

Journaling can be a strenuous endeavor, especially if you don’t have the time or discipline to commit to it every day. Frustrated by the lack of physical and digital platforms to facilitate the process, I designed a solution that could help others like me make the preservation of personal memories a daily habit without the unnecessarily cumbersome qualities of traditional journaling. Daily Log is an iOS application that accomplishes this by both streamlining the writing process and instituting a design that effortlessly organizes entries based on various categories.

Research

I began my research under the assumption that individuals were frustrated by the indelible aspect of journaling and sought a way in which they could design their journals without the stress of making errors in the process. During the interview phase of seventy-eight individuals conducted both in person and via an online survey, I generated a series of questions that focused on past experiences with journaling and the different topics individuals were inclined to write about.

The results of the interview phase indicated that the majority of individuals were more concerned about the time commitment and dedication required to maintain a daily journal than they were about the design aspect. After sorting through the most common pain points, I developed a set of personas to refer back to throughout the project as a way of ensuring that I consistently maintained a clear idea of the individuals for whom I was designing this app.

Brainstorming/Sketching

With a fuller understanding of the problem, I dedicated a physical notebook to record the iterative process and to sketch out potential solutions in real time, which was immensely helpful in validating my assumptions and gauging interest in the solutions I proposed. This method ultimately enabled me to extract the best parts of physical journals and then translate them into a design suitable for mobile devices.

Low-Fidelity Wireframes

During the initial phases of the design process, I recognized that not every sketch translates successfully to a digital interface and that there were limitations to some of my proposed solutions. For one, I was admittedly too hasty in displaying my prototype, creating confusion; not all aspects were clear, requiring me to explain “what should have been there” for a number of elements in the prototype. Yet, the feedback I received was valuable in modifying an improved design for the medium-fidelity prototype of the app.

Medium-Fidelity Wireframes

In this phase, I took the feedback from my initial user tests and revised the app’s design accordingly. However, despite the medium-fidelity prototype resembling the finished product, there remained still a few points of confusion, most notably concerning the icons because I placed too great an emphasis on designing aesthetically appealing UI elements, thereby hindering the effectiveness and overall clarity of the app. Further, in pursuit of creating a unique interface, I adopted some unconventional design elements, which caused hiccups in the flow of navigating through the app.

Up to this point, the design was divided into four parts: current entries (the Present), past entries (the Past), to-do lists (the Future), and a screen for creating new entries. User interviews revealed that individuals were less enthusiastic about the to-do list aspect given other apps facilitating this function. Recognizing that it was unnecessary to add features that were cluttering the overall design, I opted to streamline aspects of the app by refocusing on a utilizable design best for journaling entries.

Final Design

In the finishing stages, I was dedicated to refining every aspect of the design, evaluating all possible user flows in order to assure they were as clear and fluid as possible. I used two overarching criteria to measure the success of the final design. The first criteria concerned whether a sizeable majority of user testers were able to independently navigate through the app and whether they were able to intuitively assess its functionality. The second criteria gauged the general public interest.

To view a working prototype of the application’s main flows, including those featured below, click here.

Concluding Thoughts

The aim of this project was to challenge myself to design an application that solved a real-world problem. Although feedback from my user tests suggest that I am heading in the right direction, I cannot be fully certain about the solution’s success until I have a functional prototype. Below are a few takeaways from this project that I will use as a guide for future endeavors: 

• Function over form, always: During the initial design phase of this project, I was fixated on creating aesthetically appealing screens at the expense of functionality. Taking the time to iterate on my designs enabled me to realize that flashy designs don’t necessarily make for a better product.

• Don’t test unfinished prototypes: With every project I work on, receiving feedback is paramount. However, asking for feedback on unfinished prototypes proved to be unproductive. I learned that I should not ask people testing an app to use their imagination in regards to UI elements “that should be there.” 

• Don’t dwell on sketches: Sketching designs on paper is a great way to rapidly iterate ideas, but not every sketch translates well when recreated digitally. I’m working on striking the right balance between time spent sketching and creating digital mockups.

• There’s no shame in using premade assets: At various stages of the process, I felt the need to create every UI asset from scratch. This time consuming endeavor could have been better spent focusing on other aspects of the application. I learned that not only is there no shame in using premade assets, but that it’s also often crucial for ensuring that screens get completed in a timely fashion.

If you are interested in this project and would like to hear more about it, feel free to drop me a line at timothywelman@icloud.com.