Hey everyone, trying to write a bit more this year :)
I hope this is meaningful to some of you!
Thanks for putting so much thought into your writing, Joel. I especially liked where you talk about design as a team sport—welcoming old ideas, embracing the work from your partners (I want to steal your PM's idea of the timeline.) And I loved your reference to Carl Sagan.
Don't stop writing.
Loved this one like the earlier ones too. There's a lack of content around team dynamics, getting buy-in, and driving change as a team (not as an individual). This one really hit home.
Great write-up Joel!
I recently joined a company that practices Scrum and agile development, and it has changed how I look at software design/development. I almost exclusively work on features in parallel with our developers, and they all go live. We work in tiny increments, which means we will release each of those increments and see what happens. Did it have the effect we'd hoped? If not, we evaluate why and either kill the feature or make it better. If yes, we keep improving on this feature until it is no longer worth the effort. This means that we never have months of work that goes untested on the assumption that it will solve the problem we have.
I'm thinking about writing a piece on working in a cross-functional agile team as a designer, I think a lot of us are still struggling with the waterfall methods that burden our industry.
Unfortunately agile design/development is harder to do than most project managers realize. In my experience it often turns into a bunch of small waterfalls rather than designers and developers truly working in parallel. How does your company avoid that pitfall?
Also to what level of detail do you spec out a feature before designing/developing it? I found we were over-speccing features and project managers were expecting designs to be pixel-perfect reflections of that spec to be handed to developers, rather than an evolving document.
You should definitely write that!
For what it's worth, when you're working on bigger leaps, it's not always straightforward to break them into small, shippable (and testable) chunks.
That said, it's definitely better to validate things early on, and not having done that on this specific project was a failure that we've learned from :)
This is a great read, thank you for this perspective!
Would love a bit more info about how you document everything on Github. I would love to go back into a timeline of an idea and how it was discussed etc.
I'll dive into it at some point :) Sign up for the newsletter if you haven't already. I'm planning on sending stuff out that wouldn't work as a full essay.
I wouldn't hold it against any designer showcasing work that they were proud of that was ultimately cut. I mean... their ENTIRE portfolio shouldn't consist of these types of projects. But one or two? What's the drawback?
How do you feel about putting work that wasn't shipped into your portfolio? What about larger projects that saw some of your work shipped but some not? Is it only valid if it made it to production? If the process was sound and the final design a good solution, is that enough? What if some things were slated for production but then [something happened] and development was stopped.
This is a great conversation, and I think I'll write about it some day, maybe in my newsletter.
I think too often we conflate the final outcome (the thing we shipped) with our competency as designers, but that's inherently tricky. You're never designing in a perfect world, so you almost never ship the perfect thing. Usually there are compromises due to technical hurdles, new information from research, lack of resources, politics, etc.
The nice thing is that every company has these issues, so as long as you frame and communicate them properly, they'll understand, and maybe even be impressed with how you dealt with certain issues. For instance, pivoting and shipping Team Accounts v1, a mediocre product at best, which was just the best thing I could ship at the team, is the thing that impressed GitHub the most during my interview.
It feels better when something we've made is actually out there, especially when it's close to the form you wanted it to take, as if that validates the work we put in. But we're only human and all we can do is our best within a set of circumstances. So the advice I'd give is make the portfolio about the process. Be candid about the issues, and show me how you dealt with them. Because if I hire you, there are going to be issues you'll have to deal with too. I want people who make the best of whichever situation they're dropped in. Showing evidence of that can be way more powerful than just showing me that dope thing you shipped.
I think that's a good way of framing it - focus on the process and everything that went into producing the work, whether it made it to production or not, because the constraints of business needs/goals, user needs/goals and others were still present. Which is entirely different from concept work (which should be labelled as such).
This one really resonates with me. Design is just like an idea, it may be a bad idea, a good one or just an idea too big, it'll respawn as a new undoubtedly better idea.
What is dead may never die :)
Hard won wisdom here Joel. I could see this as required reading for designers in tech.
Thank you for this great write-up Joel! I've been really enjoying your other articles as well. :)
YOU ARE THE MAN! Keep going Joel