Developers, start thinking about design!

by Alexandra Leisse | | @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!

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.


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 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

Lean Summer of 2015 – Week 2

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 2.

Continue reading

Lean Summer of 2015

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 1.

Continue reading

Smidig 2014: Smidig vs Lean Startup

Nei, vi skal ikke rope “dette er ikke lean startup” fra taket på Oslo Plaza i årene som kommer. De fleste av oss har måttet høre på utsagn som “this is not proper Scrum” mang en gang, uten at det hjalp verden nevneverdig videre.

Vi lover.

Dette er en liten oppsummering fra Smidig 2014 og workshopen “The idea that wins” (også kjørt på Oslo Innovation Week tidligere i høst). Vi skal forsøke å bruke læringen fra workshoppen, og Smidig-konferansen forøvrig, til å nyansere forskjellen på Lean Startup og det vi kjenner som Smidig.

Det heter ikke Lean Startup-"metoden", eller Lean Startup-"prosjektet". Fjern bindestreken og det etter.

The Idea that wins er en workshop om å få Lean Startup til å fungere i etablerte virksomheter

I år var det flere lyntaler om Lean Startup på Smidig-konferansen. Det er gøy og nyttig å høre fra andres erfaringer. En av lyntalene handlet om et kortvarig Lean Startup-prosjekt der produktet ble levert på åtte uker, men hvor produkteieren senere ble presset av samarbeidspartnere til trekke produktet tilbake. En kritisk antagelse som ble falsifisert først etter at prosjektet var ferdig?

(For ordens skyld: Åtte uker er “ingenting” i et smidig prosjekt. Det er en evighet for en Lean Startup.)

Tilbake til workshopen. “The idea that wins” handler om å få Lean Startup til å fungere i en etablert organisasjon. Her leker vi med tanken om å bygge en liten startup i moderselskapet, og få alle rundt oss til å heie på oss. Ideen kom for lenge siden på en kaffebar i San Francisco i 2011, hvor jeg fikk anledning til å ta en kaffe med Eric Ries. Det var en svært interessant samtale, hvor han blant annet påpekte at han, tross navnet, hadde skapt Lean Startup for å hjelpe etablerte virksomheter.

Der har du også hint nummer én: Det begynner med en liten, autonom enhet – en startup inni moderskipet som itererer over en visjon ved å validere forretningsideer. Smidig på sin side, dreier seg mer om å validere funksjonalitet (mens vi forutsetter at prosjektet har livets rett).

I workshopen var Evry, NAV, Compello, Dossier, SOL og Iterate representert. De to sistnevnte i kraft av å være fasilitatorer. Målet var å lære noe viktig fra “mannen i gata” om deltagernes forretningsidéer – innen dagen er omme. Det klarte begge teamene.

Det er neste hint: Uansett hvor stor og tung ideen din er bør du klare å innhente læring fra den store verden på dag én.

“Dette produktet koster 30 kroner” (a)

“Dette produktet koster 80 kroner” (b)

“Dette produktet koster 160 kroner” (c)

Gruppen “No Such Box” sin ide var å tilby brukere skylagring med distribuert kryptering, slik at ingen Storebror kan trenge seg på dataene dine uten at du vet om det.

Før den fjerde timen var passert, var de igang med pristesting av idéen. De tre gruppemedlemmene fordelte påstand a, b og c mellom seg, og testet dem på adskilte personer de fant i og utenfor Oslo Plaza. 160 kroner er for mye var den unisone tilbakemeldingen fra noen folk i farten.

Hint nummer tre: En Lean-startup er ikke det samme som et (kort) prosjekt. En Lean Startup er skikkelig langvarig om idéen er god. Men læringen kommer fort. Det er derfor vi lever så lenge.

En Lean Startup kan forøvrig være kortvarig, men allikevel en suksess, hvis vi dreper dårlige ideer raskt og sparer moderskipet for feil bruk av tid og penger.

“Vi vil at du tar bilde av din faktura og sender den til oss på mail, så legger vi den ut i en Dropbox-folder for deg.”

Det er begrenset hvor fancy et eksperiment kan være når man har seks timer til rådighet på en workshop. Allikevel kan tidlig dialog fremkalle de utroligste tilbakemeldinger. Spesielt når vi kommer i prat med personer som ikke kjenner oss. Gruppen “Handsome and the douche” sin ide var et “Dropbox for fakturaer”. Det første de lurte på var om bedrifter i målgruppen var villige til å gi slipp på de fysiske fakturaene. På en time fikk de ringt fire daglige ledere eller økonomisjefer og spurt dem om behov og villighet til å ta i bruk nye verktøy.

