Week Links #3

Links I found interesting or useful this week.

I’ve been catching up on my feed reader, which is why a couple of these are from Jim Nielsen’s blog. Jim always writes interesting takes of things where design and code overlap.

More Files Please

Here Jim is referencing an article by Scott Jenson, which is worth a read too, which discusses the importance of files to an AI driven future. Jim’s post doesn’t go too much into that, instead focusing on files as a medium of exchange and ownership, almost like currency, which I found interesting. Like Jim, I’m a files guy too - I appreciate the value of a file as a container for information, one that I own. And like Jim says:

Do we want to trust our data to the success or failure of a single company?

John Romero doesn’t believe in prototypes

This one from Dave Rupert happens to be about two subjects I love; gaming and prototyping. I want to revisit the links in this post later to learn more about the history and context.

I have to admit though, a quote like this does ring true with me on a few levels:

No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later.

To reconcile the fact that I think prototyping is crucial, and the fact that I kinda agree with John Romero there, depends on how you define prototyping. If your idea of prototyping is to create something that ultimately does not become the end product, then yes, I can see why someone would not value prototyping. But, if like me, you believe that prototypes should ideally be real working software that you could ship, it makes sense.

This is how I’ve been approaching projects in recent years. I’m prototyping by building the real thing. It might be a crappy version at the beginning, but it gets worked on iteratively, and gets tested for real in the medium it’s intended for. There’s a lot of value in working that way, especially in fast moving teams.

The Case For Design Engineers, Pt.II

The term “Design Engineer” is something I’ve heard on occasion and thought, well yeah, why wouldn’t you work in the medium you’re designing for? Jim’s put together a fantastic explanation of why it’s not only a specialist role, but crucial in the development of digital products.

You need someone who can do design work with code.

It’s a term I identify with and I see a lot of myself and how I work in Jim’s article. I am a Design Engineer. I’m not sure if it’s a commonly used enough term to start using it all the time - most people are more familiar with Web Designer, but I like that it communicates the essence of the role.

Pixels of an interface from a GUI tool are a static representations of a dynamic form. It’s the difference between a picture of me and the living, breathing, moving me.

Design engineers don’t just push pixels around in a GUI tool, they do it in a web browser — the medium of delivery — designing not just the visuals but the interactions that make sense for a living, breathing, moving interface.

That right there is the key takeaway. Doing a ”pixel perfect” visual design of an interface is still just a static picture of a dynamic medium. The experience that a user will have isn’t a snapshot in time, something flat and unmoving; it’s alive and dynamic. Being able to create that, in the browser is design work.

Boost, the Frontend Masters blog posted an article commenting on this with a few additional links, which are might be worth a read too.