5 ms·

Good points. I'd expand that by saying that these apply to any organization that wants a content-based site but has no need for a real web development team. No

Good points. I'd expand that by saying that these apply to any organization that wants a content-based site but has no need for a real web development team. Non-technical users often don't know what they want until they see something on the screen, and once they see it on the screen, they inevitably want to make changes that undo the first set of things they asked for. Everybody seems to have an opinion about layouts and design features, whether they ought to or not, and the least-capable voices tend to be the loudest. And you're absolutely right, explaining the limits of web dev to non-technical people is a perpetual exercise in frustration. They think web dev is like print design. As we know, it's not even close. Web design is constrained by a multitude of browser limitations that print simply does not have. They don't like to hear that.

hobs 8y ago
Often considered "bike shedding" https://phinze.github.io/2014/05/24/useful-tech-terms-part-1.html https://phinze.github.io/2014/05/24/useful-tech-terms-part-1... When you are working on minor details, everyone has an opinion. When you are working on major difficult things, nobody wants to weigh in.
qznc 8y ago
> explaining the limits of web dev to non-technical people is a perpetual exercise in frustration That is doing the wrong thing. These non-technical people don't need to understand "limits". They need someone with a clear process who guides them through it. Unfortunately many web devs have no process. Print design has its own limitations but the process which people have to follow is more established.
- zebraflask 8y ago
  Sometimes that works, but as a counterpoint: if your stakeholders outrank you in the org and don't care for your process or choose to ignore it, good luck!
paultopia 8y ago
> Non-technical users often don't know what they want until they see something on the screen, and once they see it on the screen, they inevitably want to make changes that undo the first set of things they asked for. Everybody seems to have an opinion about layouts and design features, whether they ought to or not, and the least-capable voices tend to be the loudest. What does that have to do with technical or non-technical? Isn't that just visual vs non-visual? Print designers complain about the same thing. Personally, as someone who is technical but not visual, I know I definitely don't know what I want when putting together anything visual until I build it, because I can't form a clear enough picture in my mind of what the end product will look like. So I inevitably end up building something, being really really miserable about it, and then tweaking it until I'm only moderately sad about it.
panic 8y ago
> Non-technical users often don't know what they want until they see something on the screen, and once they see it on the screen, they inevitably want to make changes that undo the first set of things they asked for. That's just how design is. If you're making any software with a visual component, you need to be prepared to make significant revisions. Nailing down the visuals before writing much (or any) code can avoid a lot of this costly re-work, though sometimes there are still things you don't notice until you have working software.

hobs 8y ago

Often considered "bike shedding" https://phinze.github.io/2014/05/24/useful-tech-terms-part-1.html https://phinze.github.io/2014/05/24/useful-tech-terms-part-1... When you are working on minor details, everyone has an opinion. When you are working on major difficult things, nobody wants to weigh in.

qznc 8y ago

> explaining the limits of web dev to non-technical people is a perpetual exercise in frustration That is doing the wrong thing. These non-technical people don't need to understand "limits". They need someone with a clear process who guides them through it. Unfortunately many web devs have no process. Print design has its own limitations but the process which people have to follow is more established.

zebraflask 8y ago
Sometimes that works, but as a counterpoint: if your stakeholders outrank you in the org and don't care for your process or choose to ignore it, good luck!

paultopia 8y ago

> Non-technical users often don't know what they want until they see something on the screen, and once they see it on the screen, they inevitably want to make changes that undo the first set of things they asked for. Everybody seems to have an opinion about layouts and design features, whether they ought to or not, and the least-capable voices tend to be the loudest. What does that have to do with technical or non-technical? Isn't that just visual vs non-visual? Print designers complain about the same thing. Personally, as someone who is technical but not visual, I know I definitely don't know what I want when putting together anything visual until I build it, because I can't form a clear enough picture in my mind of what the end product will look like. So I inevitably end up building something, being really really miserable about it, and then tweaking it until I'm only moderately sad about it.

panic 8y ago

> Non-technical users often don't know what they want until they see something on the screen, and once they see it on the screen, they inevitably want to make changes that undo the first set of things they asked for. That's just how design is. If you're making any software with a visual component, you need to be prepared to make significant revisions. Nailing down the visuals before writing much (or any) code can avoid a lot of this costly re-work, though sometimes there are still things you don't notice until you have working software.