2017 — a love story for the web

A new year in tech — from a web developers point of view

TLDR; Work together, as a team. From beginning to end.

Ahh, nothing like a new year. A fresh start, a clean slate. Kind of like selecting “new project” in your favourite IDE. No build errors, no warnings, just clean code (at least for 5 more minutes). 2016 had a lot to offer a tech nerd like me. As a matter of fact I can’t seem to remember the last time I had so many things on my “need to know”-list as right now. ASP.NET Core, react, webgl, docker, phaser. The list goes on and on.

So, before looking into the future, let’s look at what 2016 made me do. Turns out it was a lot of scary things:

• I went as, what it seemed like, the only backend-coder to the frontend conference, NordicJS. Lessons learned: 1) Frontend coders are a lot younger than me. 2) I need to know React. 3) I need to make a game.

• I quit my job at Dear Friends and joined the bees at Humblebee. Lessons learned: Sometimes drastic change is the only way to move forward.

• I finally allocated time for my own ideas and projects. I am no longer working full time, and will spend one day a week hacking stuff together alongside two of Swedens best coders. Lessons learned: Just do it (thanks nike).

2017 — bring it!

So what’s in store for 2017? Well there is one thing that has been bugging me for quite a while now and I think it’s blocking our journey to greatness. I am talking about the design handoff. You know, that phase where your fellow designers have been working on this cool new app/website/campaign/thingy for months, diving into all the latest design trends, packing so much functionality into the application the client can’t wait for it to come alive. Oh, yeah, and they decided to change their design tool of choice for the third time this year.

Enter production. All of a sudden the project is time-framed, there is a delivery date that will not under any circumstances be adjusted (it will be). As a result you are forced to do estimates on every single task. And even though you tell your PM for the 100th time that estimates are a bad way of doing project planning and should under no circumstances be treated as deadlines he/she just rolls his/her eyes and be like:

So you start coding. At first it feels kind of good. Even great. Maybe this will be the first project in the history of web projects to actually launch on schedule. Then small things start to break apart.

These desktop designs are really nice. What about mobile? Hello? Anyone there? …Add 200+ hours of figuring out how each module should look in mobile.

Hmm, I wonder what that tiny search icon up there in the menu bar does? Turns out it was a fully fledged, auto completed site search that flies out and does a complete site takeover. Oh, it should also include wikipedia and instagram search results because why not. Add 110+ hours of unplanned work.

Hey guys, anyone know how these buttons will look like when pressed? Turns out the designer has promised all the buttons to be animated. Hover state: an animated 3d dragon jumps out of the button. Push state: The dragon starts blowing fire particles all over the screen (can we use webgl?), pops back inside and then fires the buttons actual behaviour. Add 150+ hours, last week of coding.

Hey PM, I guess the site should be hosted in the cloud right? (Say yes, say yes, say yes). Umm, actually no. The client want to host it themselves on their own servers. Why don’t you head over there with at usb drive and like, install the stuff. Add 100+ hours of testing application on an old internal server only reachable from a cold server room at the clients office.

So you see, design handoffs need to go! Let’s just leave them there in 2016 and never look back. But how?

Moving on

Ahh, solving problems. I love it! So how do we solve this one?

Easy.

Work together, as a team! From beginning to end.

Yes, this means there will be a developer in the initial client meetings even though there is nothing to code yet. It also means there will be a designer present on every production sprint demo even though there is nothing to design.

Why? Because we have to. And while doing this I think a new love will rise.

A new love affair

I predict that 2017 will be the year of love. The love between designers and coders. Sure, it will be awkward and uncomfortable at first. But I know that as you get to know each other better, quite a few will turn into life long relationships. Well at least longer than the average high school crush. Because we need each other to make the internet great again (Thanks Trump). We have seen enough of bad user experiences, overdue projects, sad developers, sad designers and unhappy customers. And the only way to get out of this mess is to stop blaming everyone else and start working together.

So how do we approach this problem. I’ve put together a three-step-guide.

1. Respect.
   Yes, the developer will know more about code, testing frameworks and architecture. Yes, the designer will know more about flat design, prototyping tools, colour schemes and fonts. But that doesn’t mean you can’t question each other. This is what will keep us going forward. It’s inevitable. I’m convinced this will happen more frequently if we start working together every day instead of only during the few hours of the design handoff. But when doing so, treat each other with the respect you deserve. You are all skilled in your respective area, that’s why you’re in this team in the first place. And remember, it’s equally important to let your team members know what’s good as well as what can be better.
2. Curiosity.
   Ok, Here we go. Should designers code? Should coders design? Yes, and yes. Don’t get me wrong here. I’m not talking about some kind of super-designer-developer-full stack-ninja here. We still need both roles. But if you’re designing for the web you should be curious enough to want to know how it’s coded. Maybe not in depth, but you should want to use the inspector to see what’s going on on that cool new campaign site you found on Digital Buzz Blog. Getting the students interested in code was my main focus when I got the opportunity to give my thoughts on a new educational program in Sweden called “Digital Designer”. This of course goes both ways. If you’re coding for the web you should want to know how designers think. You should have tried to do a website mockup using Sketch or any other design tool and you should be interested in making great graphical user interfaces. This makes us understand each others everyday struggles. One solution to finding common ground would be in the prototyping phase. Why not skip Invision (or whatever tool you’re using) and try prototyping in code instead, together. Let both designers and developers do the code. Give it a try!
3. Involvement.
   If you get through 1 and 2 you will probably want to get more involved in each others work. And you should! It’s the key to making great experiences. Tell your project managers that they need to involve the whole team from beginning to end. The waterfall model has run out of water. Demand a project plan that is built for teamwork instead of handoffs.

If we embrace this, as a bonus, I think we can start appreciating changes along the way. Because you’re all in it together. You got each other covered. No designer to blame for missing button states or for not providing mobile design. No coder to pick on when the newsletter signup function doesn’t work. Just the team. A team that embraces the challenges instead of finding out who to blame. Together. Just like love.

❤️

What do you guys think? Am I at least a tiny bit on the right track here? You tell me. I’m sure as hell gonna use this year to find out!