Developers, start thinking about design!

by Alexandra Leisse | alexandra@iterate.no | @troubalex

This is a written and slightly tidied version of the lightning talk I gave at this year’s Javazone.

We designers have long been told that we should learn how to program in order to really understand the medium we’re working in, and to develop a common language with developers. While I believe this to be true, I also believe that it should go both ways.

I regularly encounter a number of misconceptions about how to work as a designer. Let’s get those out of the way first.

One is born a designer

This is equally untrue as “one is born an engineer”. Just like everything else, design needs practice, and is hard work. There are plenty of excellent resources such as “the Complete Beginner’s Guide to Interaction Design” by Andrew Maier on UX Booth or “Designing for Interaction” by Dan Saffer.

Or, how Steve Krug, the author of “Don’t Make Me Think” and “It’s not Rocket Surgery”, puts it: a lot of what we do is advanced common-sense.

Design is creative chaos

Creativity is work. When designing an interface I go through a process of understanding the problem, researching UI patterns and solutions to similar problems, discussing what I find with colleagues, research some more, sketch, prototype, iterate, and refine designs.

This is the process of almost every developer I have talked to, and I refer to it as advanced problem-solving.

There are no rules in design

Good design is based on a number of principles. It combines elements of psychology, social sciences, and computer science into a coherent result. David Kadavy’s “Design for Hackers” and Google’s “Material Design Guidelines” do an excellent job to explain some of them.

Design is much closer to applied science than anarchy.

Collaboration needs shared skills

Designers and developers are two sides of the same coin. We work towards the same outcomes on our projects, we hope to achieve the best possible results, and we have similar but complementing problem-solving skills. For true collaboration, we need to learn about our respective disciplines.

Collaboration of course is not a goal in itself. It is the outcomes I want to improve when I ask developers to start designing.

Better quality in less time

Jeff Gotthelf, author of Lean UX, argues for cutting deliverables and focussing on quick iterations. When we work towards the same goals from a basis of shared understanding, we can move much faster, and can spend less time on meticulously documenting all our work.

Having [the developers] involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. – Katie Kovalcin in A List Apart

The moment we all understand what we’re building and why we’re thinking about building it a particular way, we can trust that we are all making decisions based on the right intentions. We can finally stop micro-managing, and spend our time on the details.

You are ALREADY designing

In reality, you are making lots of design decisions already today, simply to get you’re job done.

The biggest reason, though, for involving developers is that they will end up making design decisions anyway. The truth is that, as a developer delves into building a project, they will have to make decisions that affect and refine the design. Designers rarely have the time to consider all nuances of a website. The rest fall to the developer.

By involving the developer in the initial design discussions, they will be in a better position to fill in the blanks. And when compromises in the design must be made, they will be in a better position to make those calls. – Paul Boag in Smashing Magazine

In other words, the more you know about the reasoning behind a design, the better the quality of your decisions. The blanks to be filled are small each on their own but seen as a whole make quite a difference, even more so if done really well.

Shared problem solving

But there is an even better reason for why you should learn about design: you’re smart! I want you to take part in my design discussions. The more comfortable you are with what you know, and with what you think could be a better solution, the more interesting the discussions become. I’ve seen it happen, I want to see it happen more often.

But where do you start once you have decided that you should know more about design? At work.

It’s okay to learn on the job

If you have access to the designers on your project, it’s easy: simply ask them to explain the decisions they’re making and to be included already in early design discussions. This is obviously not as easy if you’re working with a design agency. In that case I encourage you to pester other designers.

What you can do regardless is to be aware of the decisions you’re making and the impact they have, to read design blogs such as Smashing Magazine or A List Apart, and to dissect interfaces of applications you’re using.

Break down the silos!

Konsulenteriet må dø!

av Erik Assum / erik@iterate.no / @slipset

Dette er en transkribering av min lyntale på JavaZone i år. Det er ikke ordrett, men innholdet er relativt likt.

Introduksjon

Jeg kommer i denne blog-posten til å snakke om konsulenter, prosjekter og forvaltning, så jeg må begynne med å definere i alle fall disse begrepene. Deretter skal jeg si noe om hvordan jeg mener man bør bruke konsulenter. Dette holder jeg opp mot noen vedtatte sannheter jeg mener finnes om IT, og tilslutt en oppsummering.

