3 ms·

> 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 t

> 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.

jrm4 4y ago
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.
taneq 4y ago
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...)

jrm4 4y ago

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.

taneq 4y ago

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...)