Where I’ve been for eleven weeks, and what this newsletter is going to be about now

Hi there 👋

It’s been eleven weeks since my last issue, which is about ten weeks longer than I planned. I’d like to explain where I went, what I learned while I was away, and what you can expect from this newsletter from now on. It won’t take long, I promise.

In case you’ve forgotten why you subscribed

It’s been a while, so let me reintroduce myself. I’m Balint, and I’m a product designer. I’ve spent the last six years or so designing mobile apps and web platforms, mostly in fintech, and lately I’ve also been building a product of my own, which I’ll tell you about in a minute.

You probably subscribed after a LinkedIn post, one of my design articles or my free guide, The Psychology Behind Design. Whichever it was, thank you for still being here after eleven quiet weeks.

Where I went

For most of this year, I’ve been building Brisk, a tool that helps freelancers with everything around the actual work: the agreement, the hours and getting paid.

It started with a pattern I kept seeing, in my own freelance work and in my friends’. The work itself was rarely the problem. The trouble happened around it, and almost always in one of three places.

The first is before the project starts, when a “sounds good” in an email is often the only agreement. So clients can sign a contract online, and a deposit invoice can follow.

The second is during the work, when hours get rebuilt from memory and some never get billed. So I added time tracking that turns your hours into an invoice.

The third is after the work, when you send the invoice, hear nothing and start drafting the “just checking in” email. So Brisk sends the reminders for you and shows when a client has opened the invoice.

Building those three things looked simple on a whiteboard. Making them work in real life was the hard part, and it’s the part nobody ever sees on a landing page.

Every feature turned out to have a dozen scenarios hiding behind the happy path. Each of them needed a decision, and most of them needed a screen or a message that almost nobody will see unless something goes slightly wrong.

Then there were the bugs, which always seem to be found by a real person at eleven at night rather than by me during testing. A lot of my week went into turning a message like “it’s not working” into a screenshot, a few steps to reproduce it and a clear question for the developer. I learned more about writing for developers in those months than in years of handoffs. A good bug report and a good design spec turned out to be almost the same thing: what should happen, what happens instead, and why it matters to the person using it.

And then there were the users themselves. Every message was useful, and almost every one pulled me in a slightly different direction. A few of them changed what I worked on the very next morning. Many more taught me that what someone asks for is rarely exactly what they need, and that the real work is in the follow-up question.

There was a little more of it every week, and every Thursday something felt more urgent than writing to you. I never decided to stop the newsletter. It just kept losing.

I’m proud of what came out of those weeks, and Brisk will come up here from time to time, whenever building it teaches me something that’s useful to you as a designer. It won’t turn this newsletter into product updates, though. If you freelance and you’re curious, you can try Brisk for free, and I’d love to hear what you think.

What I learned when nobody gave me a brief

Looking back, the product wasn’t the most interesting part of those weeks. The most interesting part was what happened to me as a designer when the usual frame around the work disappeared.

For my whole career, someone else had shaped the work around me. There was a brief, a product manager, a weekly review, a deadline and somebody who eventually said “this is ready, ship it”. On my own, none of that existed. I could spend a day on contracts, the next on what a reminder should do after a client has paid and the one after that on a single empty state, and still go to bed not knowing whether I’d worked on the right thing.

Without that frame, three things about the job became very obvious to me.

The first was how much of my perfectionism was really fear. Some days I was improving a design because it genuinely needed another pass. Other days I was improving it because shipping it meant that someone else would get to decide whether it was any good. From the outside, those two kinds of days looked exactly the same. The second kind just involved a suspicious amount of adjusting things nobody had asked me to change, and for me it was almost always the spacing.

The second was that writing things down is how I find out whether I understand them. I started writing short notes about why each feature existed, mostly so I’d have something to share. They ended up being far more useful to me than to anyone reading them. When I couldn’t explain a decision in a few sentences, it usually meant I didn’t understand the problem yet, and it was much cheaper to find that out in a note than in a finished design.

The third was how much easier it is to make things than to tell people about them. I could spend a whole week building something and then struggle to spend twenty minutes explaining that it existed. I used to think that was a founder problem, but I now think it’s a designer problem too. We’re very good at making the work, and much less good at making sure the right people understand what we did and why it mattered.

None of these lessons are about tools, and none of them only apply to building a product of your own. They’re about what it’s like to be a person doing this job, which brings me to the last part.

What this newsletter is going to be about now

When I sat down to write again, I noticed that the things I most wanted to write about weren’t trends or tools. They were the human side of the job: the feedback that stings and the feedback that helps, the meetings, the conversations with developers and managers, the confidence that comes and goes, and the weeks when nobody tells you whether your work is any good.

So that’s what this newsletter will be about from now on. Every two weeks, I’ll send you one honest piece about what it’s really like to work as a designer, with a hand-drawn illustration and as little jargon as I can manage. Some issues will be stories, some will be guides, and a few will probably be silly. I’ll also end each one with a few things I liked that week, which might be a tool, something I read or a place I went.

If that sounds useful, I’m very glad you’re here. If it doesn’t, I completely understand, and the unsubscribe link is at the bottom with no hard feelings.

I’d love your help with one thing before the next issue.

What’s one part of the job you wish someone wrote about more honestly? Just reply to this email. I read every answer, and the best ones will become future issues.

In case you missed them

If you’re new here, or you’ve just forgotten what I used to write about, these are the issues readers liked most before the break.

The next five years of product design asks five questions that will shape what it means to be a designer through 2030. It’s by far the most read and shared thing I’ve written.

Why design reviews waste time is about how vague feedback quietly kills good work, and what to ask for instead.

The soft parts of design is about the skills that actually get designers promoted, none of which have anything to do with Figma.

Why agency matters more than any skill on your resume argues that the people who shape the next decade won’t be the most skilled ones, but the ones who see something broken and just go and fix it.

Stop designing before you understand the problem is about why most design work starts too early, and why the best work starts with questions.

You’ll notice that most of them are already about the human side of the job, which is probably the clearest sign that I’m heading in the right direction.

Thanks for reading Balint’s Newsletter! Subscribe for free to receive new posts and support my work.

Things I liked this week

🖼️ A portfolio: Rachel Chen. I’m in love with how she presents herself and her work: one honest line about who she is, then a short list of projects, each labeled as shipped, concept or contract. It’s the format I’d move my own portfolio to.

🎧 A listen: An 86-minute guide to finding PMF. Rob Snyder's PULL framework asks whether the thing you're working on is something people urgently need and can't get elsewhere, which is a good question for any designer to ask before polishing a screen.

Thanks for reading :) If something in this issue resonated, please reply and tell me.

Even one line. These replies are my favorite part of writing this newsletter.

See you next Thursday 🙌

— Balint

Thanks for reading Balint’s Newsletter! Subscribe for free to receive new posts and support my work.