Official 2018 Site to Launch September 2017—Make sure to check back!

Save the Date:
May 7-10, 2019

Blog Post

On The Journey From Designer To Design Manager with Aaron Irizarry

Q&A with HOW Design Live Speaker, Aaron Irizarry

By Ilise Benun, Programming Partner and Founder of

About Aaron Irizarry:

Aaron (aka “Ron”) is the Head of Experience Infrastructure at Capital One.  He loves all things user experience, problem solving, and design process. Having worked for Fox/IGN, HP, Nasdaq, and now Capital One, Aaron loves sinking his teeth into complex problems. Aaron speaks at events and provides training for companies on design team structure, communication, and collaboration, and is the co-author of Discussing Design.

Find Aaron’s HOW Design Live 2018 Session info here:  

Critique and The Design Process: Facilitating Better Feedback

Ilise Benun: I’m especially interested in your journey from designer to design manager. It seems like an art and one that most people aren’t trained in.

Aaron Irizarry: No, they’re not. It is tough because in most other jobs outside of design, whether you work in a warehouse or in a restaurant or in real estate, you start doing the normal job. If you do well, you move up, get promoted, but you’re still doing what you do.

It’s different with design, because design is really about the artifacts and the deliverables you produce. One thing I learned from a friend is that as you progress in your career as a designer, you understand more about design. You go from being the one providing the deliverables, actually producing screenshots or mockups or prototypes, to the one managing and producing a team that produces things.

I’ve often equated it to going from the person who makes designs to the person who designs how a team designs. I love that aspect. I love the idea of taking the things I’ve learned and the dumb mistakes I’ve made and using that to help a team be productive.

I don’t design as much as I used to, I don’t prototype as much as I used to. I jokingly say, “I remember when I was working in Fireworks and Dreamweaver,” tools that not everybody uses anymore because they’re prototyping in the browser and using Github for version control. Now Sketch is becoming a very real competitor to Photoshop. Times have changed and I’m older and I’ve seen that transition.

But what’s really cool for me is to see the designers that I manage really step into their own. I don’t really care what tool they use. I definitely influence and provide critique and feedback and guidance on the deliverables they produce, but I love seeing them learn how to communicate their design and seeing how they learn to communicate their process better.

More times than not, most people just find themselves in the role of design manager. They end up in that situation because that’s what that company needs. It wasn’t something they necessarily wanted to do. But I don’t think it’s a bad thing.

I think design is about problem solving and creating deliverables and we don’t need to be that specific about what the deliverable is. My “deliverable” now is helping shape how my team works and communicating that to the business. Yes, I have insight and feedback and a hand in how things are built, but I’m not in there day to day, cranking out code or mockups as much as I used to be. But to see my team grow is incredibly rewarding.

IB: That seems like a really perfect opportunity to mention your book because it sounds like you’re talking about Discussing Design.

AZ: The book really came about by accident, but I’m so glad that it did. My co-author, Adam Connor, and I had experienced a lot of the same situations. Everybody’s been there. You design something and then you have to give it to someone for feedback, and they say, “Well, I don’t like it. Make it pop. Make it cleaner. Make it look like Apple.” Some of those silly things we always joke about as designers – that is the feedback we get!

As Adam and I talked about our funny stories over time, it really became apparent that this idea of critique and feedback and communicating our designs is an actual issue for a lot of teams. Not just for designers.

Since the book was published, we’ve seen a great amount of resonance with the community of people who aren’t designers, people who have to work with designers, such as project managers, product managers, developers. We’ve spoken on this topic at events where there are no designers in attendance at all because people want to learn how to work and communicate with designers better, which I think is a great idea.

I think we can all make more effort to communicate better about what we’re building. I really hope that this book becomes a resource that helps people. Because really, we’re only successful as a team based on what we ship.

Hopefully this book and the conversations that are stemming from it will help teams to better talk about those designs and get them in a position to be more productive, thanks to a shared understanding across multiple disciplines — product, development, design and executives. The more everyone has that understanding of what they’re trying to accomplish, the better chance their product has to get out there and be more successful.

More links: