This article talks about a different approach to capturing product requirements and describing the problems a team is trying to solve. It describes user story as too limiting, perhaps too granular. The story loses the meat of the problem being solved and the setting in which it is being solved. The author proposes a new story format called a job story. A job story intends to capture more context around the user, their needs, and how they’re interacting with the software.
This kind of challenge to the user story format is not new – nobody enjoys writing user stories because they’re fairly artificial, often too obvious, and it can feel less than valuable. The solution certainly addresses aspects of the challenge, but I see the author’s suggestion as overly blunt. A key part of the agile manifesto for me, is as follows
I was in a fairly stressful meeting a couple of weeks back and to break the tension someone put up a YouTube video. The meeting room had a few very smart and talented engineers in it, one of which put the video up for laughs. Here’s the video – go ahead and watch it if you haven’t already. You don’t have to sit through the entire thing, the first minute is enough.
So put aside the fact that their marriage isn’t going to last (because the husband obviously has very little regard for his wife). Put aside the fact that you’re probably boggled at the idea that the question wasn’t easy to answer. Take a closer look at what’s going on for the girl struggling to answer the question. She keeps going back to a frame of reference she’s familiar with in trying to answer the question.
She has a very obvious frame of reference or, in some ways a mental model, of how to think about speed and distance. It is entirely based on how fast she can run.
I’m not going to say that I didn’t smile when I first saw the video, but after a minute or so of watching her struggle I started to try to understand how she was approaching the problem. I like to think this was the user-centric analyst in me. She has a problem she is trying to solve and she has a very strong mental model that she is trying to use to solve that problem. I’m not going to say that we need to design software for this particular mental model. What I am going to say is that we, as software designers, engineers, and producers, should never guess at a user’s mental model. Sometimes their frame of reference turns out to be laughable in our minds. However if we can tap into it and understand it, then the solutions we design will be so, so much the better for our efforts.
So giggle if you must, but take this as a cautionary tale – sometimes a user’s mental model is extremely unexpected. The best way to understand our users is to go meet with them and watch them do work. Don’t assume you know how they think.
I encountered an example recently where a UI Golden Rule was broken to great effect. I promise that the idea of “breaking rules” has nothing to do with my last post that was all about not knowing what the rules are.
So back to the UI Golden Rules – there is no shortage of rules out there that have been concocted and created through a combination of common sense, user studies, and solid media persuasion. I say persuasion because there are no real “UX Golden Rules” that everyone agrees on – design is too subjective for that. I would argue that there are Golden Rules around best practices for gathering information and analysing it, but when it comes to actual design, the rules tend to be more about who has the loudest and most-listened-to voice at the moment. What’s this all mean? It means most designers tend to form their own Golden Rules and work from those. Myself I tend to model my thinking along the lines of Ben Shneiderman‘s 8 Golden Rules. But this post is about breaking rules for the betterment of design – let me tell you a story.
Consistency is often lauded as a high ideal to strive towards when designing user interfaces. It makes sense – if you do something once, and then a second time, suddenly that thing can become quite natural and … well … intuitive.
Last month I came across a cautionary tale related to consistency.
A project I’m currently working on is encountering a problem that I believe is not all that rare. They are faced with a challenging question mid-project: should the team focus on producing software that is easy to use and learn, or should they focus on getting as many features and bug fixes in as possible before the final release? I have seen many people frustrated that we can’t seem to have our pie and eat it too – we can’t seem to find ways to “do usability” without somehow impacting the project’s timeline or scope. And sadly, at this point in time, I agree that this is true for this project. Kinda.
I’d like to take a closer look at these two options, and propose a few solutions for future project teams to consider.