Eksperimentene i workshoppen på Smidig 2014 var altså dialogpreget. Slike eksperimenter er imidlertid bare begynnelsen. Å validere antagelser trenger nødvendigvis ikke, og bør helst ikke, ta mye tid, uansett hvor vi er i prosessen. Produkter som bygger på programvare har unike muligheter til å formes for læring. Dyktige fagfolk klarer å få små features i produksjon, sette opp analyseverktøy og gjøre justeringer fortløpende. Vi er da smidige, tross alt.

Den tidligere omtalte lyntalen fortalte altså om et prosjekt som fikk kritisk læring etter leveranse. De hadde begynt med en planleggingsuke for å kartlegge hypoteser. Deretter hadde de ukentlig presentert arbeidet sitt for kunde og brukere. Så ble produktet levert. Smidig og effektivt, helt klart. Men det er altså etter ferdigstillelse at eksterne krefter presser produkteieren til å trekke seg. Kunne de funnet ut av dette tidligere, og kunne eieren brukt investeringsmidlene anderledes?

Som en utenforstående kan jeg bare stille spørsmålet. For det er nettopp slike spørsmål som er kvintessensen for en Lean Startup.

Siste hint: Når en kritisk antagelse blir falsifisert, hvor lenge har du jobbet under den forutsetning at antagelsen var sann?

Ingen fasitsvar. Dropbox måtte utvikle i nesten et halvt år før de hadde første versjon av sin synkronisering på plass. Heldigvis ville folk ha Dropbox, og en demo-video på Youtube hadde tidligere gitt en viktig pekepinn på dette. Zappos solgte sko fra en lokal skobutikk på ebay på første dag. I en Lean Startup-workshop Telenor og Iterate kjørte i 2011 ble et produkt lagt ned etter bare to dagers eksperimentering.

Det kommer an på både forretningsideen og dine egne ferdigheter. Det krever kreativitet å “se” hvordan du kan eksperimentere smart. Det kan være ganske gøy å plutselig finne ut hvordan du kan “hoppe over” måneder med arbeid, og heller velge en raskere vei til mål.

Smidig er fortsatt her som en viktig del av hvordan vi jobber. Det finnes mange gode, smidige prosesser der ute, flere av dem har vi hørt om på Smidig-konferansen i en årrekke. Så husk: Selv om Lean Startup er noe nytt, trenger du ikke rename backloggen din til “hypoteser” og kalle prosessen Lean Startup. Vær stolt av smidigprosessen din, og bruk den der det passer.

Deltagerene på workshoppen var nybegynnere på Lean Startup. Det var ingen hindring. Læringen kom raskt, var verdifull og ga nye perspektiver. Vi ønsker dem lykke til videre med å finne ideen som vinner.

Da skal vi klatre opp på taket på Plaza og utbasunere det glade budskap.

Anders Haugeto (36) is software engineer, experiment designer and entrepreneur helping the customers of Iterate innovate faster. He shows intrapreneurs how lean thinking helps their mission in life – to disrupt their organization from within. Follow his tweets about entrepreneurship and experimentations here: @hauge2.

Lean Startup as an invisible hand

Torve Indahl on Please share your opinion on what prevents lean startups in enterprise


Business cases are in most large corp the key follow-up tool to measure your projects success and growth. When business managers do the traditional thinking and “lock” the business case at the project starting point, they then also lock or restrain the projects ability to learn and change. Eg. working with a norwegian telecom post acquisition for my 2006 startup in 2008, we where following the telecom´s 1 year old pre-acquisition business case and followed that path for 4 years. The company does not exist today. Many factors played in, yes, but fore sure the set path was one.

Working with lean startup for large and SME on a daily basis and as an MSc in Business, I frequently us this mindset (lean Startup) as an invisible hand. We don´t explain everything, we just use it. We change the business cases at every board/steering group meetings and wait for them to start asking questions about way there are all this changes. We are proud then to look them right in the eye and tell them “Sorry, we were wrong the last time“. We then show them the evidence from our market experiments on why we where wrong and let them in on the discussions on what to do next. Now you suddenly are on the road of trustchanges is expected and the board executives starts digging into if we are doing enough experiments….”what about the MVP then” (yes, they start using your words).

The best part is when our “success formula for new stuff” then becomes demand. Life is good