v0.01 — stardate

Job stories instead
of User stories.

At Pixelpillow, we've been working with User stories for years, known to most readers as a way of defining - from the user's perspective - what functionality software should contain: 'as [user], I want [action] so I want [outcome].'
At Pixelpillow, we increasingly noticed that this method was inadequate. We therefore switched to writing Job Stories.

Why don't User Stories work?

User stories have been standard practice in product development for decades. But we systematically ran into the following problems:

  • User stories assume a 'type' of user. They are often based on predetermined 'personas (John, 42 years old, installer, 3 children, etc)'. But personas are not 'real' people, and so in establishing them we make all sorts of assumptions about users. And as great philosopher Steven Seagal once said, 'assumption is the mother of all f*ckups'.
  • Although never conceived for that purpose, personas have become an easy excuse for many organizations to avoid talking to real users.
  • The user story describes what the user wants, but not why the user wants it. So the UX designer has very little context to determine which solution will help the user the most.
  • Data analysis (e.g. at facebook) showed that the behavior of different types of user was often more similar than different. So the [user] piece of a user story doesn't matter that much.

In short: a user story makes too many assumptions about the user and gives too little information about "why" a user wants to perform a task.

The Job Story as a better alternative

Since User Stories didn't work, we switched to Job stories. Job stories were developed by Intercom, and stem from the "Jobs To Be Done" philosophy, which assumes that users don't want features or products, but that they want a problem solved. Job stories are then a way of identifying these "problems" and describing them as user tasks.

Intercom itself describes it as follows:

If we understood the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a great outcome looks like, we were confident that we would be building valuable product for our customers.


In the shape of a Job Story, this looks like this:

  • When [situation: what is the user's context]?
  • Do I want to [task: what does the user want to do?]
  • Because [motivation: and why?]
  • So that I [outcome: what does the customer want to achieve?]

A small difference with a big effect

At first glance, a "job story" looks pretty much like a "user story. So why does this small change make such a big difference? That's because Job stories shift the focus from customer-oriented to task-oriented. With that, we no longer focus on a - often fictional - user, but on the task the user has to do. This makes the story more objective, more concrete and - if we write it well! - much more context about why the user wants to perform this task.

Writing a good job story

Writing job stories is not easy. But if you do it right 1, it yields a useful, practical list of tasks that are easy to translate into concrete features and components.


Naming what goes wrong is easy. So don't ask users what they want, but what frustrates them in performing their task.

Don't write: What is the number one need when doing your tax return?

Instead write: What is your No. 1 frustration when doing your tax return?

01.Talk to your users

Always start with real people. Find out who you are developing the application or site for and find people you can interview or - even better - observe performing their tasks. It is crucial for your product or service to find out what problems your users are trying to solve, and why.

Ask your user two questions:

  • what task do you want to perform?
  • what is your biggest frustration in doing so?

02.Rewrite your users' input into Job stories

Here it is important that in addition to naming the task (do I want), you also clearly name the situation the user is in (where and when) and the motivation (why does the user want to perform this task?).


The Job story has no option for naming a type of user because we said it is not relevant. But what if there is a very clear distinction between types of users and more importantly, what if they have to perform clearly different tasks? For example, in a system with a backend (administrator) and a frontend (consumer)?

In that case, you are not actually talking about types of users, but about "roles," which you can think of as the situation in which the user finds himself. You can easily include these in the Job Story, in the following way:

When I [in my role] as content administrator can't finish my blog article right away, I want to be able to save it as a draft, so that I can finish it at a later time.

When writing user stories, we always tried to be as concise as possible, but that is precisely not the intention when writing Job Stories! After all, we want to give the UX designer as much context as possible about the situation the user is in at the moment he or she wants to perform the task.

So don't write: When I'm hungry, I want,
But instead write: When I am hungry, almost running late, and don't have time to make my own food, I want ...

03.Translate the Job Stories into design solutions

Because Job Stories are more concrete than User stories, they lead faster to the right (design) solution and it is easier to estimate in advance how much time it will take to realize them. This helps prioritize functionality (is it worth this effort to solve this problem for a user?) and makes the final product more user-friendly and valuable to the user.

Captains log

Layout en animatie changelog
Breedte en positie changelog geanimeerd obv vw
In gsap zelfde positionering systematiek hanteren als in je stijlsheet, anders onverwachte effecten. Dus niet in stylesheet: left: 100vw, en dan in gsap x: 300.
Scrolling changelog layover fix codepen) met behulp van GSAP DrawSVG plugin
Bij layover niet handig om main content alleen opacity te geven omdat deze klikbaar blijft wanneer er geen DOM element overheen ligt.
Ontwerp scribbles homepage.
Kleuren zijn moeilijk.
SVG animaties homepage
Geprobeerd svg animaties te implementeren in eleventy
Fail. Lijkt erop dat 11ty bij build svg opbouw veranderd. Wordt vervolgd.
'Scribbles' svg's geanimeerd codepen) met behulp van GSAP DrawSVG plugin
DrawSVG kan geen externe svg's animeren. Inline svg's kunnen niet gebruikt worden als background en dus niet als pseudo element.
Ontwerp scribbles homepage.
Kleuren zijn moeilijk.
CSS Grid
Stylen changelog table gebruikmakend van CSS Grid
Positionering met CSS Grid.
Ontwerp changelog table.
Wat in ontwerp eenvoudig is, is in techniek soms moeilijk.
Implementatie van nunjucks templates en partials voor footer, header, content en changelog.
Dat foutmeldingen in terminal een boel tijd besparen als je ze tenminste ziet. Hoe je zowel .md als .html bestanden kunt gebruiken als basis. Wat frontmatter is.
Verdiept in templating languages.
Hoe templating languages (in dit geval nunjucks en liquid) werken en hoe je een basisstructuur opzet.
Menu, cahngelog en links geanimeerd.
GSAP x:0 is not x:0 maar x:0 vanaf startpositie element in de DOM.
Opzetten typografische basis
Implementatie fonts en styling responsive typografie.
Een 'Fluid typography' systeem opzetten. Tekst gewrongen en styling homepage.
Typografie laten schalen tussen breakpoints gebruikmakend van 'clamp' in css.
Opzetten framework personal site
Eleventy opgezet als static site generator.
Hoe je je eleventy inricht mbv terminal.
Gitlab setup
Wat een SSH key is en waarom je deze nodig hebt. Hoe rechtstreeks te committen vanuit VS Code.