Document Actions
Requirements: Functionality or User Interface First?
I was recently promoted to VP Product Management in my organization. I have nearly 9 years tenure with the company in a sales and management capacity, so know our product very well and *think* I know our clients too. My question is this; We are about to enter the requirements setting phase for the next version of our product. We have acquired feedback that suggests the primary goal of this release is to be much easier to use and to require less training than current versions - which are very sophisticated (and complex). One area that needs work is relative to our user interface. What order makes the most sense to proceed in: Begin with the end in mind (i.e. design the new interface, then create the functionality behind it, or vice versa?).
An outside-in approach increases your chance of success. The first step is to ascertain whether the problems you solve with your software have changed. Are they really the same as when the existing functionality was written? If not, you should begin by finding and quantifying market problems, then proceed to requirements and design. If the problems are the same, then you're really just re-designing an interface for existing functionality.
In any case -- once you have determined the urgent, pervasive problems that people in your target market segment are willing to pay to have solved, you should define the requirements (including personas, problems, and use scenarios). At that point, your Development team can design from the outside in -- using interaction design tools (like paper prototyping) to design an interface that works well for your intended users.
The key to successful products is frequent user validation -- regardless of your point of beginning, build multiple validation steps into the plan to reduce risk and increase your chance of building a product that delights users and sells itself.
Answered by Stacey Weber
