What I learned from 2013

A non-exhaustive random list of things that stroke me


In contradiction with the fact that I am no longer at school and that I am getting older and older, I feel I am still learning and 2013 was indeed a great full-of-stuff year.

For the first time in my life : I got married, I became a father, my job applications were rejected, I started to behave like a responsible adult at work, I saw a therapist, I started to accept things that I couldn’t have accepted before, I considered the fact of living with a mortgage above my head, I convinced my mother to change home, every doctor I saw told me to lose weight, I was invited to a British wedding, I gave a conference in a barcamp, I discovered Wisconsin in winter, I attended 2 startup weekends & I went to SXSW.

Crap, it sounds like I am getting old.


Step Your Webdesign Process

In terms of work-related stuff, in my line of work, I tried to make things go quicker and further providing my clients coded wireframes as an answer to their problems. Wrong. Clients are not ready.

When I start a project, I try to explain them the reasons why coded wireframes are a better, quicker and smarter way to deliver web pages/apps/sites. It’s natively responsive, users can observe items behaviors, it’s quicker to test, it’s easier to fork with a team of people around the globe, it’s easy to share and to improve. Basically it’s more efficient.

Clients are not ready for this process. They want their JPG mockups to give feedback on with a red marker and email it back to you. They want to make little non-important changes such as the logo size, the rounded corners, the gradients… They want this. They need this to exist as a client. It is their way to participate in the making of the solution.

What I learned here is that you have to let your clients find the solution themselves. At least, part of it ; and take care of the part they don’t want to do. If you don’t let them find a part of the solution they won’t consider yours as the good one. Or, better said, they won’t be able to consider this solution as the solution they will promote or use.

Therefore, from now on, I will design in 3 steps :

  1. White paper, 1 color lines (sharpie), expression of the main experience and screens navigation. Basically the structure of elements and interactions : no feedback as you design it with the clients. Make them sign the paper (the one who validates and, if possible, the one who pays). It’s important.
  2. JPG mockups of all screens (desktop screens only), fully colored : 2 steps of feedback maximum (on color scheme, gradients, logos, shadows, rounded corners, fonts (everything not validated during step 1)). Be careful, keep it consistent.
  3. Responsive coded wireframes, HTML, CSS & JS online (not local, it gives a better idea of performance). No programming needed. Fake links with functional mockups will make the job. Only one step of feedback (only on JS/CSS behavior or on specific use cases).

As a conclusion, even if you know fancy, efficient and smart ways to deliver web, don’t use them if you’re not sure your client or supplier will be able to fit in.



Just Fucking Do It

Well, it always sounds easier to say it than to do it but it is actually the best advice someone can ever tell you about anything. From the mistake rises wisdom. From the wisdom rises success.


Designers & Developers Are Different People

Even if the obviousness of the title is close to stupid I wanted to write a few words about it. This year, I’ve been quite busy reading posts telling that designers should “learn to code” and developers should integrate better design in their production. The fact is that there are really few people that can do both and enjoy great results. The good developers I know couldn’t design something great and vice-versa.

However, it is true that they are more and more talking and listening to each other and this is actually a great thing. As they are learning from each other they are producing solutions with encouraging compromises.

When I first started to work with developers (and therefore got to talk to them (I’m crazy, right?), I started to execute design in a completely different way. I paid more attention to “development time VS user impact” over functional details. I focused a lot on maintenance, performance, reliability, interoperability and all this finally made me take better decisions for the user interface in general. Simpler navigation, a button where it should be a button, a link instead of a form, less bullshit when useful information is needed. And last but not least, internationalization readiness.

What I call the “developer laziness” is the quality that makes great developers. They will tend to find the quickest, simplest, most scalable and most sustainable way to program things. Which is great because programming is about thinking the smartest way to make machines do the boring stuff, isn’t it ?

I can hardly find a word for the designers opposite quality. Let’s call it the “designer foresight”. Tell me if you find a better way to call it. It is pretty much the same. What makes great designers is their ability to make a design last. Their way to design something which will be used, which may be adaptable and which the user may project himself using.

That’s why I can’t imagine developers being designers and vice-versa but I kinda dream of a world where developers may deeply understand this designer foresight and where designers may consider the developer laziness as the essential quality.


Some Bastards Rule

Yeah, if you can’t do anything about it, just live with it.



Don’t Push Too Hard Yourself, Take Your Time

This is the final obvious piece of advice for the day. Obvious but true. We only live life once.

Take care of you and of the people you like.

Email me when Experiences & Experiments publishes stories