I’ve always understood one reason why development-led products turn out the way they do (bad): developers get excited by making something work. That’s the payoff. Once it works, the motivation for everything else dries up.
Building Tootbox, I’ve realised another reason: developers think in data. When you’re looking at database fields and need to design a way for users to fill them, the easy way out is a form that maps inputs 1:1 with those fields. This makes for a very uninspired UI.
The first iteration of Tootbox fell into this trap. I don’t normally need to concern myself much with how data is stored, freeing me to think more about the best experience rather than the path of least resistance from data entry to storage. Designing as I coded, though, I became lazy.
“Toots will have text. We’ll need a text area. Toots will have dates. We’ll need a date input.” It’s not hard to see how slippery that slope is. I ended up with a very plain list, button, and form.
I once read that almost all software is just displaying lists of items. This is true. Think about Twitter; you follow a list of users, those users have lists of tweets, and those tweets have lists of likes. It’s lists all the way down.
Developing an app that allows users to add to lists and then displaying those lists back to them isn’t hard — at least not at first. And because it’s not very hard, everything else about making the product successful gets more difficult. What’s the angle? How is it different than the next thing? Messaging, marketing, and design are key differentiators. The only real difference between Goodreads and Letterboxd is the niches they’ve chosen.
This all hit me the past two weeks as I focused on getting the Tootbox MVP launch-ready. My realisation was that nobody will log in to Tootbox to fill out a form. They’ll come for one of two reasons:
- Something — an external trigger — has made them feel good and they want to capture and store it, either in text, an image, or both. This is the primary, more common action.
- They want to reference the things they’ve already stored. They’ll do this less frequently, when they need that evidence to support something like a job search or annual review, or maybe just need a confidence boost.
Why, then, is the “New toot” button just tucked away in the top-right corner? That should be a big, inviting CTA front and centre. Maybe there’s a text input right at the top of the page. Since the focus of a toot can be primarily text (like a journal-type note) or primary imagery (like a screenshot of a message or some statistics), maybe there are two big buttons for writing a new toot or uploading an image. All of these inputs could carry over and be pre-filled in the full “new toot” form.
I’ll also need to consider lowering the friction in the way of users inputting just the fields they want to use. Right now, they have to add text and a date. They can optionally add a big emoji, images, tags, and links. On the frontend, all of these fields are created equal — all normal inputs on the form, visible by default. Maybe I can keep an eye on stats for which ones are used and experiment with deemphasising some of them behind a “more options” type toggle. (That could also be a self-fulfilling prophecy. Hide the tags feature and all of a sudden usage plummets.)
Anyway, that’s my upcoming challenge. Making data entry more fun.