Lean product design at Forecast

Lean product design at Forecast


My role

  • UX Research

  • Leading Design Workshops

  • Sketching

  • Mocking up and prototyping

  • User Testing

The problem

I joined a startup three months before the product was going live. I faced a major dilemma: How do I introduce Design Thinking and UCD in a Startup environment whilst continuously bringing value? What's more important, usable or useful? What is the definition of "good-enough" when you are pressed to "release first"? 

I had to put aside some of the UX practices that worked in less high pressure environments and adopt a more pragmatic approach.

In this chapter, I focus on how I used research to drive the product design - see here for the visual design principles I devised alongside this work, and here for my approach for building a particular feature.


0. Learn

Interviewing stakeholders

The first thing I did was to talk to the main stakeholders to really understand the business and product - the founders. I interviewed them separately to see how/if their vision about the product and users differed. It was important, though difficult, at this stage to loose them up so that they wouldn't start jumping to offering solutions without stating the problems they were trying to solve.

Together, we created comics and storyboards about what we thought was making the product different from the swarm.

Personas and interviews

From the conversations with stakeholders, we identified few target users and I went out to various digital agencies to interview Project Managers and follow them around.

I kept the interviews goal-oriented as I wasn't interested in demographics or other factors normally used to build personas. I wanted to know their pains.

Based on these early interviews, I created a set of initial personas. However, soon it became apparent that there were as many types of personas as Project Managers I'd interview. It was difficult to try to categorise and box them into personas, when, really, what was important was to understand the problems they were trying to solve and how would they approach them. Patterns across a continuum of behaviour were easier to map. 


The best thing about talking to users at this stage was how frustrated many of them seemed to be with their current tools.

My day is a fractured experience
We need a bridge across all our tools
Just... fix Project Management!

Based in this initial research, we decided to frame our hypotheses as JTBD. Click here for a concrete example of how we build the scheduling feature.

Understanding the project lifecycle


Project Managers...well....manage projects. So it seemed key to understand some of the methodologies that the interview subjects were using on their day to day work. And so, parallel to the qualitative research, I read a lot about project management methodologies and build process maps.

Through these interviews and contextual research, we created an "ideal project life-cycle" and mapped which team members were involved at what stages as well as all the pain points as opportunities for an app.


1. Build


Working in a small startup team it was important that everyone was aligned as to what we were building, that everyone felt they had a voice in the product, and that the right information was extracted from expert stakeholders.



I facilitated workshops at different levels

  • Planning sessions (prioritisation, backlog planning, mapping)

  • Knowledge sharing sessions (HMW, Assumptions gathering…)

  • Ideation sessions (collaborative sketching, futurespectives)

  • Regular retrospectives


I would normally start with a warming up exercise inspired by improv theatre, or improv drawing, so that I could get the team to think creatively. After the initial brainstorming, we would group the ideas using affinity mapping and prioritise where we wanted to start. I made sure each workshop had clear objectives and that actions were assigned.

Framing Questions

This map was the result of a series of workshops around building the task management feature. Based on the personas and the themes identified from the ideation sessions, we divided the user needs into goals, activities and tasks. We mapped the activities step by step, imagining an ideal system and then we had another group session where we prioritised the paths we wanted to build first.


From design to code

Most of the time I was running half a step in front of the developers, and I sacrificed providing high fidelity designs in favour of handing out quick sketches and working closely with the devs as they were building it. That way, I had more time to spend in research and testing. 

The beginning was hard, and communication was sometimes broken, but it became easier as we developed a design system together, to complement the rough sketches.

2. Measure

Paper or Sketch prototypes, or even simple code prototypes were built to test hypotheses or ask questions about features that were not yet built and guide conversations.

Design hypotheses were frames as questions and built into the prototypes to validate or invalidate our theories.



3. Learn (again)

We performed regular user testing sessions - sometimes in the office, more often at the project manager's site - where we incrementally tested what we were building, and the insights made it to the backlog. 

Another important source of learnings came form the customer support team, both from intercom issue tracking, to phone calls and sales demos. Whilst these were second hand insights, I had regular catch up with the sales team in order to understand what were the most pressing issues with the users and clients.