I'm over Instagram.

For photographers like me, it just doesn't work. Whether you have 5 followers or 500,000, it’s not a place for photographers looking to share their work with a community of thoughtful, engaged people.

Worse, it creates a toxic treadmill of insecurity and self-doubt by encouraging us to focus on follower counts, hearts and worthless comments. I’ve been there, obsessing over follows and likes. It’s not a good place to be.

My goal isn’t to gain thousands of followers and become some kind of social media king. I'm actually looking for ways to get better at my craft.

I know how hard it is to learn to make better pictures on my own. I believe that getting consistent, regular feedback (and thinking critically about other’s work) is the quickest way to make great photographs.

I'm designing and building a new app for photographers to get better feedback on their work.

Project log

Watch the app being built in real time.
The last entry was 3 days ago.
Day 92
Respect the Spec

You know what was a nice smell? Paper, right after your teacher handed out the daily reading she forgot to Xerox until right before class started. It was nice and warm and vaguely...yeasty? And speaking of warm reading—I've got a fresh spec for you, hot off the press.

Spec - v0.1
Open on Notion >

I've seen specs done in as many ways as product teams I've ever worked with, and that's fine. The utility of a spec is to act as a record of agreement between stakeholders. If they need to be long and full of detail...that's fine. If they can be short and punchy...great. What they absolutely have to be is exacting enough for agreement to be meaningful.

As a designer, specs from product managers are often a source of distain. Bad specs can be too prescriptive (ex. "put a blue button on this page"). Or they can fail to articulate the goals with enough resolution to be actionable (ex. "we're building this feature because...it's on the roadmap"). Often bad specs are guilty of both. Bad specs don't leave enough room for a designer to do their job.

In this case, the spec here is an attempt to bring together everything I've learned in the last couple months and mold it into something I can communicate as a complete product. I've tried to be specific about the mechanisms of the app (ex. specifying a group of 5-10 reviewers) without being prescriptive as to implementation, but those kind of bright lines are hard to find in reality.

I've also sketched some storyboards for the core review process that the spec describes. These aren't wireframes—they're intended to tell the story at a higher level. The "UI" that's drawn is purely representational. The fidelity is absurdly low just like the hokey UI created for movies. Like in Jurassic Park, Lex has to navigate the 3D "Unix" interface to reactivate the security system.

This storyboard is simple, but communicating a user "flow" like this forces you to think beyond the screen. I'd like to see more feature specs include stuff like this. We can get so buried in numbers and charts and slide decks that we forget that what we build has to work first and foremost as a story.

Storyboard Spec
Requesting feedback • View full size

UPDATE: Bobby Ghoshal (@ghoshal) pointed out that the goals aren't stated in a way that's measurable. I've updated the spec in Notion to reflect his suggestions.

subscribe plz
my imageThanks! Let's talk soon.
Sliding into your inbox
Project updates, sent every few weeks. No spam.
Day 83
UX interviewing with my baby
Baby duty can't stop me from doing some down and dirrrty street research

Where I live, in New York City, a lot of people don't have kids because they're focused on their careers and doing boozy brunch on the weekends with their French bulldog Chad.

I don't blame them—having a kid is tough. I thought I had worked out a time over the weekend to get feedback on the two app concepts I designed. I had it all set up with my buddy Tiago, but I forgot I was on baby duty all weekend.

One thing about having a full time job and a kid and designing and building an app on the side—I'm learning to be more flexible. To roll with the dirty diapers, so to speak. So I went for it. Watch below.

What did I learn?

Despite having an adorable cherub strapped to me like a bomb vest, I had a hard time getting people to talk to me. New Yorkers know better than to engage weirdos on the street. And a NYC sidewalk has to rank as one of the most distracting environments on Earth, even without a fussy baby. It's not an ideal place to get people to focus enough to engage and be thoughtful.

Even under the circumstances, the fake brochure pages worked as provocations. Everybody seemed to grok the idea of the app pretty quickly, and when I asked which one they were more excited about, I received resolute answers, except from those two women (who may have been drunk).

But you only talked to a handful of people!

The goal with design research like this isn't to extrapolate conclusions. It's deeper than graphs and numbers and sample sizes. It's like musicians jamming. I'm trying to build shape around the problem.

I think this mostly concludes the research phase of this project. The next post will be a recap and summary of everything I learned and what's next. Stay tuned.

Day 73
Kyle Bragger on the demise of Forrst
Kyle shares his first-hand insights on the challenges of building an online community

Kyle Bragger was kind enough to answer a few question I had about Forrst, a feedback community for designers and developers that launched around 2009. Here's what he had to say:

What were the biggest community challenges?

KB: Probably a combination of keeping things focused, and balancing the membership growth with community growth. Things felt like they got off the rails from time to time in terms of the overall goal of the community, especially with people coming in and using it as though it were Dribbble etc. (i.e. posting low context previews of work) — it didn't give a lot to go on in terms of other people being able to give actionable feedback and critique. And with membership/community growth, as it was invite only, that naturally meant the community had room to breathe and grow somewhat organically, and generally (at least at first) kept the quality of membership high, but also mean that often people who should be members weren't.

What were the common reasons people stopped using it?

KB: Probably a decline in the quality of the community. Many factors were at play, some folks thinking it was just a Dribbble clone and treating it as such, a skew of membership towards much younger people who weren't interested or able to participate and provide critique/help to others for various reasons, my eventual departure, etc.

How important was the gatekeeping aspect (i.e. the invite system)?

KB: I think it was responsible for the overall quality & longevity of the community. It wasn't perfect but I think flooding the gates, to to speak, would have meant a lot more noise and self-serving posts.

If you were to start something like Forrst again, what would you do differently?

KB: Probably not do it. :-) It was a great experience but I'm not sure I have the mental bandwidth to attempt to foster that kind of community again. I do have thoughts here and there about other ways I can build things which are helpful to our industry at large, but I'm not sure a feedback community is on that list any more.

You can find out more about Kyle on his website or on Twitter.