One of my big worries with the book is that people will use it like a Pokémon challenge, trying to “catch ‘em all” to somehow claim the nonexistent title of Haver of All The Skills.
I worry about that because that would have been me, several years ago. I would have felt like security in an industry or a discipline comes from being able to fill all of the possible gaps, and do all the possible things, and to have proof that I could do them because I had done them. That creates security, right?
Well, no. Not so much.
The quest for security is itself flawed when it imagines that security comes in the form of a Certified List of Achievements and Beliefs that will always be valuable.
This static history can’t create security, because things change so much. The coding I knew how to do doesn’t apply to the coding that needs to be done now. The tools are different, the people are different—and the business focus is always a little different, based on the people, processes, and products in play.
So if you’re like me, I’m hoping that the big, reassuring, security-producing message of the book is that the next skill is learnable, too. If I don’t know how to meet the business or user needs with the skills I have, I can learn them when I need them, instead of building them all up in case I need them someday. I can learn them with the tools and methods that are current at the time, to explore, define, ideate, decide, develop, sustain, and optimize my practice as I go.
I’m more knowledgeable now than I was several years ago, and it’s arguable that I have fewer things to learn in this field. But I learned so much from writing this book, from my co-authors, from interviews. If anything, I’m reinvigorated to keep learning about the new ways UX folks come up with to solve business and user problems. We’ll try to “catch ‘em all” the next time we write a book about them, but otherwise, I’m content to learn them as I need them.