Why the Developer went to the Design Conference

Andrei Popa
AlphaSights Engineering
4 min readJan 4, 2018

I’m not a designer, but I consider myself a problem solver and in order to solve problems I always feel the need to gather as much knowledge as possible around my area of expertise. So I decided to go to a design conference this year and expand my horizons.

You probably heard of Nordic.js – well the Nordic masterminds created something new – Nordic.design and I was lucky enough to attend the 1st edition. The speaker lineup was incredible and included, amongst others, Tim van Damme from Abstract, Tobias from Minecraft and Carly Ayres (which I hope we’re going to hear more about in the future).

First, not all design conferences are about colours, contrast, the 8px grid or when not to use drop shadows — as one might expect. That’s not what all designers are up to these days. This one was oriented towards user experience and UI, but I think it was actually more about people. Humans designing for humans, interacting with humans.

It also was my first time in Sweden. If I can tell anything about Swedes (first impression) is that they’re all about feeling. Not just designers, but everyone in general. And you could see that in all their presentations, all of which, by the way, can be found online here — Nordic.design 2017 Conference.

Below I’ll give you some of the conference highlights, biased by my own taste and preference, of course. Feel free to watch the whole videos or just a couple of minutes from each, starting on the queue points.

In their talk, The Power of Play, Willow, and Petter relate to real-life emotions and use that feeling to lay the ground for building better products and explaining design decisions.

One quote that really stuck with me was, “Always assume good intentions.” I’ll just let that sink for a few seconds…

Another one of my favorite presentations was Tobias Ahlin’s — he explains how gathering more knowledge instead of judging people very quickly can change opinions in virtually no time.

Tim van Damme lays it out very well explaining why people should be encouraged to speak up, have their own opinions instead of acting like clones. This is the kind of environment that allows teams to build better, less monotonous products. Also, diversity is not always about gender, race, or ethnicity. It’s about backgrounds as well.

A great example is AlphaSights, where some of the developers were once professional poker players, lawyers, or had careers in the military before joining the software engineering team. All the knowledge they brought was invaluable to the group, as well fresh perspectives on certain concepts.

Also, his quote, “listen to what users want / give them what they need,” is something that not only applies to design, but applies to most of software engineering and beyond. If the front-end team asks the back-end team to add a new field to the database, that might not be what they need — they might need a query that outputs the same thing — so questioning some decisions most of the times end with better, more robust and documented solutions.

“You can’t efficiently break rules if you don’t understand them,” was my favorite in Car Noone’s The Irresponsible Designer. She also questions the concept of, “done is better than perfect,” arguing that people don’t really use mediocre products.

One thing not very well documented in her talk was the statement, “everybody falls in love in the same way,” which I don’t completely agree with. It’s not always love at first sight when it comes to products. Some users prefer discovering new features over time to engage, some prefer to have it all in the same place from the start… others never start at all. Maybe getting everyone to fall in love would be a goal as far as I can tell.

To conclude, I highly recommend anyone to attend design conferences, product conferences, go to medical conferences, or building materials conferences. It might open new perspectives and one would be amazed how many concepts from different fields of work apply to software engineering and the other way around.

Take Percy Spencer for example, a Raytheon engineer who started fiddling with energy sources for radar equipments — and this is how the microwave oven was invented in 1945. It’s a funny story actually (bit out of context):

One day while building magnetrons, Spencer was standing in front of an active radar set when he noticed the candy bar he had in his pocket had melted. Spencer was not the first to notice this phenomenon, but he was the first to investigate it. (Source: https://en.wikipedia.org/wiki/Percy_Spencer)

Also, don’t be afraid to be wrong. Question decisions if they don’t feel right — gathering more knowledge can only be beneficial for building better products and richer features. And to quote Cat Noone, “Designers should code. Bye!”

--

--