The Team
A quick bit of context
SimpleTasks started with a simple frustration. A developer friend of
mine
wanted a clean, no-nonsense way to manage his personal tasks - nothing built for teams, nothing
bloated with features he'd never use. He decided to build it himself and open-source it so
others
dealing with the same problem could use it too.
I joined as the solo UX/UI designer. My job was to design the entire product from scratch -
research, flows, components, high-fidelity screens - working alongside two developers on a tool
that
needed to feel effortlessly simple without being dumbed down.
This case study focuses on one specific challenge within that project: how do you make creating a lot of tasks as fast as possible?
The problem worth obsessing over
Early in the process, our research kept surfacing the same
frustration: people abandon task managers not because they stop caring about their tasks, but
because the act of entering those tasks becomes a chore in itself. You open the app with 10
things in your head, and by the time you've filled out the third form - title, size, priority,
tags, confirm - you've lost the thread.
This gave us a clear product goal that went beyond "make it look clean": we needed a way for
users to offload their entire brain in one sitting, with as little friction as
possible.
The standard task creation flow I had already designed was solid. It followed familiar patterns, included only the essentials, and worked well for adding a single task. But it wasn't built for volume. Creating 10 tasks one at a time still meant 10 separate interactions.
So we asked: what would it look like to create 10 tasks at once?
Some ideas we rejected
One of the “faster” concepts I designed was to give the users the
ability to write their tasks directly on a card on the board without the necessity of opening a
modal. Trello uses a similar approach, but I decided to add the option to also add tags right on
the card.
However, we agreed that this is not the solution we are looking for, because this would still
require users to click a button every time they want to add another card and they would still
need to open a separate window if they wish to include more details such as description,
priority, etc.
Cramping all these as options directly in each card didn’t feel like the right solution either.
We needed something more radical than a faster form.
An older version of the task manager main screen while testing the look of the concept
The idea that changed the direction
The answer came from our lead developer, not from me - and that's
worth saying, because good product ideas don't care about job titles. His proposal: let users
write tasks like they're jotting down notes, using a simple bullet-point syntax that
gets parsed
into fully formed task cards automatically.
Instead of filling out a form, you open a blank canvas, write freely, and hit "Create tasks."
Each top-level bullet becomes a task. Sub-bullets carry the optional details - description, size
(XS/S/M/L/XL), priority (P1/P2/P3), and tags. My job was to figure out how to make that idea
actually work as a designed experience.
The very first draft of the fast task creation feature
The design challenge: a blank page is intimidating
The feature lives in a modal. When you open it, you see a large blank text area and two buttons. Intentionally minimal. But that immediately raised a real question: if someone has never used this before, how do they know what to do?
The syntax has a learning curve. It's not complicated, but it's not
self-evident either. A blank page with no guidance would leave new users stranded.
My first approach was to add a help icon in the top right that would
open up instructions in the
sidebar. That worked, but only temporarily.
The two buttons are moved to the bottom and a help icon with instructions is added.
I also designed a live preview panel - as you write, you see your tasks taking shape as actual task cards on the right side of the screen. This felt important because the syntax is abstract and seeing the visual output in real time makes it much easier to understand what you're building and catch mistakes before you commit.
This is how the feature looks with the preview on the side
And that’s where the problem occured: the instructions panel and the preview panel were designed to live in the same place. This meant that a user can see only one of the two at a time, which wouldn’t be an issue if a person knows how to use the tool, but what about when people want to have the instructions visible at all times as they type? (which actually seemed like a very possible use case)
How I resolved it
The solution was to make the help panel togglable inside the text
area itself via the help icon, while keeping the preview panel as the default right-side
content.
The reasoning was straightforward once I framed it this way: the preview is useful every time
you use the feature. The instructions are only useful until you've learned the syntax. So the
preview earns the permanent real estate, and the instructions are one tap away when needed, and
completely invisible when not.
To further reduce the learning curve, I also added ghost placeholder
text inside the writing area - a subtle visual example of the syntax that disappears the moment
you start typing. New users see immediately what format is expected without having to open the
help panel at all.
The result is a layered onboarding experience: placeholder text gets you started, the preview
panel shows you what you're building in real time, and the help panel is there as a fallback if
you need a fuller explanation.
What the final experience looks like
Open the modal, see the ghost placeholder showing you exactly how to write your first task. Start typing and the preview panel populates live on the right, showing each bullet transforming into a real task card. If you need a reminder of the full syntax, tap the help icon. When you're ready, one click creates everything at once.
For a user with 10 tasks in their head, this goes from 10 separate form interactions to one continuous writing session. It's not perfect - the syntax still has friction we haven't fully solved. But it ships, it works, and it's meaningfully faster than anything else we considered. Sometimes that's exactly the right place to stop.
