Like many of you, I, too, joined the tech industry purely by happenstance — it was not planned, and I had no idea I was getting into product design when I was accepting the roles I was accepting. I was just doing what I thought seemed reasonable.
At some point, I became aware that my career had a name, and it was called “product design” (at the time, of course, it was called “UX/UI design”). Around this time, I started hearing a great deal of fanfare for “design methodologies,” “the design process,” and other intriguing phrases that I could not exactly derive the concrete meaning of. I heard colleagues talk about these phrases, or I saw presentations from colleagues trying to explain why we should employ them at our workplace, and so on. I began to be concerned: up until this point, I’d not engaged in any “methodology,” or “process” in my work — I just did what I thought seemed reasonable. I anxiously thought about an overhaul of my entire approach, wondering if I was doing it all wrong all this time, misleading my peers and employers.
Day 1: understand
I looked up design methodologies. But every source that explained one seemed different to the last; what’s more, none of them seemed to map to what I could seriously imagine doing at work every day; I saw diamond shapes and references to teams or roles we either didn’t have or I didn’t understand; I saw references to activities that didn’t seem plausible, — or even fun — for my colleagues; I saw charts illustrating pipelines of work, with trees going into other trees, depicting “the product development pipeline”; I heard words like “scrum,” “agile,” “rituals,” and the dreaded “waterfall” — I worried often about whether I was “doing waterfall,” and wasn’t sure how to find out if I was.
I felt confused, and I told myself that I just wasn’t at a level where I could understand — but that, eventually, I would. Looking at the dearth of articles online, and the presentations my colleagues were bringing back from design conferences, anyone who was anyone was using a “design process,” was “doing agile,” so, surely this must all must make sense to someone, somewhere. I wondered if my job was the problem — is my workplace behind the times? Are we doing design all wrong? Should I find a workplace that uses these methodologies and processes? Was it just me?
If only I’d doubled my diamonds more
So that’s what I did. I looked for places that, in their marketing material, indicated that they engaged in these methodologies and practices. Off to the races I went. One workplace, in particular, had a publicly available “playbook” in which they described their entire design process. They used design sprints as their preferred methodology.
When I joined, however, I noticed that we didn’t do these often — we often did the opposite of that, in fact: to keep the lights on with our studio, we had to do things like staff augmentation, and we did the things our clients told us to. I sometimes asked myself: if these processes were the right ones, why weren’t people banging down our door to engage in them? Why weren’t these processes such good products to sell that we could make a living off them? If something is good, it should largely be self evident, no?
But there was more. When we did do design sprints, though we faithfully followed the processes with our clients (and even had fun doing so!), I noticed that the products we launched that started with sprints failed as often as the ones that did not. What’s more, one day, when all of us at the studio were chatting, a developer, — speaking on the gulf of difference she was observing between what our playbook claimed we did, and what we actually did — in a hushed voice, had the temerity to ask the room: “does it ever seem like there’s some aspect of our design work that’s just aspirational?”
You ever lose your religion?
Some time later, I felt my mind resisting the diamonds and the methods and the processes and the sprints — all of it. I felt myself go from “I don’t understand these methodologies, but I know there’s something there to get!” to “I don’t understand these methodologies, and there’s nothing to get.”
From there, when I’d hear talks about the value of design processes, methodologies, and so on, I felt my soul roll its eyes. I had truly lost my religion. I was the real imposter on the ship.
Just yesterday, I was chatting with a dear friend and colleague of mine and, on the topic of both of us taking up mentoring as a hobby, I sheepishly asked him: “do you ever notice all the early career people have the same case studies? Here’s some generic app, with some problem statement, with some graphic of some random guy and made up quotes about his life, pictures of stickies…?” He immediately started laughing, saying, “man, none of us do any of that shit.”
While I lost my religion, I think I got my old self back: I just do what I think is reasonable. To me, there is truly nothing of greater importance than ol’ reliable: good, solid reasoning from the giant skull noodle — if I don’t get it, I don’t buy it.
