Mar 22, 2021
PM Process: User Interface
Many product managers focus on finding the best interface for easier user engagement with the product. While some insist on using design tools, mock-up tools, prototyping interactions, some insist such must be left to the UX designers to provide the best possible proposals. I will like to debate if we actually captured the requirement at the right level. A lot of that is to do with how you described your problem in the first place. If you are excited about writing user stories right, read on and let me know what you feel.
The Curse of Details
Let’s look at a travel portal user story where a user interface is described for an air ticket booking interface.
As a user, I shall be able to select a from airport from a drop-down, select a to airport from a drop-down and the date and time of the travel from a calendar/clock, and request flight options.
I think most of us will relate to this user story. But, do you realize we have kind of assumed substantially on the user story? These are stiflingly restricting for your UX person to operate. How so? Following are the assumptions I made that look innocuously simple, yet constraining innovation.
- We presumed there is a drop-down to select cities
- There is a clock/ calendar to select travel date and time
- Indirectly, we presumed there exists a user interface presented as a web page or client application that can render such user interface components.
Someone may say it’s fair; we just have a travel portal. When we implement for mobile devices we will write a new user story. How much effort is expended in writing another line? Fair enough. But, can there be an alternative?
The Alternate
Let’s look at the user story in this way:
As a user, I shall be able to pick up from the airport and a to the airport and an indicative travel time to seek suggestions for available flights.
This story is incomplete to most people, and rightly so. Hard to estimate and even not clear as to where it will be delivered. These are ideal epics for your backlog so that engineers and UX personnel can debate and come to a common understanding of the implementable user interface. Let’s understand the granular implications of this story:
- from airport: Can the user type the city, while the UI presents her alternate choices as a drop-down? Can she be provided a map? Can she decide from the location of her current city? In the case of a location-enabled device will that become her priority? All these are valid expressions and definitely ideal for the conversation to decide on the right interface.
- to airport: Similar to above but additionally can point to your natural place of residence as an option.
- indicative travel time: This is the most interesting one. Why does it always have to be a date and time from a calendar and clock? Could it be 12 hours from now, the first flight the next morning? Is that not how we typically decide our travel? Last Friday of the month? Next long weekend for family time or spring break?
When you have epics written like this, you can discuss them with engineering and UX teams effectively. Provide them the food for thought to munch on and then decide on a story that is narrow enough depending on the UX of your interest. If you think deeper, the user story is even true for a conversational chatbot. When in doubt, the bot shall ask you to clarify with a question just like a human agent shall do.
Writing very narrow user stories may look relevant to you as you implement a story in sprint planning phases, but never miss out on probing for innovation when you have an opportunity to do so and in short enabling your teams to come up with innovative alternatives. Use epics judiciously, leave the product management intent reflected in the backlogs.
