Content: It’s All About the Interface
As you may recall, I’m the PM for a project to install a content management system for a medical publisher. We have worked hard at understanding and documenting the benefits of the system, but that’s not what people really want to talk about.
As Katie Couric on the Today Show has been heard to say, “It’s all about the hair”. This lady interviews newsmakers daily, and is on a first name basis with world leaders. She gets by far the most mail when she changes the smallest aspect of her appearance, especially her hair. For Users, it’s all about the Interface.
In my project, as we work through Business Requirements Specification, I’m doing interviews with Managers, Customers, and Users. Not surprisingly, they don’t talk about Business Requirements – they talk about application interface details. They bring up Google, and show me how well it works. They take me to house wares shopping sites, and show me how you can cross-link from a lamp to other lamps with similar attributes. They describe features of search sites that they have used successfully, that allowed them to save their last search, or apply parentheses and Boolean logic to their current search.
Meanwhile, I’m trying to figure out how many “components” there are in the system, the nature of the interfaces between the components, and which ones we will buy, which ones we will build, and which ones we have already. I know that we are going to buy a software package as the core of the solution, and I’m trying to formulate a map of the overall solution, with my eye on the RFP to come, and how we will ask for what we need. I suspect that most of the user interface details will come with the package.
At this point, dear reader, you are probably saying – “Larry, you are getting ahead of yourself – let the requirements be requirements, not design.” And of course you are right. So we will slow down a bit, and take it step by step. Let’s talk about the interface, and translate that into requirements. Then let’s collect the requirements, and then talk about the magic that happens as requirements become hi-level design.
As Katie Couric on the Today Show has been heard to say, “It’s all about the hair”. This lady interviews newsmakers daily, and is on a first name basis with world leaders. She gets by far the most mail when she changes the smallest aspect of her appearance, especially her hair. For Users, it’s all about the Interface.
In my project, as we work through Business Requirements Specification, I’m doing interviews with Managers, Customers, and Users. Not surprisingly, they don’t talk about Business Requirements – they talk about application interface details. They bring up Google, and show me how well it works. They take me to house wares shopping sites, and show me how you can cross-link from a lamp to other lamps with similar attributes. They describe features of search sites that they have used successfully, that allowed them to save their last search, or apply parentheses and Boolean logic to their current search.
Meanwhile, I’m trying to figure out how many “components” there are in the system, the nature of the interfaces between the components, and which ones we will buy, which ones we will build, and which ones we have already. I know that we are going to buy a software package as the core of the solution, and I’m trying to formulate a map of the overall solution, with my eye on the RFP to come, and how we will ask for what we need. I suspect that most of the user interface details will come with the package.
At this point, dear reader, you are probably saying – “Larry, you are getting ahead of yourself – let the requirements be requirements, not design.” And of course you are right. So we will slow down a bit, and take it step by step. Let’s talk about the interface, and translate that into requirements. Then let’s collect the requirements, and then talk about the magic that happens as requirements become hi-level design.
Posted on Thursday, December 29, 2005 at 11:23AM
by
Larry Cone
in Best Practices, Case Studies
|
Post a Comment
Larry Cone
in Best Practices, Case Studies
|
Post a Comment
View Printer Friendly Version
Email Article to Friend
Reader Comments