Definisjoner

Wikipedia definerer en konsulent som

en tjenesteyter som i en profesjonell ramme tilbyr sin ekspertise innenfor et visst fagfelt, vanligvis i et begrenset tidsrom

I dag finnes ordet konsulent også brukt om innleid ekstrahjelp uten den kompetansen vi tradisjonelt forbinder med begrepet

Samme nettsted definerer et prosjekt som

En innsats som gjøres for å oppnå et definert mål, som oftest innenfor en planlagt tids- og ressursramme

Selv definerer jeg forvaltning som

Et sted der systemer laget i prosjekter bemannet med konsulenter blir sendt for å dø

Konsulentbruk

Så hvis jeg mener at konsulenteriet må dø, mener jeg da at all konsulentbruk er ufornuftig? Det enkle svaret er nei. Det litt utfyllende svaret er at man skal bruke konsulenter når man har korte og avgrensede oppgaver utenfor kjerneområdet. Eksempler på dette er f.eks om du skal bytte fra websphere til tomcat, flytte fra svn til git eller sanere noe gammelt ræl som ingen bruker lenger. Det viktige her er at det er konsulenten som er domene-eksperten. Ikke kunden.

En annen god grunn til å bruke konsulenter er fordi du mangler kompetanse og trenger hjelp til å komme igang. Eksempler på dette vil være å få opp et CI/CD-miljø eller begynne med et nytt programmeringsspråk som Clojure. Igjen er det konsulenten som er domene-eksperten og kundens mål vil være å nytte godt av denne ekspertisen for å unngå fallgruver og komme seg fortere igang.

Konsulenteriet må dø!

Så hvilken bruk av konsulenter er det som er så feilaktig at jeg mener at det må dø? Det er når man bruker konsulenter til oppgaver som ligger i de fast ansattes domene. Fordi da er ikke lenger konsulenter ekspertene. De er vikarer.

Grunnen til at jeg bryr meg om dette er at jeg mener at en slik bruk av konsulenter koster langt mer enn det smaker. For konsulentbruk er et optimaliseringsproblem, som så mye annet. Og for slike problemer må man kjenne både gevinster og kostnader. Dessverre er det også slik at en del av de gevinstene man ser for seg kommer man aldri til å ta ut. Det blir som å kjøpe opsjoner uten å utøve dem. Og det er jo bare dyrt.

Vedtatte sannheter om IT

De skulte kostnadene ved bruk av konsulenter, sånn rent bortsett fra at de som regel er dyrere enn faste ansatte forblir skjulte fordi kunden tror på følgende sannheter om IT.

IT er kun en utgiftspost

Fordi IT kun er en utgiftspost er det fint å kunne skalere ned i dårlige tider. Av samme grunn er det fint å kunne bytte ut dyre konsulenter med billigere vikarer som er like bra. Poenget her er at det er ytterst få bedrifter som klarer seg uten IT. Man må innse at for å lykkes idag, må IT integreres på alle nivåer i forretningen. IT må være forretningen , forretningen må være IT.

Domenekunnskap er uviktig

For at IT og forretning skal kunne jobbe sammen og komme med de beste løsningene på de vanskeligste problemene, må IT forstå forretningen bedre enn forretningen selv. Da nytter det ikke med vikarer som løper ut døra så fort prosjektet er overlevert til forvaltning.

IT systemer blir ferdige

At Politiet fortsatt bruker Straffesaksystemet som ble levert i 1979 er bare trist. Det som hadde vært kult var om politets Straffesaksystem hadde vært topp moderne og i kontinuerlig utvkling siden 1979.

