3 ms·

> Don't design and code at the same time. You'll waste time and burn yourself out getting lost in CSS rabbit holes, trying to make the code look pretty etc. and

> Don't design and code at the same time. You'll waste time and burn yourself out getting lost in CSS rabbit holes, trying to make the code look pretty etc. and then when you get it working it and you step back to look at it, you realise the design doesn't work and it needs more iterations. This is where I get stuck. It's not because of analysis paralysis (although there is a bit of that too) so much as it is for optimizing loading time, comparing/triaging frameworks, and a whole host of other problems I'll call "optimization syndrome". I know the golden rule is to avoid premature optimization, but at same time I don't want to commit to a design that I like only to find out after the fact that it's slow, computationally expensive or relies on an outdated/EOL dependency. Any advice in that?

seanwilson 4y ago
> I don't want to commit to a design that I like only to find out after the fact that it's slow, computationally expensive or relies on an outdated/EOL dependency. Hmm, did you have a specific example in mind? I can't think this applies that often. You can for sure scope out the dev/tech side a little first then keep that in mind as you're doing the design first so you're not designing something that's infeasible to code. For example, I think I've developed quite a good feeling of what web design elements are going to difficult to adapt to mobile/responsive designs and will tend towards cleaner to implement ones. It's a lot quicker to e.g. roughly draw a UI widget in a design tool to get a feeling for how it might work vs integrating a UI library and coding it up before realising it was the wrong direction to go. You'll likely come up with better ideas too by getting your head away from how you're going to code your app and thinking about what a new user wants to do with your app.

seanwilson 4y ago

> I don't want to commit to a design that I like only to find out after the fact that it's slow, computationally expensive or relies on an outdated/EOL dependency. Hmm, did you have a specific example in mind? I can't think this applies that often. You can for sure scope out the dev/tech side a little first then keep that in mind as you're doing the design first so you're not designing something that's infeasible to code. For example, I think I've developed quite a good feeling of what web design elements are going to difficult to adapt to mobile/responsive designs and will tend towards cleaner to implement ones. It's a lot quicker to e.g. roughly draw a UI widget in a design tool to get a feeling for how it might work vs integrating a UI library and coding it up before realising it was the wrong direction to go. You'll likely come up with better ideas too by getting your head away from how you're going to code your app and thinking about what a new user wants to do with your app.