“Knowl­edge isn’t pow­er until it is applied.” — Dale Carnegie

This year, no top­ic has influ­enced me as much as Lean UX. At the begin­ning of the year I decid­ed to grad­u­al­ly put my the­o­ret­i­cal knowl­edge into dai­ly prac­tice. As the year is slow­ly com­ing to an end, I would like to share my thoughts, find­ings and expe­ri­ences with you.

First of all: It’s never too late to correct the course!

I often had to lis­ten to sen­tences like “It’s too late” or “We should have done that at the begin­ning.” In the con­text of dig­i­tal prod­ucts and lean man­u­fac­tur­ing meth­ods, these state­ments — for me — lose more and more of their correctness.

Once, we had a project that strug­gled. We tried to under­stand why. We did ret­ro­spec­tives, checked our tool­chain, etc. and did not come to any result. Then, we changed our focus and we iden­ti­fied that many of the prob­lems we had were not caused by WHAT we were doing, but by HOW we were doing it.

Short­ly after that, we had to decide: Should we take a dif­fer­ent path (like alter­na­tive approach­es and meth­ods)? Or do we stay on the track defined at the begin­ning — know­ing that it is get­ting bumpi­er and bumpi­er?
The fact that we were already in the process made the deci­sion not eas­i­er. And even if it was bumpy, we had already invest­ed pow­er (time and mon­ey) and gen­er­at­ed some out­put. It was like we were feel­ing the Con­cord Effect.

---

It’s about doing it together

In most cas­es, you cre­ate prod­ucts, not for your­self and not by your­self. You will need the trust, com­mit­ment, and sup­port of oth­er peo­ple (and depart­ments). So Share your vision and thoughts: no long e‑mails, big meet­ings, Jira-tick­ets, or Excel sheets. Just go to them. Have a chat and inte­grate them as much as it is pos­si­ble. Show them how valu­able they are. You will see, most peo­ple are will­ing to par­tic­i­pate. Get them on board.

Prod­uct teams are most effec­tive if they work togeth­er as close­ly as pos­si­ble. Seize some Space ( or a room), hang the walls full of the things you’ve made and you’re proud of. Talk about it with every­one who pass­es by.

Remote, how­ev­er, should remain the excep­tion (like if you want to do Home-Office or some­thing like that), but not the rule.

In the end it is the peo­ple who cre­ate prod­ucts — not meth­ods, process­es or tool.

---

Assumptions are welcome

If you want to avoid end­less dis­cus­sions and design-by-com­mit­tee rounds, gath­er just enough infor­ma­tions to form a hypoth­e­sis, then trans­fer it into an exper­i­ment and start learn­ing — through real mar­ket feedback.

As explained in the Book Out­comes over Out­put (by Joshua Sei­den), a basic hypoth­e­sis has two parts:

1. What we believe
2. The evi­dence we‘re seek­ing to know if we‘re right or wrong

Frame the prob­lem in such a way, that it almost begs for the next step to be an exper­i­ment or research project, to see if your hypoth­e­sis is right or wrong.

The Lean UX Can­vas (by Jeff Gothelf) is an excel­lent tool for trans­lat­ing busi­ness prob­lems into assump­tions, hypothe­ses and experiments.

---

Stay small and lea®n

There is a com­mon (sequen­tial, lin­ear) approach for devel­op­ing soft­ware and it works (more or less) like this:

Three or more months of gath­er­ing require­ments to iden­ti­fy the whole prod­uct scope.
Three more months of con­cept cre­ation fol­lowed by anoth­er three months of User Inter­face and Visu­al Design.

Six more months for devel­op­ment and two for bug-fix­ing test­ing.
Final­ly: the Go-Live. Sounds like a no-brain­er, right? Unfor­tu­nate­ly only in theory.

Now, let us put in some real­i­ty to make it more practical:

Add a bunch of dis­cus­sions about chang­ing or mis­lead­ing require­ments, per­son­al taste, reject­ed approvals, and nev­er-end­ing feed­back-cycles. Then mul­ti­ply it by the sus­tained pres­sure affect­ed by reach­ing a dead­line (and a scope) that was deter­mined and esti­mat­ed at a point when most things are uncer­tain: at the beginning.