Fordi vi anser systemer som levert, og ikke foredler dem over tid, blir de tilslutt helt ubrukelige og må byttes helt ut, ikke ulikt Svinesundsbroen. Men fordi man ikke har hatt noen kontinuerlig utvikling, har man ingen utviklere og man må inn med konsulentene, som må lære seg domenet som de ikke kan noe om. Og fordi man nå endelig skal få et nytt system, må man passe på at man får med seg alt man har savnet de siste 30 år, pluss litt til. Og når systemet blir definert som ferdig, enten fordi budsjettet er brukt opp, eller tidsfristen overskredet, forsvinner konsulentene med tilhørende domenekunskap ut i nye oppdrag i nye domener, og tilbake sitter brukerne med et system som ikke virker, hverken idag eller i framtiden.

Tilslutt

IT har kommet for å bli

Det er veldig få bedrifter eller etater idag som sier at, nei, IT er
ikke noe vi satser på. Manuelle rutiner holder lenge for oss. Idag må alle
IT systemer være under kontinuerlig utvikling, bortsett kanskje fra de
som ingen bruker.

Konsulent eller vikar?

Så hvis du er konsulent idag, bør du tenke deg om. Hvis du sitter ute
i oppdrag og egentlig bare er en midlertidig ansatt fordi kunden
ikke klarer å ansette folk, bør du kanskje heller hjelpe kunden ved å
forklare på en pen måte hvorfor de ikke er attraktive. For din rolle
som konsulent bør være ekspertrollen. Den som kan noe som kunden ikke
kan.

Men dersom du sitter ute i et tidsbestemt oppdrag og hjelper kunden
med å bli bedre på ting den ikke kan, eller løser et problem som
ligger på siden av kjerneområdet, så synes jeg du skal klappe deg selv
på skulderen og gratulere deg selv med å ha funnet et godt
konsulentoppdrag.

Experiences from ReactEurope

At the beginning of July, Truls and I went on our first work trip abroad to attend the first ever ReactEurope conference in Paris. A two-day conference dedicated to the very popular React.js, a frontend library made by Facebook, and other related topics. Despite of an intense heatwave in southern Europe and the lack of an A/C that could cool down 700 people in a single venue, we still feel that the conference was a great experience. There were many great speakers who presented interesting topics and we learned a lot from their talks. The speakers include the creators of React.js, React Native, Flux, ImmutableJS, GraphQL, Relay, Babel, Redux and React Router, all important parts of the React ecosystem. We also had many enlightening discussions with other attendees.

A lot of people in a not-so-big and no-A/C venue.

Continue reading

Lean summer of 2015 – Week 6

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 6.

Our Lean summer has come to an end.

Six weeks ago we were given a task; to help Telenor innovate in different areas. With the rise in popularity and functionality of webRTC, Telenor wanted to know whether or not this technology could help.

first_day

Six nervous students preparing for their first day

We didn’t expect this project to be easy, and didn’t expect it to go without issues or problems. We expected guidance, but we also hoped for some freedom to try and fail for ourselves. Mistakes are a great opportunity to learn, but only if we can make and solve them on our own..

IMG_0120

Six great friends enjoying a last party together before going their separate ways

Continue reading

Lean Summer of 2015 – Week 5

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 5.

Navigating the corporate jungle.

Compared to the real world, student life is easy. We are free to do almost whatever we want, when we want to. You never really have guilt-free time off, but you also don’t have to get up early every day.

For many of us, summer internships are the first taste of a real job. We would soon discover that getting up early would be the easy part.

IMG_20150720_180731

How many interns does it take to fire up a grill? One to light it and four to watch it in silence and scare away the seagulls

Continue reading

Lean Summer of 2015 – Week 4

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 4.

In Lean, you have to be versatile.

When iterate hired us for a summer internship, they didn’t do it to stick us in a dark room to code their todo-list. Our focus is to innovate, to do something different than what we are used to. We use the Lean methodology to help us with this process, and the goal is to figure out what the customer needs.

IMG_20150715_141735

Team Phone hacking out new ideas for their recruitment campaign 

Continue reading

Lean Summer of 2015 – Week 3

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 3.

We knew from the beginning this internship was going to be different.

Most tech student summer internships follow a standard format: You show up the first day to a round of introductions, you get assigned a workstation, a task, and maybe some company swag. The first week is focused on workshops and courses, and then you are set to work. For the next few weeks you work on your project in order to bring it to completion on time.

Certainly a cool internship when you get to brew your own beer and design a matching label.

Continue reading