On Oct 20, 2007, at 1:19 AM, Bill Fernandez wrote: > To me there's a very important distinction between these two > documents: The functional spec defines WHAT you want the product to > accomplish (what it's functionality is), and the UI spec defines > (from the user's standpoint) HOW it accomplishes it (how it's > functionality is presented). > ... > In practice, as a freelance user interface architect I often end up > writing both kinds of specs for clients, in which case I'm able to > maintain the distinction between "what do you want it to do?" > (functional) and "is this a good way to do it?" (UI). And I must > say, it's very good to get clarity on the first before spending too > much time on the second.
Do you (or your employers) usually create the functional spec *before* the UI spec? I suppose this is a pretty traditional way of doing things in big organizations, but I thought we were generally moving away from that model. Are you comfortable with that approach? I always work in the opposite order. It's the way I think. What the user sees *is* what the product does. How the functionality is presented *is* the functionality. Everything else is engineering problem-solving in the service of the user experience. To me, this is where functional specs are useful: When a UI design needs to articulate some back end rules that are generally invisible to the user, or whose functionality needs to be articulated in terms that are useful only to a programming team (for example, does the system use a session or a cookie to remember a user preference? which database does the data come from?), then a functional spec can add to what the core user experience spec says. The user experience spec is the Holy Bible that everyone is working towards -- the functional spec is . Maybe I'm thinking of a tech spec? I think of this in architectural terms, where the architect designs where the people go and how they experience the space, but the engineers decide what kind of steel beams to use, where the rivets go, how to route the water pipes and the electrical wiring, etc. (I am not demeaning the work of engineers here. Engineers with the right skills can certainly build, or help build, great user experience specs. And, of course, the process of figuring out how to effectively build and deliver the user experience as specified in the UI spec is not trivial, requiring great skill, creativity, and ingenuity.) As UI designers, sometimes we have no choice but to follow a tech spec. Many product managers begin with functional specs and then bring on the UI team to "make it user friendly". But in my mind if any product manager has a choice in this matter, they do their product a great service by beginning with the UI design. If there is a single thing that best exemplifies "user centered design", it is the concept that the "UI is the spec" [1]. In Agile development, which is these days belatedly but excitedly integrating with UCD, the spec is often expressed as "stories" and "test cases": By expressing what something is supposed to do for the user as a story, and accompanying that story with specific examples of how it should not fail, you are elegantly eliminating both a functional spec and a test plan documentation process from your methodology, saving many thousands of person-hours. Yet another exciting development in the slow death of the functional spec. [1] http://www.37signals.com/svn/archives/001050.php -Cf Christopher Fahey ____________________________ Behavior biz: http://www.behaviordesign.com me: http://www.graphpaper.com ________________________________________________________________ Welcome to the Interaction Design Association (IxDA)! To post to this list ....... [EMAIL PROTECTED] Unsubscribe ................ http://gamma.ixda.org/unsubscribe List Guidelines ............ http://gamma.ixda.org/guidelines List Help .................. http://gamma.ixda.org/help
