Product Design is an engineering process.
It is not just about drawing a beautiful user interface, it is about building a solution to a user’s problem.
It is a succession of logical steps in thinking and writing, which I highly recommend to browse through sequentially. And the best approach to my experience is going top down. Once more, it is about having the right discussion, at the right moment.
It is going from:
- the requirements analysis (user problem),
- to a concept design,
- on to a functional design,
- and to end up with a technical design.
The Pyramid Principle Logic in Writing & Thinking describes in detail the general benefits of the Top Down approach. This blog post will focus on its application in the Product Design context, within an Agile environment.
Why go for a Top Down approach?
I have seen a recurring trend with startup technology companies to first worry about the technology, and the technical implementation, and try to meet customer requirements with their technology.
Don’t miss the point
The thing is, with such a process: you might end up with a technology that is awesome, but that doesn’t answer any need. And no one will buy it, until you make modifications. Some of which may be very light, and some may affect the complete architecture or data model that you have chosen at the start. Worse, the delivery channel may be wrong (maybe your product is just not suited for SaaS in the end).
Make sure simple things stay simple
The most frustrating situation will be when you actually do answer a need, but by solving it with first looking at the technical implementation, you can end-up reinventing some basic User Experience principles or even vocabulary. And doing that is then just a pain for on-boarding new users, or marketing and sales activities, as you will constantly have to explain the features which would otherwise have been self-explanatory.
Last but not least, this approach is the best way into a lean product development. By getting a high level overview of your product requirements depending on your market, users and customers, it will be natural to prioritize your roadmap, and eventually decide to postpone this or that feature which are not critical to delivering a solution. That is about building your Minimum Viable Product.
Picturing the approach with the SADT
I like to picture things with this technique. Probably what’s left of my engineering studies.
At each step of the design, you should be thinking of a black box, with only:
- An input
- An output
- A control
Let’s take go through a simple case study.
You are a hardware technology company that specializes in buildings security. You customer has hired a single guard to control all of the site’s entrance. That guard may also have other tasks to perform, which makes it impossible for him to stare at all doors or CCTV. However, he should control the identity of each visitor before he enters the site.
Concept – Movement detector
You can start offering a movement detection & warning device.
Wait, what? That’s already a choice you have made! You’re now at the “Concept” stage. And somehow you’ve closed some doors. Who said that this was the only solution to this user’s problem? As you are a hardware technology company, you will leverage your distinctive competency. So that’s OK. But it could have been worthwhile checking for other options.
An easy way to materialize this would be to have the following:
Looking at the specific “emitting” part, you could for instance use a good old NE555 integrated circuit as pulse generator.
What’s my point here? At each and every step, I made some choices (good or bad). They directly opened doors, but closed many more of them.
If I had started directly at the implementation level, I would never had the chance of seeing more options, which could have been more appropriate regarding my business objectives just as much as regarding the user’s needs.
The technology should always be a leverage, not an actual solution!
How Scrum supports this approach
Backlog position and User Story level of detail
As show on the diagram below, the best way to maintain your backlog is to play with the level of detail in which a user story is written, and its position in the backlog.
When a user story is plainly expressed as a user problem, it should be somewhere down the backlog. And probably that its complexity points estimation will be high (you have no clue of what you’re going to do).
When a user story is at the top of the backlog, best is that you know exactly how the feature will work, that you have the mockups ready, and potentially that you have the implementation guidelines ready.
If you a Jira user, I can definitely recommend you the following:
- Describe the concept in an Epic
- Describe the features for that Epic in User Stories (the goal is to have stories smaller than 8 pts, remember!)
- Describe each story’s implementation in sub-tasks
Grouping properly the stories in epics will make it much easier to browse through the backlog and prioritize the sprints, but also will enable you to make the right trade-offs on MVPs for each Epic, and still without forgetting any feature. (Issues not linked to Epics tend to be lost deep in the backlog).
The use of Epics will facilitate to have a visual roadmap. Best is when you configure your “Epic” issue type in Jira to have an estimated start date and end date. Then, interfacing Jira with Confluence will enable you to display your Roadmap via the Calendars feature. Visually appealing, easy to drill down through Epics to Stories, from Confluence to Jira. Great for conversations with your manager/business stakeholders.
How to write a proper Epic
Given the above, you understand how critical it is to properly describe your Epic.
- The user problem described in a few sentences (ideally one)
- Your concept solution, in a few sentences
- A Product Opportunity Assessment, as described my Marty Cagan, already quite some years ago.
The shortest the description, the better chances you have that your developers will read through it.
Never put your screen mockups there! They belong to stories! (or that’ll be one more way to write a book in your Epic description)
User problem/User goal
I’m often referring to what I call the user problem. Let’s look a bit more at what I mean with it.
User stories are not the whole requirement. Agile developers want user stories; product managers want to bring back stories from the market about users. What we really need, however, is to understand user goals.
Writes Edward Brown. He proposes a very interesting exercise in his blog post to better understand how to define that user goal.
I’m actually used to mentioning a User Problem (instead of goal), as opposed to the solution I’m trying to build for the user.
What is also very important here is that the User Problem should encompass the market context. And there you get the link with the User Persona, which should be mentioned in the title of each of your user stories… 😉
I’ve already quickly mentioned that in a previous blog post. It is an other way of making sure you set clear objectives. I prefer Marty’s Product Opportunity Assessment, but this still is a good old recipe.
Writing an Epic is also like setting an objective. Making it S.M.A.R.T. implies to make sure it’s:
The cool part is that you probably already cover some of those parameters if you’re working with Agile, especially through the definitions of “Ready” and “Done”.
The following are issues I’ve met while designing products, and short-circuiting the top down approach.
This is not the user problem you are looking for
Interviewing users and customers can be a tricky exercise. Often, users will tend to describe what they want the product to do, instead of what problem they would like it to solve. That makes the process directly jump to step 3, or even step 4. And there goes your product consistency, and “functional debt“.
Make sure you are in the lead during the interview, and understand exactly what you users need!
Jenga your product
It’s not because you can implement a feature that you should.
Some new implementations may have a direct impact on your whole product, or even your sales process. And where you thought you had a great idea, you’re actually blurring the whole story and losing customers.
An interesting exercise, however, even if still in the “Jenga” concept, is to wonder every time you add a new feature if you can remove and other one instead.
Could be a very bad idea! At least if you don’t actually go through the whole design process we talked about.
Trying to reuse some work that has been done is great in terms of shrinking the time-to-market. But if you’re thinking: oh, that feature is great, I’m just going to reuse it into this other product that seems to have common points with the first one… Well, you’re on to totally missing the user problem!
Indeed, as long as you haven’t understood and stated the essence of the user problem, how can you know that this specific feature actually is a solution for him? There’s no room for approximation!
Of course, you will still need to be careful in not re-inventing the wheel every time, so the past work definitely is a valuable experience, and should be considered in order to improve the coherence between your products.
- http://fr.wikipedia.org/wiki/Analyse_fonctionnelle_%28conception%29 (in French)
- http://svpg.com/assessing-product-opportunities/ (by Marty Cagan)
Featured image by espinozr