The Result: You prob­a­bly will not meet the dead­line, not reach the scope and the bud­get will dou­ble. And — even if you launch a usable And work­ing prod­uct (after 1,5 years) — you have to fear that nobody will use it.

Pure pain!

But how to deal with such prob­lems?
The answer: Start small and learn.

For exam­ple: If your most sig­nif­i­cant fear (risk) is to cre­ate some­thing that — in the end — nobody wants, it should be your high­est pri­or­i­ty to ver­i­fy if there is a poten­tial user group or mar­ket for your prod­uct or Ser­vice before you start build­ing it.

How? Imag­ine a banal 3‑minute video on a land­ing page demon­strat­ing the prod­uct as it is meant to work. Tar­get it to a com­mu­ni­ty of ear­ly adopters and learn. That is — more or less — the way Drop­Box started.

---

There is an alternative to traditional personas

Per­sonas are user mod­els show­ing the char­ac­ter­is­tics of per­sons in a tar­get group. They can, for exam­ple, help a devel­op­ment team to put them­selves in the posi­tion of poten­tial users to bet­ter under­stand and rep­re­sent their goals, behav­iors, pref­er­ences and expec­ta­tions through­out the design process.

Some­times, per­sonas are viewed as some panaceas.

There is a tra­di­tion­al way of cre­at­ing per­sonas: at first you have to dive deeply into a phase of user and mar­ket research.
Next, you will be doing a lot of sur­veys. Even­tu­al­ly, this might end up in loops of eval­u­a­tion to prove the data’s accu­ra­cy — and some­times about the struc­ture and design also.

Lean (or pro­to­type) per­sonas are slight­ly different.

Lean per­sonas are cre­at­ed fast. The deep­er you dive into your tar­get groups by doing small inter­views and test­ings — dur­ing the design process — the clear­er the per­sona becomes. And instead of advanced arti­facts designed to be declared as fin­ished (at some point), lean per­sonas are seen as liv­ing objects using a sim­ple and flex­i­ble framework.

---

Sketching (and prototyping) is king

Sketch­es are help­ful when it comes to shar­ing ideas. Many peo­ple assume that they are not good at sketch­ing things. And that’s ok. Because that is not the point. You don’t have to be good. As long as you’re able to draw lines, cir­cles and squares, you’re in!
And it is not about beau­ty! It is about bring­ing your thoughts to paper, so you’re able to share them. If you still feel that you can­not sketch, try it out.
And if you want to improve your sketch­ing skills, there are numer­ous books, Youtube videos and arti­cles wait­ing for you.

Pro­to­typ­ing gives you the pos­si­bil­i­ty to make ideas tan­gi­ble. It can be a tool that enables stake­hold­ers to make reli­able deci­sions — quick­ly and ear­ly. And you can use it to val­i­date assump­tions in qual­i­ta­tive interviews.

Kinds of prototypes

• Sketch or Paper Pro­to­type: 
  This is the most abstract form of pro­to­typ­ing, in the form of hand-drawn sketch­es or written/painted sto­ry­boards — and some­times nap­kins too ;).
• Bastler Pro­to­type:
  It isn’t pret­ty and made with­out claim to Design Guide­lines or cor­rect­ness of the content.
• Craft Pro­to­type: 
  Nor­mal­ly bet­ter look­ing and work­ing than a Bastler-Pro­to­type, this one con­tains more details (like busi­ness log­ic, design require­ments, or content).
• Pre­series Pro­to­type: 
  A pre­series pro­to­type is almost like the final man­u­fac­tured prod­uct. In shape, size, func­tion and log­ic. It’s the last step before get­ting into pro­duc­tion. It’s also a func­tion­al blue­print for the devel­op­ment hand­off — Instead of man­u­al­ly mea­sured screens and end­less con­cept descriptions.

Validation variants

• Self-val­i­da­tion: 
  As a Design­er, we do this method in our dai­ly work. By using dif­fer­ent pro­to­typ­ing- and wire­fram­ing soft­ware (like Flinto, Prin­ci­ple, Adobe XD, Axure, etc.), paper-pro­to­typ­ing, video pro­to­typ­ing, mod­el­ing, hand drew sketch­es and HTML-snip­pets — Also to ensure val­i­da­tion for our selves.
