Writing Great User Stories to add Emotional Value

How writing the right user story creates better UX

I just completed a mini personal project and I wanted to share some thoughts on designing and developing a product around the users emotional needs. A simple shift in perspective can often lead to a much more solid design process.

The idea: an app to consolidate and simplify the management of multiple inbound finance streams. 

I had the idea from back when I was working as an office temp. I discovered that when you are not in employment with regular shifts, fixed pay rate and hours, it can be hard to keep in control of all the inbound finances and budget accordingly. I regularly had to sit down and calculate how much I was earning, tracking my varied hours against a fluctuating pay rate, deducting tax and travel costs in order to make sure I was earning enough to pay the bills, while knowing how much extra disposable income I was making. Plus there were tons of payslips floating around — some digital, some paper, some weekly, some monthly. 

For me, money (or lack of it) can be a big source of anxiety, and so it was a time-consuming task of reassurance for myself to go through all these calculations. It was Necessary, but a total Chore-Bore.

I also realised that I could not be the only person out there to feel this way. Plenty of people have to juggle more than one job, and many have other pressures on their time such as family or kids to support, leaving even less time for life-laundry. So the idea was to design a product that could simplify this process and help people working multiple jobs, irregular shifts or seasonal work, to keep a track of their hours and earnings. 

Part 1 — defining the solution

Having decided on the idea, I needed to think more about the problem and define what the core functionality should be that would solve this problem. Immediately I started listing potential features and tasks that the app would be able to do:

  1. “Create job type”: input pay rate, tax, overtime rates, deductibles, tags, pay schedule, category

  2. “Log hours”: select job type and manually enter start/finish times, start/stop clock for automatic entry, or import hours from a calendar e.g. iCal/google calendar

  3. Calculate expected pay: display basic details of hours worked of each job on the main page, with link to full details, and a means to edit/correct hours

  4. Export data as PDF/spreadsheet/report etc

  5. Could also include a way to request/send money via PayPal, or auto input into an invoice template.

Beyond this, it needed to feel secure and reliable (given that salary data is particularly sensitive) so it would need to be password protected. It was important to me that it felt simple, easy to use, and not a chore, so inclusion of playful features and gamification opportunities should be embraced.

A rough idea for the opening flow of the app — swipe in any direction from the sign in or create account buttons to push the dollar bills out the way and complete the action… keeping it playful!

Part 2 —  designing the look and feel

I created some design iterations that explored the core functionality I chose the day before. I considered a few ideas for how a user flow might work. It seemed that I needed could be as simple as a dashboard with a menu. All the key actions would then feed off the main menu. 

I had a good rough idea how I wanted the app journey to start:

A rough idea for the opening flow of the app — swipe in any direction from the sign in or create account buttons to push the dollar bills out the way and complete the action… keeping it playful!

But as for the meat of the app, I ended up playing around with several different iterations. They each had different strengths and weaknesses, and so I continued to play around with varying combinations of features until I had 5 designs which looked like good starting points for further development:

Five rough iterations of the main “dashboard” of the app

These paper designs are actually only slightly larger than my iPhone so I could instantly see and feel what was better in hand. I liked the idea of a central button that could pop up with menu choices at the touch of a thumb (I personally hate having to switch the way I hold my phone in order to tap a button at the top of the screen or stretch to the far left or right hand corner of the bottom of the screen).

I kept in mind my mantra of what I thought I was trying to achieve: “a means to manage and display earnings”. But in reality it was a little more complicated that. 

Part 3 — review and refine

Day 3 was when things started to get interesting. I needed to critically evaluate the designs and figure out if they were working as prototypes. 

Although these designs did indeed fulfil the basic functionality criteria, I didn’t feel like they went far enough. They weren’t quite as clean or simple as I had hoped. I wasn’t sure that displaying more information was better, but equally, a certain amount needed to be included. I knew something wasn’t quite right.

I took a long hard stare into the abyss and realised: None of the dashboard designs I had conceived were “wrong”, but equally, and crucially, they didn’t add any emotional value either. 

The reason? I wasn’t really thinking about my original motivation, the feeling of frustration, or the struggle of why I wanted to create this product in the first place!

When I spoke about this with a friend, they sent me an excellent article by Alan Klement on replacing the user story with the job story; a very subtle but significant difference which helped me see where I had been going in the wrong direction.

My original user story had been:


As a [persona]

very busy person juggling many jobs

I want to [desired action]

have help managing and quickly viewing my finances

so that [expected outcome]

I can keep track of how much I am earning.


As Klement points out in his article though, traditional user stories like this don’t really get to the core of the problem. They make assumptions about the user yet leave no room for context or emotional clues that help inform how the product should behave. 

To design an effective solution, we need to understand the struggle. And in this particular example, the traditional user story format simply did not convey the actual issue of why I was spending all that time wrangling spreadsheets: the anxiety of “do I have enough money to pay my bills?” the worry of “how much money will I have left at the end of the week to buy food?” and the painful query of “do I need to pick up an extra shift to reach that earning goal?”

Thinking in this way changed how I viewed this product. I rewrote my user story using the format Klement suggested:


When [user situation, moment of frustration]

I am worried if I am making enough money

I want to [motivation, how progress is visualised]

check my earnings quickly and easily,

so that [expected outcome, how life is better]

I can relax and be reassured that I have the knowledge to make the right financial decision (for example, choose to buy groceries or go out for dinner)


It was a real lightbulb moment: fundamentally the purpose of the app was not simply a administrative tool, it needed to be able to do something far more valuable: assuage fears. 

blog 1.jpeg

By thinking in terms of earning targets rather than just displaying data, the value-added is the ability to help a user make judgements over their finances. Just smashed a target? Then yes, bring on the trifecta of C’s: Champagne, Caviar and Courvoisier. Running behind on a target three-weeks running? Well, it’s probably time to stay at home and eat CostCo cat food until you can pick up an extra shift. 

I went back to the drawing board and reworked the dashboard — instead of being data heavy with dates, locations, hours, job types etc — it simply needed to say whether I was hitting my personal earning goals, a function I would add in to the profile.

This project will still need further development of course, but I’m much happier with the direction it is going in now I know it is adding emotional value.