In one of his last posts, Seth Godin wrote about implicit anchors that force us to follow specific paths. This might be OK in many cases but...
Great editors, great strategy consultants, great friends--they're generous enough and bold enough to unanchor the conversation and get to the original why at the beginning of a string of decisions.
Curiously, last week I had experienced the metaphor of the anchor in my job.
A Couple Of Anchors
A colleague of mine gave me a specification for a new function, clearly explaining how it should have been done. First anchor: the solution is already provided. At first it made sense to me, but, after a while, I came up with two other solutions, so these are the choices I presented:
The easy one - about one hour of work
The intermediate one - probably one day of work, maybe two
The hard one - about a week of work (this was the one suggested by my colleague)
Needless to say that I would have chosen the first solution. When I proposed this to my colleague he said: "Wonderful!". Second anchor: the easiest and fastest solution is the best.
The Solution Is Storytelling
Everything seemed OK, but I thought something was missing. So I started to speak with my colleague about the use cases for that function and... oops! There were some constraints that make not possible the easy solution.
In the world of the UX design, they use the term persona to identify specific classes of users and see how they interact with the UI. It's a sort of role-playing game. I think that something similar is needed also when designing the behavior of a system, not only it's interface.
A software may have different kinds of users with different skill levels and different goals. Having someone that is able to restrict these many situations to few specific cases is really helpful to be able to provide quickly the solution that is the best for the user.
By telling the story of a fictional user, you can understand why he needs that particular function and how he will use it. At this point, you have all you need to choose the right solution.
On a related topic (interaction between product managers and developers, and how to save a project), see also Missing Things.
Cover image by Zol87 taken from Wikimedia Commons licensed under the Creative Commons Attribution-Share Alike 2.0 Generic license.