• User-val­i­da­tion: 
  In the first case, our Con­cept-Solu­tions are the­ses. So we have to val­i­date these hypothe­ses against real user and con­text and to gath­er infor­ma­tion about back­ground and needs. To do this, we use Meth­ods like User-Test­ing and Interviews.
• Busi­ness-val­i­da­tion: 
  If we talk about KPIs and Busi­ness-Log­ic, we are also able to check ear­ly the achieve­ment of them, col­lect stake­hold­er feed­back and enable clients to make a busi­ness deci­sion even before launch­ing the prod­uct ear­li­er on. It is also an excel­lent basis for discussion.
• Tech­ni­cal-val­i­da­tion: 
  To avoid nasty sur­pris­es in pro­duc­tion, we are able to clar­i­fy tech­ni­cal ques­tions or find tech­ni­cal solu­tions early.

---

Create a shared understanding!

I have rarely seen such pow­er in some­thing, as I see it in shared under­stand­ing.
Many devel­op­ment teams have Jira, Excel lists or sim­i­lar tools to keep track of the back­log. Often, one per­son is respon­si­ble for the back­log, writ­ing Epics. Some­one else has to break these Epics down and has to add the details and accep­tance cri­te­ria. Still, oth­er peo­ple are assigned to esti­mate and devel­op this sto­ry, based only on the User sto­ry descrip­tion.
One major issue lays in a lack of com­mu­ni­ca­tion. As team mem­bers will most like­ly have dif­fer­ent inter­pre­ta­tions and expec­ta­tions, a shared under­stand­ing should be estab­lished right from the start of the project.

User Story Mapping

With User Sto­ry Map­ping, you can cre­ate a back­log togeth­er that makes depen­den­cies, risks (spikes) vis­i­ble and extend­ed by sketch­es and infor­ma­tion. It is not a ver­ti­cal list on a screen. It is a flex­i­ble matrix on the wall.

The most impor­tant thing: do this togeth­er with all the rep­re­sen­ta­tives of the dif­fer­ent prac­tices and crafts. Cre­ate a shared pic­ture of what to devel­op in the next release and to iden­ti­fy what is need­ed to ensure it.

 

 

---

You can release running software earlier

“The world as we have cre­at­ed it is a process of our think­ing. It can­not be changed with­out chang­ing our think­ing.” — Albert Einstein

In the begin­ning, it was hard for me to under­stand how to release work­ing soft­ware on a week­ly or dai­ly basis. Moritz, a col­league of mine, then told me his expe­ri­ence of work­ing in a ful­ly agile company:

„The team came togeth­er for an hour in the morn­ing. They took the sto­ry, ideat­ed togeth­er on a flip-chart (to cre­ate a shared under­stand­ing) and imple­ment­ed it until the evening. It is pos­si­ble, when you break down your sto­ries until you can devel­op them in one day (or less).“

The aim is to break down big­ger sto­ries so that the real scope is made clear. Small sto­ries are bet­ter to imag­ine. For exam­ple, if you have the sto­ry I want to search for files, what is real­ly behind it in detail becomes appar­ent first, when you start to talk about it. So break them down!

Break down your stories (and tasks) — to ensure smaller badge sizes

The sen­tence I hear most often by doing break­downs is: “That’s more com­plex than I would have thought.” Anoth­er one? “Now, we can see which depen­den­cies we have.”

I’ve heard sev­er­al dif­fer­ent names for sto­ry sizes like Sto­ry points. Besides, teams also like to use T‑shirt sizes (S, M, L) or ani­mals (mouse, dog, cow, ele­phant). In this case, the biggest unit (L or ele­phant) indi­cates a sto­ry that is too big to be esti­mat­ed. So you have to break it down until you can esti­mate it.

I pre­fer a slight­ly dif­fer­ent mod­el. Instead of esti­mat­ing a sto­ry and giv­ing it points or names, we try to break down every sto­ry until it is small enough to be real­ized in one day (or less).
We also use sto­ry map­ping for this. We (the fea­ture team) trans­fer sto­ries from the flex­i­ble back­log and detail them. We enrich the small­er sto­ries with infor­ma­tion, ideas, sketch­es, unknowns, alter­na­tives and risks.

---

Risks are a part of the game

We live in a world full of uncer­tain­ties. And because of that, it’s help­ful to iden­ti­fy risks already dur­ing the release plan­ning. If you rec­og­nize a risk, don’t ignore it. Deal with it! Make it visible!

