This kind of windy article further confirms my belief that "design" is relatively hollow at its core; essentially a jargon-filled way to try to generalize a task that must be very specific, wherein not much of this jargon is very useful.
Some user(s) have some kind of task that they want to achieve. They could get together and communicate well with some kind of developer who can help them achieve or complete that task; all of which is likely doable without this middle layer of whatever this is.
> essentially a jargon-filled way to try to generalize a task that must be very specific, wherein not much of this jargon is very useful
I think if you tried to do a similar breakdown of what it's like to design computer code in general it probably wouldn't help much either because there's rarely a rigid process - you're usually going by intuition to weigh up what's most productive to try next where the intuition was gained from experience vs jargon filled articles. I'm not sure why UI/UX design content is so thick with this kind of text in comparison though.
I mean, I think I get why -- it's that "design" is where all the cool kids are, essentially. Selling people the idea of "design" itself is profitable and/or fruitful. I teach undergraduate IT, and this whole thing definitely gets butts in seats; obviously I find it a mixed bag at best.
The longer I spend making things, the more I believe that there IS a process, and a very important and relatively general one, at the heart of good design. It's just several meta levels up from "1) create a new file and call it NewProjectName.cpp". Articles like this seem fluffy and nonspecific because you can't fit "apply decades of experience in mapping the process to a specific scenario" into a snappy sound bite or bubblegum blog post.
At a quick approximation I'd say my process is a bit like:
1) Talk to lots of people and find out what sucks about their life/job/business/etc.
2) Review the pile of things that suck and pull out the ones that seem like you could fix for much less than the cost of just putting up with the suck.
3) Talk to lots of people again, this time specifically ones with experience relevant to your target suckage, about that suckage. Become an expert in it. Spitball potential solutions but don't fall in love with any. Above all, listen to the answers, some industry vet will probably say "that'll never work, what you really need is..." and be right. Remember these people.
4) Now you should have a good shortlist of ideas that you can implement and that cheaply address an expensive pain point in a large number of peoples' lives. These are the right problems to solve. Only NOW may you start trying to solve them.
5) Run your leading candidate solutions past the experts you identified in round 3. Have solid solutions for any objection they can come up with against the idea being a great fix for their problem.
6) At this stage you probably have a couple of great ideas that you can go build.
(Should probably call this part 1 of 3, where part 2 is actually building the thing and part 3 is building a business around it...)
> Some user(s) have some kind of task that they want to achieve. They could get together and communicate well with some kind of developer who can help them achieve or complete that task; all of which is likely doable without this middle layer of whatever this is.
Whilst this is definitely true the question is what would the end result be like. All you're doing is having the developer engage in design which isn't a bad thing if they have the temperament and skillset to do it. Which not all developer's actually do. As someone leading a very practically oriented design team that develop all their designs it's painfully obvious that very experienced developers are not inherently good product designers even if they are very good at designing the code they write. In a large part I think the process of design is mostly universal but the nitty gritty parts of it are actually what matter.
There’s definitely a lot of fluff written by consultants with things to sell you though. But that’s not really different to other disciplines. In particular “design thinking” is the “agile coach” for designers.
How can you be very good at designing the code you write if you're not somewhat good at designing things for people to use in general? Sounds like you'd get incredibly clever algorithms doing something of questionable utility through an awkward interface.
Yes. Like git. Or many open source projects that tend to compete on feature set but not usability with paid products. Early Blender is a great example there. The great thing about being able to code is that you can build near enough anything. The trap of coding is that you get more enamoured with the act than the end result from the perspective of other people.
> Some user(s) have some kind of task that they want to achieve. They could get together and communicate well with some kind of developer who can help them achieve or complete that task; all of which is likely doable without this middle layer of whatever this is.
What you just described is the middle layer. You're describing a layer in the development of a product wherein the goals of the user and the business are translated into features that can be specified at a level of clarity which allows them to be implemented as part of a holistic, functional system.
If a developer does this, he is doing design.
If you agree that this is an important process, and is non-trivial to perform, you may find yourself saying "well, maybe some developers would be better at this than others," and now you've created a role called "Design Developer" or something like that.
And then if you find that this Design Developer spends more of their time specifying features for other developers to implement, and less time coding, you can go ahead and optimize your hiring process for people who are good at talking to users and translating that understanding into specifications, rather than writing code. You've now recreated the role of designer.
If instead, you say "well, this actually is a trivial process: any developer could do that work and still be a high-functioning programmer at the same time," then I would ask for some examples of this, and probably be able to give you ten or twenty times as many counterexamples.
A maxim I heard and stand by
"Design is a marketers tool. Not a designers"
Very real when you think about it. Good design comes from good understanding of the problem and the environment. Requires being a part of the environment, making accurate observations and some flight of imagination.
This 'design thinking' approach is such a rubbish. Having quite a bit of background into how design is done at Apple or some top studios, this kind of process couldn't be further away from how good design is actually made and yet, sadly, the web is filled with self-proclaimed gurus of this kind.
well one reality I partook in at a FAANG (engineering) for years essentially allowed the quality of design to be an emergent phenomenon through extremely vast internal testing and data collection, with evolution of alternatives competing for favor among testees. A tirelessly iterative process.
Thus, "good design" was derived from experiences, an emergent phenomenon, not something prescribed.
It's possible that distinction is what people are alluding to.
Somebody has been paid to put together a huge document explaining how they document instinctive design decisions. I really don't get how this is an industry.
'People will click buttons'. 'people react to this HUE value'.
It will forever blow my mind that people are paid to say where a button lives
16 comments
[ 3.3 ms ] story [ 51.8 ms ] threadSome user(s) have some kind of task that they want to achieve. They could get together and communicate well with some kind of developer who can help them achieve or complete that task; all of which is likely doable without this middle layer of whatever this is.
I think if you tried to do a similar breakdown of what it's like to design computer code in general it probably wouldn't help much either because there's rarely a rigid process - you're usually going by intuition to weigh up what's most productive to try next where the intuition was gained from experience vs jargon filled articles. I'm not sure why UI/UX design content is so thick with this kind of text in comparison though.
At a quick approximation I'd say my process is a bit like:
1) Talk to lots of people and find out what sucks about their life/job/business/etc.
2) Review the pile of things that suck and pull out the ones that seem like you could fix for much less than the cost of just putting up with the suck.
3) Talk to lots of people again, this time specifically ones with experience relevant to your target suckage, about that suckage. Become an expert in it. Spitball potential solutions but don't fall in love with any. Above all, listen to the answers, some industry vet will probably say "that'll never work, what you really need is..." and be right. Remember these people.
4) Now you should have a good shortlist of ideas that you can implement and that cheaply address an expensive pain point in a large number of peoples' lives. These are the right problems to solve. Only NOW may you start trying to solve them.
5) Run your leading candidate solutions past the experts you identified in round 3. Have solid solutions for any objection they can come up with against the idea being a great fix for their problem.
6) At this stage you probably have a couple of great ideas that you can go build.
(Should probably call this part 1 of 3, where part 2 is actually building the thing and part 3 is building a business around it...)
Whilst this is definitely true the question is what would the end result be like. All you're doing is having the developer engage in design which isn't a bad thing if they have the temperament and skillset to do it. Which not all developer's actually do. As someone leading a very practically oriented design team that develop all their designs it's painfully obvious that very experienced developers are not inherently good product designers even if they are very good at designing the code they write. In a large part I think the process of design is mostly universal but the nitty gritty parts of it are actually what matter.
There’s definitely a lot of fluff written by consultants with things to sell you though. But that’s not really different to other disciplines. In particular “design thinking” is the “agile coach” for designers.
What you just described is the middle layer. You're describing a layer in the development of a product wherein the goals of the user and the business are translated into features that can be specified at a level of clarity which allows them to be implemented as part of a holistic, functional system.
If a developer does this, he is doing design.
If you agree that this is an important process, and is non-trivial to perform, you may find yourself saying "well, maybe some developers would be better at this than others," and now you've created a role called "Design Developer" or something like that.
And then if you find that this Design Developer spends more of their time specifying features for other developers to implement, and less time coding, you can go ahead and optimize your hiring process for people who are good at talking to users and translating that understanding into specifications, rather than writing code. You've now recreated the role of designer.
If instead, you say "well, this actually is a trivial process: any developer could do that work and still be a high-functioning programmer at the same time," then I would ask for some examples of this, and probably be able to give you ten or twenty times as many counterexamples.
Very real when you think about it. Good design comes from good understanding of the problem and the environment. Requires being a part of the environment, making accurate observations and some flight of imagination.
Thus, "good design" was derived from experiences, an emergent phenomenon, not something prescribed.
It's possible that distinction is what people are alluding to.
It will forever blow my mind that people are paid to say where a button lives