Confusing artifacts for design itself

Is it any easier if you substitute in the process for the artifacts? I hear many that speak of this, although it's more opaque to me.

It's hard to do that when the expectation, the whole framing, is that the artifact is the design. Suggesting otherwise can cause people to look at you like you have two heads.

People either don't realize or there are incentives in place to discourage the notion that design is a holistic practice around making good decisions within a set of constraints.

There is the iterative process of design and then there is the outcome of that process, "the design". Sketch artboards, Framer prototypes, user flows, etc are an outcome of the process of design. They are the plan to be implemented, or "the design". I'm not sure if I'm missing something from your argument but I don't see the problem tbh!

Yep agree with all that. But it's the specific artifacts that are conflated with what design is. For example, the process of defining a problem and selecting that problem from other things that could be fix or explored—that process is not considered design because it doesn't have an accompanying artifact. Many times product management or execs do this work. And the result of that problem definition process is given to designers to create a solution (usually in the form of wireframes, prototypes, Sketch files, etc).

If that makes sense—I'm curious if others have experienced this or if I'm alone here hehe

So far in my 9 years of digital design, this has been the common experience

Another example that maybe you've heard that can help:

"We're short on time so let's skip design and go straight to development."

Basically, we're gonna skip the artifact creation process and just start coding stuff. There is still "design" in that scenario. Whatever is coded needs to be decided on how it works, why, for whom, what it looks like, etc.

With this language, "the design" is a metaphor for just the artifacts. It's not a process or practice of making decisions toward a goal within a set of constraints.

As long as everyone on your team is working with the same vocabulary and expectations, it doesn't really matter a whole lot.

A scenario that could be harmful is when someone says, "let's skip the design" and then sees somebody spending a bunch of time on something they define as "the design".

So, just have a light convo with your team along the lines of, "When you say skip the design, here's what still needs to happen and here's what to expect."

Usually this solves all/most semantic confusion. I've been there though. At the end of the day, you're all working towards the same goal of shipping something useful/useable and time is money–so spending time arguing over what is and what isn't design is not productive.

As long as everyone on your team is working with the same vocabulary and expectations, it doesn't really matter a whole lot.

My point is that the vocabulary and expectation are not the same. That what design is is different.

The result is the designer's work is bound to just the artifact creation.

So, just have a light convo with your team along the lines of, "When you say skip the design, here's what still needs to happen and here's what to expect."

I'm afraid it takes more than light convos. This is about changing points of view, sometimes at the highest levels of an organization.

arguing over what is and what isn't design is not productive.

This is a great point and is key to why I'm exploring this. If design = artifacts then the value of hiring great designers is massively diminished. Mike Montiero says, "Hire designers for their brains, not their hands." Designers shouldn't just be drawing pictures all day. We are trained to understand people and contexts and create meaningful solutions. But if the point of view of an organization is that design = artifacts its difficult to realize the potential. That's why I think it is productive to argue over this stuff.

The root problem I'm hearing here is mismatched expectations. Light or hard, a conversation needs to be had in order to squash a perceived problem on either side.

I'm curious what you have tried in the past to mitigate this problem. If you've failed in establishing a shared understanding of your team's process, as well as what it means if you forfeit any step in that process, why do you think that is?

I said have a light conversation, because that's how I've handled it in the past. Have a harder conversation if the problem persists.

That might be the root cause, not sure exactly. I'm not sure conversations are the answer.

Invision just published a report on design maturity. Pretty interesting results that back up my observations.

https://www.invisionapp.com/design-better/design-maturity-model/

The gist is that regardless of size of company, industry, or geographic location, most companies (41% of the companies surveyed) are at the lowest level of design maturity. This means the design function only focuses on wireframes, visual design, etc (i.e., artifacts).

My guess is that within those companies, the point of view of executives and managers is that design = artifacts.