An exam­ple: On one of our last work­shops, we assumed that the theme Reg­is­tra­tion & Login is a No-Brain­er. Done a thou­sand times already, so it’s prob­a­bly easy to break the item down into small­er sto­ries. Then, dur­ing the release plan­ning ses­sion, we iden­ti­fied unclear depen­den­cies to the inter­face of the 3rd par­ty provider. None of us could eval­u­ate it. And we were unable to assess the top­ic in terms of scope or time -> A risk of not reach­ing the release date. So we declared it as a Spike (a theme or a sto­ry with risks/unknowns that have to be val­i­dat­ed quickly).

---

Use a release forecast instead of Gantt Charts and Deadlines

Esti­mat­ing long-term projects at the start is a pain. Today we are aware of the fact that it is not pos­si­ble to pre­dict the future and to iden­ti­fy all risks, depen­den­cies, and the full scope at the begin­ning, on the one hand and being inno­v­a­tive and flex­i­ble at the same time on the oth­er hand.

Although there will be some­one in most projects, who needs an assess­ment of what is ready, in progress or planned next, many find this infor­ma­tion annoy­ing. And if you don’t see any impor­tance for your­self, some stake­hold­ers and project spon­sors might will need this infor­ma­tion to cre­ate reports and sta­tus to their superiors.

In his book #NoEs­ti­mates, Vas­co Duarte describes a tool called Release (or back­log) Fore­cast. You use can the Sto­ry-Map (Flex­i­ble Back­log) as the tem­plate for deliv­er­ing a release fore­cast, for stake­hold­er, showing:

• What will we pro­vide in the next four weeks (sprint backlog)?
• What (most like­ly) will we deliv­er in the next two months (Release Backlog)?
• And what will most like­ly be not deliv­ered in the next two months (Prod­uct Backlog)?

See this tweet from Vas­co (based on Chaos Report, Casper Jones ‘Jour­nal of Defense Soft­ware Engi­neer­ing’, McK­in­sey & Uni ‘Oxfords Study of Large Scale IT Projects’ from 2012 and his Data):

“We are per­fect­ly able to Esti­mate the future.

We are so good that: 60% time over­runs is the aver­age; 66% of large IT Defense projects are late and/over bud­get; 17% of large projects go so bad they threat­en the sur­vival of the company!

Yeah, we are ABLE to esti­mate #NoEs­ti­mates”

— Vas­co Duarte

 

Vas­cos’ book is filled with sta­tis­tics and exam­ples explain­ing why the tra­di­tion­al way of esti­mat­ing is not the best. Most­ly it is not about the What but about the How. So, if you want to cre­ate prod­ucts or ser­vices that mat­ter, be aware that you have to be flex­i­ble to changes — Because the world turns.

---

Get out of the Building

When it comes to con­duct­ing qual­i­ta­tive inter­views to get insights, GOOB (Get Out Of The Build­ing) is prob­a­bly the most effec­tive method you can choose.

Go out and go where the peo­ple them­selves are sit­ting. Spend a day with the peo­ple who use the prod­uct or ser­vice, or also talk to those whose job depends on it.

Enriched by par­al­lel sur­veys and quan­ti­ta­tive research, you get a bet­ter pic­ture of the usage of the prod­uct or service.

It also serves you to val­i­date the per­sonas, which — ini­tial­ly still based on assump­tions — pro­vide a sharp­er and more accu­rate pic­ture of the user groups.

 

Sometimes it is frustrating

Even though I am still at the very begin­ning of my lean-ux-jour­ney, I try to inte­grate lean think­ing — step-by-step — into my dai­ly activ­i­ties. Some­times more, some­times less suc­cess­ful. And some­times it is frus­trat­ing as well. For exam­ple, when I iden­ti­fy waste in my own actions — usu­al­ly afterward.

Now, I am very curi­ous to see where the jour­ney will lead me, but also us as a team In 2020.

Spe­cial thanks to Maeve O’Flynn, Chris­t­ian Kil­ian, Fabi­an Möller, Fabi­an Gaber, and Jan Sagemüller for their help, feed­back and patience (with me).

Thx for reading 🙂

Feed­back on this arti­cle is high­ly appreciated.

This arti­cle is also avail­able on Medi­um