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

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