But there are others who will make such statements and seem to be perceived as decisive and leader-ish because at least they are forwarding some agenda that can align people.

I haven't tried Excalidraw, but it looks pretty similar. I slightly prefer the visual style the TL;Draw outputs though.

I haven't had real problems with that. If you hold CMD while you drag a selection, it avoids moving objects, and only selects fully-enclosed things. That allows me to deal with most overlapping things easily.

Both times I’ve set up a test framework to use TDD to drive the answer. It also helps me refactor to clean up confidently.

In 2022 I did Typescript with Remeda github.com/jamiemill/ad...

... the first 10 days and then I couldn't keep up

I still like React for more complicated stuff, so I’m not sure if I would have hit a limit with plain JS and ended up frustrated for a different reason. I definitely feel the pull of nextJS which keeps everything react top-to-bottom.

I used Astro to build www.yorkshirewoldsheritage.org.uk. Most complicated was the Places section with interactivity between map and listings (on desktop).

Initially I had a react island which led to two sets of state and styles and so I ripped it out. With plain JS and it all clicked much better.

This question really got me thinking! Current feeling:

No person or role is excluded, but it’s usually contrasted with Delivery - the short moments where we put the blinkers on and execute on a bet, intentionally ignoring alternatives.

But that delivery is still in service of a bigger discovery. 🙃

You can learn all this by being really tightly integrated with a high-performing engineering team. Instead it's quite common to see designers leaving all the stuff above to the engineers...

And then wonder why their precious design is twisted and compromised by that other team.

I would also love to be added, posting about IA, designer<>dev collaboration, concept modelling and rants about Figma

It's also just... hard for designers to engage with some of this stuff if they focus their energy on Figma only

I think the reason is that developers are forced to think about all this stuff in the process of making it REAL. But these are all design decisions and ideally a product/UX designer should engage just as much with them as an engineer.

13. Conceptual/data models - the relationship and cardinality of objects which has a massive effect on the interactions and layout

9. Moving forward without breaking changes; migrating information from old features to new

10. The discipline to stress test a design with edge cases

11. Thinking how a design will respond to screen sizes, text sizes, translations, accessibility

12. Modularisation and reusability of UI

7. Consistency boundaries - where data should agree with itself and where it can become eventually consistent instead

8. Capturing intent (eg commands) instead of mutating state

9. Strategies to slice a design thin and release incrementally

3. The power of pairing on a problem

4. The power of example-driven design - working with real scenarios and data

5. The feedback and ideas you get from testing in the real medium (real code in browser not Figma)

6. Considering how to make tools safe to use

Yes it’s pretty cool! I found it useful for querying an export of research insights, eg “what did people say about feature X?” or “why might people feel our tool is hard to use?”