I made a square to indicate the phase we are discussing: the kick-start phase.

We didn’t want to make a wordy post, so what we are going to see is a tutorial of how we take care of the kick-start phase following Lean UX methodology with a client that doesn’t know anything about it.

Actually the workshop is divided in two and it is as explained by Jeff Gothelf but with some adjustements for our agency format.

Specifically, we are going to see:

1) Analysis Workshop

Participants: 3–7

Duration: 3–12 hours

Schedule:

Introduction

Problems (30 min — 1h)

Business outcomes (30 min — 1h)

Proto-personas (30 min — 4h)

User needs (30 min — 1h)

Hypothesis table (1h — 4h)

2) Design Studio Workshop

Participants: 3–7
Duration: 3h — 15h

Schedule:

Introduction

Drawing (30 min — 3h)

Presentation (30 min — 1h)

Discussion (30 min — 1h)

Decision (30 min — 1)

Let’s begin with some what and why, and then let’s dive into the practical thing.

Why run a workshop?

The Second reason is that the best way to start working with your client is to break down the wall between you and him which often perpetuates the dynamic of “I’m selling you something”. On the contrary, we’ll build this thing together. This brings a lot of benefits and puts the client in the position of paying for the toy he puts the hands on.

The third reason is that the client rarely has clear ideas and neither does he know quite why he is asking for a project to be created.

Is this project really going to help or generate money?

When do we run the workshop?

A client has arrived and is asking us to create an e-commerce platform (for example). He doesn’t know that 95% (personal stats) of e-commerce platforms published online without a strategic study fail.

Should we make him a quote and tell him we want X amount of money for the job?

We don’t, instead we run a workshop.

Because, maybe the best solution could be running a landing page, or opening a shop on eBay, or maybe something else.

How do we run a workshop?

We do the following, one after the other:

Analysis Workshop

Design Studio Workshop

How are we Lean UX?

These two workshops are kick-starting many Lean Loops, and they meant to be repeated at each iteration, with different and ever deepener topics.

It’s very important to have someone in your team covering you the budget management, basing on outcomes the work with your client. Otherwise, you will be forced to sell your work based on features, and this is not exactly Lean UX.

These two workshop, as I said, are totally picked from Gothelf’s Lean UX Book and readjusted as long as we kept experimenting them with my team and new clients.

By the way, the answer to “How are we Lean UX?” is “By understanding the Lean UX principles deeply”. Let me mention some important ones:

Cross-functional teamsBest medicine against waterfall.

Outcomes, not outputGetting out of the deliverable business.

Shared understandingCollective knowledge of the team discovered together.

No human being acting like web guruTesting is our guru.

Permission to failThe only existing way to learn.

And many others…

Let’s begin.

Meeting with the client

Before we begin we need to know the client and his project idea.

So we meet each other, and the client tells us about the project, and we speak about our work methodology.

Our speech is helped by a great Keynote’s presentation and faces the following crucial points:

No quotes, we ask for a budget

We work through MVP and iterations

We have to choose onestakeholder

We work Time & Materials

I am pointing this out because workshops and Lean UX goals are not going to work well without these aspects (we will soon dedicate a post about this).

Our presentation lasts one hour and it’s truly important in order to align the client with our way of moving.

Last but not least, in the meeting, we put uncertainty about the business strategy and the client’s idea, then we throw a workshop.

Proto-personas are like personas but without validation through research. Or better, validation occurs in a second moment. They were born from the need to begin work on a product immediately, not spending too much time on preliminary work.

Experience moreover teaches us that 90% of time proto-personas are well guessed, and UX Design work flows efficiently.

Once the proto-personas list is done, and many post-its are attached for each one:

We are going to give to each participant a different proto-persona, together with a template:

Through time we have discovered that the three columns below can be merged into “needs/frustrations” or just “needs”. However, I suggest to experiment and find your own preferences.

Each participant has from 30–90 min to design his proto-persona.

After that, alternately everyone presents his own:

In this (Italian) example above we have even divided user needs/frustrations into three more categories (of time):

Pre-experience

Experience

Post-experience

In the context of the visit at the Uffizi’s Gallery Museum has been perfect:

Pre-experience: I organise my visit

Experience: I do my visit

Post-experience: I come back home and I remember my visit

We haven’t been able to test this time splitting into other projects though, so we don’t know exactly if it fits always well.

5) User needs

Now we are going to select one, two or three proto-personas to focus on.

All together, re-reading proto-personas, we find the needs/frustrations which we judge more relevant.

We fill the part “user needs” with post-it related to these needs. We can divide again the whiteboard, or draw a line between the proto-persona’s post-it and his needs.

Did this, we are ready for the hypothesis table.

6) Hypothesis Table

Now let’s place everything we have done before, inside the Hypothesis Table.

Hypotheses are everything that is going to create the basis of the future phase of development (for those who are confident with Scrum, they are very similar to User Stories).

Here is the template of a hypothesis, built from the table above:

We believe we will

achieve

[business outcome]

if

[proto-persona]

solves

[user need]

through

