Part 2 — Prototype one retrospective
Bridging the gap between dream and reality
Dreaming up great designs is one thing. Making them a reality is quite something different. This post is the second in a series of behavior driven design to build a to-do app that actually help you get things done.
The first post focused on the problem and how most to-do apps don’t really help you to get things done. It is mostly simply a digital note taking app, sometimes with annoying reminders. But there’s little in these apps to help you actually change behaviors, which is the problem I want to solve in my app design for done.
To recap, the designs are aimed to be very simple, without any clutter to keep you focused on what’s most important right now.
The next step highlighted in the first post was to write a few applications as a first round of prototypes based on tutorials (which is how I best learn). This post is the result of the first tutorial with the aim to see what’s possible technically and adapt the designs accordingly.
The most fitting tutorial I could find was a collaboration between Kevin Powell, who focused on the styling and layout in this tutorial, and Kyle from Web Dev Simplified, who then added the functionality to make the static screens work in a follow-up tutorial.
After following the two tutorials, I had my first prototype to evaluate!
I had a very simple app that allowed me to easily add a list or task simply start typing and pressing enter. Completing a task is as easy, and dynamically updates a counter at the top and visually gives feedback on the task.
Why start here?
The reason why I chose this tutorial was that the design most closely fits with the core elements I have in mind, even though it looks quite different from my designs.
What is most important to me is understanding how complicated it is to create separate lists in one app, dynamically update counters to display in a dashboard, and have a simple design that doesn’t require authentication or registration in order to get started.
O, and I really like how Kyle runs through the logic as he changes the code which makes it easy to learn, and I enjoy how Kevin always aims to stay on top of the newest CSS trends.
I also enjoy how it is beginner friendly while feeling as if I have done something substantial.
Let me run you through my experience in the development process.
The first part of the tutorial takes an existing design and then builds the framework (html) and styles it (CSS) as a static page. This is an area I am pretty comfortable with (although still a beginner) yet, I still feel I learned a lot of valuable tools following the tutorial.
Here are the most valuable lessons I took from the tutorials, and the process of creation in general:
1. Design first
I am a visual thinker. I also clarify ideas by being able to see them. It is hard for me to do a complete design upfront and I strongly believe in an iterative approach. When I started learning web development, however, I didn’t place as much value in a design as I do now.
Having a design as a reference serves as an architectural blueprint to know which rooms will go where, where you will need plumbing, and how to style the interior.
2. Include resets
In order to sit with less problems later on, it is useful to add a styling reset that resets all margins, fonts, and other settings that might impact your specific design.
Here is a good example of a CSS reset by Josh Comeau that explains why specific CSS is added in different places as a starting point, which I found super useful.
3. One perspective at a time
Another extremely valuable lesson I learned by working with a really great designer, was the importance of focusing on one perspective at a time. Raza Khan from ThinSeed mentored me through a process of design and in our different sessions added layers of complexity one step at a time. He first focused on the content, then the styling and finally putting it all together.
The way the tutorials are split between the styling and structure, and the functionality, adds to the concept of focusing on one perspective at a time. This makes it easier to consume the information.
After building the prototype I used it for a few weeks to critically look at what I liked and what could be better. Here are the main lessons.
1.No registration or login required
One of my pet hates is having to sign up and remember yet another password for an app I’m just curious to look at. I see registration and logging in as a barrier to entry.
So I loved that I didn’t have to sign up or have to worry about installing anything. I could just get started straight away.
2.Locally stored cache
As long as you don’t clear your cookies or use a different browser or device, your progress will be remembered without an issue.
I also really like having it as a web app rather than a mobile app as I mainly use a laptop.
3.Visual feedback on done items
I really like the visual styling when clicking an item as done. It animates a strike through line through the task and marks the bullet point in a clearly highlighted orange color (see image below).
The number of remaining tasks in the top banner also updates to only show the remaining tasks.
What could be better
Every masterpiece that has ever been made, could be better. Here’s what I wished I had that wasn’t in this first prototype.
Accessibility to me means the ability to access something. This of course includes concepts like contrast, catering for screen readers, etc. But even more fundamental is finding something when you want to use it.
The designs don’t cater for saving or bookmarking the page for easier access and relies on the user knowing how to find it.
2.Not able to edit lists and tasks
A basic feature that I found to be missing is the ability to edit list and task names. The only way to edit an item is to delete it and add a new item. This is definitely something that needs to be added in the next iteration.
3.Nested list handling
In principle I like the idea of two layers to handle the tasks and lists. In practice, however, I found this confusing and somewhat frustrating. An accordion could potentially be more useful to keep context in a nested list.
Although there is feedback to highlight the selected list, I still found it confusing to figure out which task is where and an unnecessarily amount of extra clicks to get my task or list.
It’s also not possible to complete a list, only tasks, which I find reduces the feeling of progress towards your goal. And I’ve spent the past few years trying to think smaller and create tasks that can be done in small increments which is an XP practice that I find really useful.
This validated my designs where I have separate lists rather than nested lists. Rather than adding a layer of complexity to try to simplify the layout, I focus on only the most important items and keep the rest all accessible in a different list in a Kanban like board.
The immediate next steps is to update the designs to incorporate the feedback and add desktop designs.
I also want to find another tutorial with different designs and functionality to compare and expand my technical skills.
Part 1 — Behavior driven design looks at an initial design and the problem with existing to do apps.
Part 2 — Prototype one retrospective (this post) takes a first step to build a prototype and critically re-evaluate the initial designs.