I spent nearly five years learning from and leading the design team at Flickr, a role that allowed me to wade into the thick of everything from the highest level product strategy to the finest details of our work. Engineering, design, product, and all of the teams at Flickr spent a lot of time involved in all of the strata between those levels—at some points building things more effectively than others. Over the years some bits of the early culture evolved as the product grew, while the foundation of inclusion, transparency, and merit-based decision-making mostly just got stronger. A few significant lessons we learned prepared the team for our big redesign in May 2013 (a story for another time).

Ship Often

(but not too often)

One of the great strengths of Flickr’s culture is the emphasis on continuous deployment. Even after 10 years the team deploys code into production at least 10x/day on average! Which is amazing, and comes with tremendous benefits. Every engineer and some designers could push changes to a 100-million-strong community with relative ease (but never without care, of course). This system, combined with passion and a desire to experiment, comes with some down sides, too. We often shipped small features that our community mostly didn’t notice while also hearing that we weren’t changing enough. The lesson here is that each thing when its done is often less powerful than combining a few things into a cohesive statement.

1. Think about the story of what you’re launching — Is it compelling enough to achieve / exceed your desired results? Think about sequencing of releases as well as contents of each individual launch, how they’ll be experienced in context with each other.
2. Group small releases to achieve larger, more coherent impact for each push. Ideally your community understands you’re doing things deliberately andof where you’re headed, rather than just seeing (or missing) a minor tweak.
3. Make change a normal part of product experience for the community. Aim for the Goldilocks area between too little to notice and infrequent huge disruptions.
4. Plan on big redesigns. Start redesigning before it’s urgent, continue evolutionary projects to test while working on the big change.

Empathy + Opportunity

Prioritize empathy with community, team, and stakeholders; then present opportunities.

Don’t limit design to what stakeholders ask for. Build what they need, what will delight, what will maximize their experience.

Flickr users didn’t (directly) ask for most of what we built when we redesigned the product. It was critical that we knew their needs — and how they could use our product beyond what they currently knew — for us to create experiences that inspired new levels of enjoyment and engagement.

Tired but true: “If I had asked my customers what they wanted they would have said a faster horse.” — dubiously by Henry Ford

Bigger Photos! was the #1 goal from our community, leaders, and execs. That request is far from a definition of an experience that matched the potential of Flickr. We explored and ended up using giant photos as the key vessel for nearly all content on Flickr. The team replaced white space and typography, the old Flickr design language, with large photos as “containers” for text, metadata, and interactions. If we’d followed directions we would have ended up much closer to the old Flickr. We would have missed our potential.