kowitz

Hi there. I worked on this launch. Designing for Slack had a difficult learning curve and I wanted to share some of what I learned along the way.

Here's a twitter thread I wrote this morning with about a dozen tips that I wish I knew before starting to build a Slack app: https://twitter.com/kowitz/status/1285254103354859520

One of the most rewarding things I've learned in the past few years has been how much better work can be when you really get to know your co-workers. Our team uses a team-question like this to start every day and it's helped us tremendously.

A startup is a rollercoaster. I totally feel it: the ups and downs. The healthiest way to cope with that volatility is to build a bedrock of trust between the founders and the rest of the team.

It might seem silly, but doing the work of asking and answering questions like these are the best way I know to develop trust.

I wrote this to share some methods that I've found to be helpful for the startups that I work with.

What do you think? I'd love to know where others have found value in "launch hand learn" vs. other quicker methods.

I wrote this article because I've seen the many ways that user experience methods can contribute to lean startups. Launching is a good technique for learning. But I've seen many quicker, scrappier methods work great, though they're often overlooked.

I hear from startups all the time that they're struggling to find participants for user studies. You can only recruit your friends or hang out a the local Starbucks a few times before you start wishing for better participants, and better data.

Michael outlines the process here that I've seen work well for dozens of user studies that we've done together. Hopefully it'll work for you too.

I hope you like the article. I'm interested in how similar/different this is from engineering interviews.

So I've been thinking about this more since yesterday. I think some people misunderstood me and thought I was saying that pixel-perfect and polished designs are always necessary. They're not. Sometimes fast and sloppy UIs are what you need to build in order to learn the fastest, and eventually get to a better product. (Sometimes misaligned elements and odd typography gets the brand tone just right, like on hacker news.)

The part I haven't quite figured out how to think about yet, is how teams decide how much the details matter. How do you know when the fit and finish is good enough? I'm not sure. I do think though that as products are competing more on experience (easier, more delightful, focused, etc), that the details will matter more than they ever have in the past.