[feature].

We will know we are right/wrong when we see this
[signal from the market/behavioural shift].

This is the most meaningful part of the workshop.

It tells us that we have been doing a work in order to result a list of features reasoned by both sides (user and business), and with a KPI associated.

KPI = “Key Performance Indicator”

It corresponds to the [signal from the market/behavioural shift] above.

What does it mean? We have written a Hypothesis Table. This means getting out of the requirements bad habit, where a client or a good UX Designer impose us what we have to do based on pretty anything.

Let’s be clear: at this point we neither have done pretty anything, but we created the basis to test and iterate throughout time on tangible and lean products. We created the basis to keep going monitoring KPI and taking decisions based on data.

Here we are claiming (in the form of hypothesis) that we are going to solve frustrations and achieve business outcomes through specific features.

And many other things like campaigns specially designed to do the KPI job.

Here is an example of hypothesis:

We believe we will

achieve

Increase of expiring food products selling

if

Max — usual customer (33 years old)

solves

Buy good products at low cost everyday coming back from work

through

Products Highlight in homepage

Targeted e-mail marketing campaign

Lead Nurturing on new segment of clients

We will know we are right/wrong when we see this
10% increase of expiring product selling, after one month from the first started campaign.

With this table the Analysis Workshop ends.

Design Studio Workshop

Participants: 3–7

Duration: 3h — 15h

Decription

Lots has been written about this practice, especially Google literature about Sprint Design.

However we haven’t been able yet to place Sprint Design sessions in a saleable package in our agency. Basically, they cost too much or anyway they are (just my opinion) better applicable in startup environments or one-product-focus teams ( this is an interesting post about this topic).

Therefore we rely on Design Studio sessions, also taken by Lean UX methodology, and certainly effective.

This workshop is about designing the product (screens, architecture, scenarios, etc.)

Schedule

Introduction

Drawing (30 min — 3h)

Presentation (30 min — 1h)

Discussion (30 min — 1h)

Decision (30 min — 1)

1) Introduction

Our workshop begins re-reading all the material produced in the previous workshop, specially the Hypothesis Table.

Each participant receives a proto-persona and a scenario, for example:

Proto-persona:

Max, labourer (33 years old)

Scenario:

Max hurts himself in the work place and has to request an appointment with the doctor.

Here is the big paper and the instructions:

2) Drawing

Duration:30 min — 3h

Participants have to draw:

Product’s architecture (app, website, etc.)

Example of usage of the product in his scenario

This should be drawn for at least two solutions (if you have assigned enough time to this phase).

Product’s architecture

Basically we are talking about the screens:

What often happens is that everybody get scared at the beginning, because they think they don’t have skills, but at the end you realise that everybody draw solutions one thousand times better then the UX Designer or whoever is running the workshop does.

Example of usage of the product in the scenario

This second task can be done with drawings, schemes, and everything which allows the participant to communicate an idea:

Duration

Generally we organise drawing during morning, and presenting ideas and solutions in the afternoon.

3) Presentation

Durata:30 min — 1h

One by one, participants stand up and present their solutions sticking their big papers on the wall:

4) Discussion

Duration:30 min — 1h

Both for the presentation and the end of all the presentations, we discuss solutions, and we move towards the final one (or ones) which we share and consider the rightest one. This is done by modifying, improving, and merging all the solutions. It is creative work and with a few rules.

5) Decision

Duration:30 min — 1h

Here we formalise the final solution (or solutions).

With this material Design Studio Workshop ends.

And now?

If we are at the first job with the client, we have to get some more analysis work done. They will allow us to estimate the feasibility of goals in time.

I know that big product estimates stay at the opposite corner of Lean UX principles, but client always need to know where they can arrive with a certain budget, and this is our current solution. If anybody knows how to avoid this please write a response let’s discuss good solutions.

Actually, consolidated clients don’t need this.

How do we set a budget?

You have two roads:

Basing your budget on features to implement

Basing your budget on outcomes to achieve

Challenges are:

Teaching your client to think with a Lean UX mentality (we run a good presentation to do this and teach the client to use tools like Pivotal, etc.)

Have a good part of your team (or initially one person) able to base a work on business outcomes.

Conclusions

There would be a lot more to write, and in the future we are going to speak more about everything which happens from now on, i. e. here:

While in this post we covered what happens here:

I am curious to know how other agencies and freelancers move in this context, and if this post have been useful.

Some final notes

Breaks:In every workshop it’s important to have breaks previously scheduled and communicated to the whole team (coffee, launch, etc.).

Time:Before proposing this workshop to a client I strongly suggest to test it with your own team, in order more than anything else test durations. In the past it has happened to me to manage moments of stress caused by impossibility to accomplish everything inside our schedule.

Rules:we suggest to forbid phones and laptops.

Everybody participation:who is running the workshop can encourage everybody to talk making them read aloud texts or asking them opinions.

Amir Ati

UX/UI Designer

He loves designing user interfaces with a focus on cleanliness and content priority. Inside the team, he has a role of junction between UX/UI Design and Front-End Development.