3 ms·
One example of what I'm thinking of is the tarsnap website. Nothing fancy, and Colin mentioned in a blog post he'd rather get the code for his product right fir
by m0nty 18y ago
One example of what I'm thinking of is the tarsnap website. Nothing fancy, and Colin mentioned in a blog post he'd rather get the code for his product right first (and from what I've seen it's good stuff) then work on the website. So sure, if you're an interaction designer you have to do the Right Thing. But it's easy to get paralyzed in the face of what looks like an overwhelming task when you should just pitch in, accept you're going to f*ck up to some extent, then rework it.
I failed a project last year through being too perfectionistic, so I'm trying to retrain myself not to be. Frankly, my standards were much higher than the clients' and I could have done half the work and been much more successful.
- ahoyhere 18y ago> accept you're going to f*ck up to some extent, then rework it. Oh, I'm totally with you. My app is far from finished. The settings area still sux. And we use lightbox-style overlays in a few places and I hate those suckers. And there's a lot more that I want to do with it, like, NOW. But we did ship on the day we said we would. :) The main reason we were able to do that was to first identify which missing "killer features" would not be apparent to people other than us. We, of course, had the perfect 2-years-down-the-road mental image of our project. We could never ship that. But other people, coming to the app as newbs, would not know that we managed not to include <killer feature here>. Then we ruthlessly qualified things as "good enough." I can't tell you how many times I said "Eh, fuck. Just ship it. We can make it better later." I just wouldn't compromise on data entry. That's the whole point of the app. Then again, we didn't compromise on what we had, BUT we did leave out the other entry mode (still working on the design, a month later). So...