Designer vs designer
This is just a quick stream of my thoughts as I react to an important Twitter thread from Jared Spool within which he suggests the following:
This thread is important for a couple reasons; First because Jared Spool is a titan in UX, his research and thoughts carry weight and should be carefully considered (and his open/public objectivity reinforces for me his dedication to that craft), and second because it all dovetails into a point (I think) he’s been trying to make for some time about inclusivity in design/process (I recommend reading his article for better context).
I’m kind of a tweener; I “design” daily, and work very closely with our UI/UX Design team (and other teams), but I live in Engineering and am primarily a UI Developer. Notice that I’m making a usage distinction between a verb “design” (lower case) and a noun “Design” (upper case), which I think is very important here, and the crux of my disagreement/confusion with a generalized classification of any influencer of a design as being “the designer”.
Let’s be clear, anyone can “design” something, including very complex interactions/applications, but that alone does not make those people Designers; they have designed, clearly, but these are different things, and semantics are important.
As an attempt at a question of equivalence, if I provide input toward, and thus influence a Request for Proposal (RFP), am I the Salesman? If I provide input toward/influence a schema, am I the DB Admin? If I suggest a default value of a translation, am I the Copywriter? All of these seem flatly ridiculous to me; it would similarly seem to me flatly ridiculous to think that no person outside of a title/role can influence the outcomes of those in that title/role. Part of my issue here is related to the singular “the” and the other part is related to, what in my mind is, an overly generalized classification.
I’ve been at my current company for well over a decade, during which I have evolved/changed roles many times. Especially when we were a much smaller team, by nature of a relatively high need for getting things done to relatively low capacity for specialization in a specific subject matter, well defined governance and roles are heavily blurred. During a time when we didn’t have Web Developers, or UI Designers, or even Product Directors, I was a heavy influencer in our product suite, including development, design, and direction. That being said, I wouldn’t have referred to myself as any of those titles at the time, despite performing tasks of all 3 of those roles regularly. I do recognize that during those days, because of needs:resources, I was “designer”, “developer”, and “director” (often all 3 for a given feature) of many of our still existing/revenue generating products, and in this context, Jared’s point seems reasonable. It could be said I was “the designer” for a dual-handle slider price filter, but “The Designer” here may as well have been someone at an e-commerce site from which we drew inspiration.
It’s important to widen the top of the design funnel to include as much input as feasible (this is something I’ve been actively working to nurture within my organization); this is especially true as more specialized roles become common in larger teams. It’s simply not enough to throw a business case or set of requirements over a fence to a Designer and trust that person will output the most appropriate solution to a given design problem in a silo (this holds true for every related role: product owner, technical writer, copywriter, designer, developer, tester, etc). If something is small, it’s relatively clear; “We need to collect the user’s email address and store it in their (existing) customer record in this (existing) db field”. The risk of the Designer getting that wrong in some way may be small, but risk exists; they could forget entirely about things the owner/spec writer forgot to include, or made assumptions were known compulsories; localization, responsive layouts/device classes, touch input, existing UI pattern, input validation and error feedback, input sanitization/security, et al. The larger the feature, the greater the risk of something being missed. So, as the group of influencers grows, design risk lowers.
Design is heavily rooted in influence. Much of it is subjective; things that look or feel right to an individual, so in that sense, we are all designers. Most of us are also copywriters, or coders, or developers, or managers, or usability researchers, and probably all of those and more. The work of a talented Designer however moves closer to objectivity; they frequently derive inspiration from elsewhere, but then make effort to validate their work, through research, testing, analysis, et al. A Designer should absolutely procure influence from a myriad of sources, including internal non-Designers, but they then distill those influences into their designs, and validate the effectiveness of each. “Design” and “design” are certainly very closely related, but differ in important ways.