functional designer?

18 Oct 2007 - 3:40pm
7 years ago
25 replies
1633 reads
russwilson
2005

I wrote a post on my blog recently about software design which proposed
calling front-end design "interaction design" and back-end design
"functional
design" --
http://www.dexodesign.com/2007/10/what-do-we-mean-by-software-design.html

Ironically, a few days later our CEO sent me an article from Zigzag
Marketing
addressed to product managers which talked about the importance of the
"functional
designer" to product development, only by "functional designer" they were
referring
to what we would call interaction design (for the most part). See the
functional designer
article at: http://www.zigzagmarketing.com/articles.asp

Has anyone come across "functional design" as a term? I thought it made
sense
for back-end design.

Best regards,
Russ

--
Russell Wilson
Blog: http://www.dexodesign.com

Comments

18 Oct 2007 - 4:42pm
Chris Borokowski
2007

I have heard the terms information architect, development architect and
function engineer.

I prefer the term "function designer" and "function design," as
otherwise it sounds like a description of design that contrasts
"dysfunctional design," or ineptitude.

--- Russell Wilson <russ.wilson at gmail.com> wrote:

> Has anyone come across "functional design" as a term? I thought it
> made
> sense
> for back-end design.

http://technical-writing.dionysius.com/
technical writing | consulting | development

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

18 Oct 2007 - 4:43pm
Peter Bagnall
2003

Russ,

I'd tend to interpret functional designer as a synonym of interaction
designer. Mostly because it would make sense for a functional
designer to be someone who creates a functional spec. And a
functional spec talks about the interaction between the software and
it's user.

http://en.wikipedia.org/wiki/Functional_specification

I tend to use the term "engineering design" to mean the backend.

Having said that I don't especially like "functional designer" as a
term. As you point out, it's rather ambiguous.

Cheers
--Pete

On 18 Oct 2007, at 21:40, Russell Wilson wrote:

> I wrote a post on my blog recently about software design which
> proposed
> calling front-end design "interaction design" and back-end design
> "functional
> design" --
> http://www.dexodesign.com/2007/10/what-do-we-mean-by-software-
> design.html
>
> Ironically, a few days later our CEO sent me an article from Zigzag
> Marketing
> addressed to product managers which talked about the importance of the
> "functional
> designer" to product development, only by "functional designer"
> they were
> referring
> to what we would call interaction design (for the most part). See the
> functional designer
> article at: http://www.zigzagmarketing.com/articles.asp
>
> Has anyone come across "functional design" as a term? I thought it
> made
> sense
> for back-end design.
>
> Best regards,
> Russ
>
>
>
>
> --
> Russell Wilson
> Blog: http://www.dexodesign.com
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help
>

----------------------------------------------------------
No one would be foolish enough to choose war over peace - in
peace sons bury their fathers, but in war fathers bury their sons.
- Croesus of Lydia, 595 - 547 BC

Peter Bagnall - http://people.surfaceeffect.com/pete

18 Oct 2007 - 7:08pm
Nicholas Iozzo
2007

I've used the term functional design to help our clients understand
the different roles within the design process. The IAs are
responsible for the functional design while the visual designers are
responsible for the design of the form.

When you add to this, form should follow function, you have an adage
that helps explain why you want to get your wireframes done before
the comps.

I think this also serves project teams to better understand the role
in a project. If the final design looks like a coat of paint was put
on a wireframe, then the project team is not working well together.
conversely, if the wireframes are merely suggestions to the
designers, then you also have a problem.

But to think of design as form following function, you have a mental
model to help a team work together. The IA designs the functions of
the application, the visual designer does the form.

Finally, the best design happens in an iterative fashion (no one can
get a design perfect on the first try).

When you put this all together, you have form and function design
tracks interweaving and building on each other... with the functional
track starting just before the design track.

Anyway, that is how I explain it to my clients.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=21651

18 Oct 2007 - 11:07pm
russwilson
2005

Okay, so then how would you distinguish between an
interaction designer and a functional designer? Are they the same?

On Thu, 18 Oct 2007 17:08:41, Nick <ixda at humansize.com> wrote:
>
> I've used the term functional design to help our clients understand
> the different roles within the design process. The IAs are
> responsible for the functional design while the visual designers are
> responsible for the design of the form.
>
> When you add to this, form should follow function, you have an adage
> that helps explain why you want to get your wireframes done before
> the comps.
>
> I think this also serves project teams to better understand the role
> in a project. If the final design looks like a coat of paint was put
> on a wireframe, then the project team is not working well together.
> conversely, if the wireframes are merely suggestions to the
> designers, then you also have a problem.
>
> But to think of design as form following function, you have a mental
> model to help a team work together. The IA designs the functions of
> the application, the visual designer does the form.
>
> Finally, the best design happens in an iterative fashion (no one can
> get a design perfect on the first try).
>
> When you put this all together, you have form and function design
> tracks interweaving and building on each other... with the functional
> track starting just before the design track.
>
> Anyway, that is how I explain it to my clients.
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://gamma.ixda.org/discuss?post=21651
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://gamma.ixda.org/unsubscribe
> List Guidelines ............ http://gamma.ixda.org/guidelines
> List Help .................. http://gamma.ixda.org/help
>

--
Russell Wilson
Blog: http://www.dexodesign.com

19 Oct 2007 - 4:25am
Adrian Howard
2005

On 18 Oct 2007, at 21:40, Russell Wilson wrote:

> I wrote a post on my blog recently about software design which
> proposed
> calling front-end design "interaction design" and back-end design
> "functional
> design" --
> http://www.dexodesign.com/2007/10/what-do-we-mean-by-software-
> design.html

I find the idea of there being a sharp divide between the two
disturbing...

[snip]
> Has anyone come across "functional design" as a term? I thought it
> made
> sense for back-end design.
[snip]

It may be a little confusing in the SW dev world since "functional"
is also a style of software development (you can say "functional
programming" in the same way you can say "object oriented programming").

It also has a slightly lesser known meaning in software development
as a design methodology <http://en.wikipedia.org/wiki/Functional_design>

Adrian

19 Oct 2007 - 4:29am
Adrian Howard
2005

On 19 Oct 2007, at 05:07, Russell Wilson wrote:

> Okay, so then how would you distinguish between an
> interaction designer and a functional designer? Are they the same?
[snip]

I don't think they necessarily need to be the same person - but they
need a number of skills in common. A good user experience and a good
software implementation both depend on a deep understanding of the
users domain.

Cheers,

Adrian

19 Oct 2007 - 8:12am
Switzky, Andrew
2007

Okay, so then how would you distinguish between an
interaction designer and a functional designer? Are they the same?

I think functional designer should mean the same thing as interaction
designer. It's a good way to explain what you do to business systems
analysts, project managers and developers as well as to clients.

Andy

19 Oct 2007 - 8:42am
Faith Peterson
2007

I'm in a small shop in which designers wear three hats. We design
functionality when we specify what operations and information to expose to
the user. We design interaction when we specify how to expose them, and how
the user will interact with the application to use them. We wear our
"application business analyst" hats when we analyze and specify the business
needs the functionality will meet. We have two dedicated UI
designers/front-end developers who design the appearance and layout, and
code the browser-side logic.

Interaction design is where we do the most cross-functional collaboration,
because the front-end developers have to be able to make it possible (and
often have great ideas) and the server-side developers have to deliver
everything we need for the interaction in the page and handle discrete
transactions with or without new pages. It's also the most challenging in
that it's the perspective that our business stakeholders and user
representatives "get" and the language they speak in ("Can we just add a
little button over here that will ...") so we have to do the most
translation and expectation management.

I work on a web-delivered application, so the "front-end/back-end" divider
doesn't work well in this context. It would mean that functional design
specified server-side system behaviors, and interaction design specified all
browser-side system and user behaviors. We focus the design of functionality
and of interaction both on the browser side. We treat server-side operations
as a black box
--
Faith Peterson
f.a.peterson at gmail.com

On 10/19/07, Switzky, Andrew <Andrew.Switzky at austinenergy.com> wrote:
>
>
> Okay, so then how would you distinguish between an
> interaction designer and a functional designer? Are they the same?
>
> I think functional designer should mean the same thing as interaction
> designer. It's a good way to explain what you do to business systems
> analysts, project managers and developers as well as to clients.

19 Oct 2007 - 8:25am
Nicholas Iozzo
2007

Assuming you start from business needs through research, functional
requirements, testing, and UI design, then I see functional design as
the entire process with interaction design mainly being the last step.

With functional design, you are trying to figure out which functions
you will be supporting of your end-users and how you will support it.
The interaction side of it is determining which combinations of
controls and events will be used to allow the user to accomplish
those functions (in the most usable and "buildable" manner).

To be clearer, I should have called it functional UI design. But
since I have developed these terms to help our clients understand
what we do, I could safely drop the UI.

Also, I think my definition above is for a slice of what we do. I
mainly work on business process or transactional applications.

This makes me wonder, is our field getting mature enough now that it
is worth while to define sub-sets of what we do and give each of
those sub-sets their own unique nomenclature?

_____________
Okay, so then how would you distinguish between an interaction
designer and a functional designer? Are they the same?

On Thu, 18 Oct 2007 17:08:41, Nick ixda at humansize.com wrote: I've
used the term functional design to help our clients understand the
different roles within the design process. The IAs are responsible
for the functional design while the visual designers are responsible
for the design of the form. When you add to this, form should follow
function, you have an adage that helps explain why you want to get
your wireframes done before the comps. I think this also serves
project teams to better understand the role in a project. If the
final design looks like a coat of paint was put on a wireframe, then
the [trim]

-- Russell Wilson

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=21651

20 Oct 2007 - 12:19am
Bill Fernandez
2007

I've never before heard of "functional design" or "functional
designer". On the other hand I have for many years, and in multiple
companies, used the terms "functional specification" and "user
interface specification" (among others) for important design process
documents, on both hardware and software products.

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).

To give a trivial example, the functional spec might say "the product
shall provide a way for the user to choose one of the following
colors: red, green, yellow, orange, blue". And the UI spec,
depending on the overall design approach for the product, might
specify the use of a pop-up menu, a voice command, the pressing of
the keyboard keys "1" to "5" to correspond to the colors in a given
order, etc.

A big, recurring problem I've had through the years is that the
people who were defining the functionality (often Marketing) would
often state functionality in the form of a UI design ("the colors
shall be chosen through a floating palette of colored squares"), and
then would keep that image in their minds throughout the project --
even when it was clearly inappropriate to the ultimate UI needs.

As an aside, it also turns out to be very difficult (and thus a skill
unto itself) to describe the desired functionality (for the
functional spec) without expressing it in a concrete form (which is
the role of the UI spec).

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.

I don't know if there are contexts in which the role "functional
designer" is necessary, but I do feel uncomfortable equating
"functional "design with "user interface" or "interaction" design.

My two cents,
Bill
--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

20 Oct 2007 - 4:24pm
Christopher Fahey
2005

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

21 Oct 2007 - 4:50am
Bill Fernandez
2007

At 5:24 PM -0400 10/20/07, Christopher Fahey wrote:
>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?

BF: I always create a functional spec before a UI spec. These days
my functional specs are often informal: perhaps a list of bullet
points or a general description of what the end result is supposed to
be like. But I feel it's essential to get an adequate sense of the
range and scope of the job I'm being asked to do.

>... (for example, does the system
>use a session or a cookie to remember a user preference? which
>database does the data come from?)...

BF: To me, these do not belong in a a functional spec. A functional
spec would say "we have to let users set [these] preferences..." and
"there must be a way to store and retrieve [this] data...". *how*
the preferences and data are stored and retrieved is up to the
engineers to design. How the preferences and data are presented to
the user is up to me to design. We both have essential roles in
delivering the desired functionality to the user. Both of us must be
successful for the user to have a satisfactory experience.

>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.

BF: I, too, use the building-architecture analogy, and I equate
myself in this analogy with the architect. A building architect
always has to ask the client what kind of building to design and what
are its key characteristics. What is its purpose, what is the
budget, how many people, cars, etc. does it have to hold, etc. I
suggest that the list of answers to these questions comprises the
first (and sometimes final) draft of what I'd call a functional spec.

>(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.)

BF: One key thing I've learned in my career is that the only thing a
user ends up seeing or interacting with is what the engineers build.
Therefore I only have influence, not control over the outcome. I can
maximize my influence by working closely *with* the engineers to: (a)
design something they can build (within the constraints of budget,
schedule, legacy issues, etc.), and (b) getting them excited about
how wonderful the results can be.

>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".

BF: Whenever I've encountered this, the people who have worked on the
project before I was brought on board have gone way beyond what
belongs in a functional spec, or marketing requirements document,
etc., and instead have already created a design (even if they're not
calling it that). When in the past I've found myself presented with
such a situation I have gone to the decision maker(s) and said,
diplomatically and tactfully, you have two choices: constrain me to
simply making minor improvements to the "design" you've presented me
with, or give me the freedom to create the design that this product
really needs. You're paying me, it's your call.

>...If there is
>a single thing that best exemplifies "user centered design", it is
>the concept that the "UI is the spec" [1].

BF: At least on the face of it I can't agree with this, although
maybe you didn't mean it the way I read it. To me user centered
design starts with a deep knowledge of, sensitivity to and
commitment to the users. Any design, engineering, testing,
marketing, packaging, sales, distribution, support, etc. must flow
from that for a product to be "user" centered. And as you may guess
from my list, I feel that the user "experience" is affected by the
full spectrum of organizational specialties. A good UI design is
certainly a key contributor to a good user experience, but can easily
be undermined by poor performance in other parts of the organization.

>[1] http://www.37signals.com/svn/archives/001050.php

BF: I read this, and it doesn't sound at all like my experience. I
don't doubt that the writer(s) are telling the truth as it has been
for them, but for me I have typically found functional specs to be
empowering and unifying.

--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

21 Oct 2007 - 9:58am
Todd Warfel
2003

On Oct 20, 2007, at 5:24 PM, Christopher Fahey wrote:

> 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.

Some of our larger clients have been using our behavior design specs
(wireframe decks) as part of their documentation–more than just an
initial document, it's on ongoing updated spec for the dev team. They
still have their functional spec that's 60pp or so and more than
anyone cares to read.

I've often wondered why we don't just have one document. But I've
also wondered if one document would be better or worse. To be honest,
we rarely find any visual designers who read the functional spec–they
typically rely on our behavior designs instead. So, perhaps it's
better to have two separate docs? Or would it be better to just have
a prototype that serves both purposes? Maybe provide the more
detailed functional specs in an underlying layer that the dev team
can get at that isn't in the way of the designers?

Fortunately, instead of having a functional spec written before our
behavior design specs, we're finding more and more of our clients are
trying to do them in tandem with each other. Just last week, one of
our clients wanted our behavior design for a specific piece of
functionality so that he could write his functional spec. That's
progress.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

21 Oct 2007 - 10:00am
Todd Warfel
2003

On Oct 21, 2007, at 5:50 AM, Bill Fernandez wrote:

>> ... (for example, does the system use a session or a cookie to
>> remember a user preference? which database does the data come
>> from?)...
>
> BF: To me, these do not belong in a a functional spec. A
> functional spec would say "we have to let users set [these]
> preferences..." and "there must be a way to store and retrieve
> [this] data...". *how*
> the preferences and data are stored and retrieved is up to the
> engineers to design.

Perhaps this is a difference in either experience or opinion (or
both), but the functional spec is the part that elaborates more on
the backend technology. So, this is exactly where I would see this
type of information fitting in.

Cheers!

Todd Zaki Warfel
President, Design Researcher
Messagefirst | Designing Information. Beautifully.
----------------------------------
Contact Info
Voice: (215) 825-7423
Email: todd at messagefirst.com
AIM: twarfel at mac.com
Blog: http://toddwarfel.com
----------------------------------
In theory, theory and practice are the same.
In practice, they are not.

21 Oct 2007 - 1:05pm
Bill Fernandez
2007

At 11:00 AM -0400 10/21/07, Todd Zaki Warfel wrote:
On Oct 21, 2007, at 5:50 AM, Bill Fernandez wrote:

... (for example, does the system use a session or a cookie to
remember a user preference? which database does the data come
from?)...

BF: To me, these do not belong in a a functional spec. A
functional spec would say "we have to let users set [these]
preferences..." and "there must be a way to store and retrieve
[this] data...". *how*

the preferences and data are stored and retrieved is up to
the engineers to design.

Perhaps this is a difference in either experience or opinion (or
both), but the functional spec is the part that elaborates more on
the backend technology. So, this is exactly where I would see this
type of information fitting in.

Todd--

Then maybe we're using the term "functional spec" to mean different
things, and maybe some of this discussion is each of us explaining
what *we* mean by the term.

My philosophy is that it's always best for everyone to agree on the
goals, constraints, assumptions, etc. of the project then let
everyone do their part towards realizing those goals. In my
experience this starts with something that's often called a
functional spec which describes *what* but not *how*.

Indeed I just received from a client, who often involves me at the
beginning of each project, an early draft of a document titled
"functional spec for...", that did not say anything about the UI or
the technical plumbing -- it was just a description of the various
things the product had to do.

It is also my experience that this initial, abstract statement of
goals and constraints subsequently leads to concrete documents from
various departments describing *how* they propose to accomplish the
agreed-upon goals. From engineering this usually takes the form of
engineering specs, database schema, APIs, etc. From me this usually
takes the form of one or more "UI concept" documents, which leads in
time to a detailed "UI spec" (which sometimes, if the product is
web-based, is in the form of the actual HTML and CSS templates that
will be used to implement the product).

Also, I find that the formality of each step varies from project to
project. If there are many departments and many players involved,
then sometimes more formality is required. On the other hand, when a
client says "just design *and* build me a new website", I can get by
with asking a number of basic questions, doing a few reality checks,
then doing most of the work in my head -- and letting much of the
project develop "on the fly". It all depends on the situation.

Of course others will have different experiences and so may slice and
dice the process (and the terminology) differently.

--Bill
--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

21 Oct 2007 - 1:18pm
Joseph Selbie
2007

"Indeed I just received from a client, who often involves me at the
beginning of each project, an early draft of a document titled
"functional spec for...", that did not say anything about the UI or
the technical plumbing -- it was just a description of the various
things the product had to do."

I am coming into the thread rather late, so forgive me if I missed this
earlier, but what you are describing here as a "functional spec", sounds an
awful lot like the first iteration of the use cases we encounter in many
companies.

The use cases we've been involved with start with a description of what the
user needs to be able to do -- regardless of where or how that will be
accomplished in the application. As the use cases iterate, they become more
specific and eventually include field level accuracy.

I know that use case definitions and methods for developing them vary widely
across companies that employ them, but the functional spec sure sounds like
the same approach.

Joseph Selbie
Founder, CEO Tristream
Web Application Design
http://www.tristream.com

21 Oct 2007 - 3:06pm
Peter Boersma
2003

Todd wrote:
> Fortunately, instead of having a functional spec written before our
> behavior design specs, we're finding more and more of our clients are
> trying to do them in tandem with each other.

I'm doing my wireframes side-by-side with functional specs now: I'm in the middle of a project where the implementors will be using a commercial e-commerce package, so they are trying to only document non-standard functionality. They started by using screenshots from a demo-store to illustrate their work, but after we delivered the first iterations of wireframes they are replacing the screens with ours.

(I am not satisfied with what they're documenting though; half of it is a rewrite of our specs. When we say "the 'edit' link takes the user to the page where she edits the relevant items" I'd expect them to document what software function is called and what the parameters are, not repeat our message.)

Peter
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

21 Oct 2007 - 7:43pm
Bill Fernandez
2007

Bill Fernandez wrote:
>...I just received from a client... an early draft of a document titled
>"functional spec for..."

Joseph Selbie wrote:
>...what you are describing here as a "functional spec", sounds an
>awful lot like the first iteration of the use cases we encounter in many
>companies.
>
>The use cases we've been involved with start with a description of what the
>user needs to be able to do -- regardless of where or how that will be
>accomplished in the application. As the use cases iterate, they become more
>specific and eventually include field level accuracy.
>
>I know that use case definitions and methods for developing them vary widely
>across companies that employ them, but the functional spec sure sounds like
>the same approach.

BF: I think use cases and functional specs (at least as I use the
term) are two approaches to describing what the product must do,
prior to figuring out (designing) how to do it. My impression is
that functional specs tend to be lists of functions (e.g. "log in",
"log out"), whereas use case sets tend to be lists of tasks with the
steps needed to accomplish them (e.g. "View Account History: 1 log
in, 2 navigate to account history facility, 3 specify date range, 4
view resulting list of transactions", etc.). It is also my
impression that use case sets often end up being used as the
skeletons for both engineering and UI designs, and for product
testing -- in which cases they morph over time (as you describe
above).

BF: I also think that different people/organizations use these terms
in different ways. The important thing to me is that, whatever
tools/docs/terms we use, I am able to work productively and
effectively with the necessary constituencies (e.g. engineering,
marketing, management) and maximize the extent to which my expertise
is appropriately utilized in creating the best possible products. I
have always found that some form of synchronization of expectations
is key, and that exactly what form this takes varies between clients
and projects.

--

======================================================================
Bill Fernandez * User Interface Architect * Bill Fernandez Design

(505) 346-3080 * bf_list1 AT billfernandez DOT com *
http://billfernandez.com
======================================================================

22 Oct 2007 - 6:56am
Adrian Howard
2005

On 21 Oct 2007, at 19:18, Joseph Selbie wrote:

> "Indeed I just received from a client, who often involves me at the
> beginning of each project, an early draft of a document titled
> "functional spec for...", that did not say anything about the UI or
> the technical plumbing -- it was just a description of the various
> things the product had to do."

That is a pretty common name for that sort of document in my experience.

Cheers,

Adrian

22 Oct 2007 - 7:07am
Adrian Howard
2005

On 21 Oct 2007, at 21:06, Peter Boersma wrote:
[snip]
> (I am not satisfied with what they're documenting though; half of
> it is a rewrite of our specs. When we say "the 'edit' link takes
> the user to the page where she edits the relevant items" I'd expect
> them to document what software function is called and what the
> parameters are, not repeat our message.)
[snip]

Why are they doing it?

Personally I would expect the developers to just refine, rather than
rewrite. Once you get to the level of software functions/parameters
it's more effective to write code. What they do need to do is take
the domain concepts form the IxD/UX-oriented documents and understand
them well enough to embody them in the code.

Something I've been playing with a bit is getting folk to use tools
like FIT and various Behaviour Driven Development tools to encourage
folk to start turning the specification into automated tests rather
than Yet More Paper.

Cheers,

Adrian

22 Oct 2007 - 7:12am
Peter Boersma
2003

Adrian wrote:
> Personally I would expect the developers to just refine, rather than
> rewrite. [..] What [functional designers/developers?] do need to do is take
> the domain concepts form the IxD/UX-oriented documents and understand
> them well enough to embody them in the code.

What form do these refinements and understandings take?

Peter
--
Peter Boersma | Senior Interaction Designer | Info.nl
http://www.peterboersma.com/blog | http://www.info.nl

22 Oct 2007 - 2:54pm
lois lewis
2007

HI all,
A few thoughts - first I often call "What a product should do"
Business requirements - not functional requirements.

Also I recently worked on a project where I helped craft the business
requirements by working with users and I created a UI specification
but the developers kept complaining that there was no "functional
specification" This was not a web product but a thick-client app -
with an interface but also with many business rules that I didn't
have the knowledge to document - I just said something like "system
applies limits to data entry - here is how a limit appears to the
user" but I didn't say anything about how those limits were applied
through the workflow management tool.

The developers I worked with expected that to be in a doc too - but I
knew it wasn't me that wrote that kind of a doc - they called it a
functional spec..

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://gamma.ixda.org/discuss?post=21651

22 Oct 2007 - 3:54pm
Christopher Fahey
2005

> A few thoughts - first I often call "What a product should do"
> Business requirements - not functional requirements.

Yes!

My ideal process:

1) Business Requirements -- what the business wants to do
2) UI Spec - what the user experiences to deliver #1 successfully
3) Functional Spec - what the machines do to deliver #2 successfully

Before, during, and after all of these steps, there are many
opportunities for research. My concern is when #2 and #3 are
reversed. Or when #1 is dumb.

-Cf

Christopher Fahey
____________________________
Behavior
biz: http://www.behaviordesign.com
me: http://www.graphpaper.com

23 Oct 2007 - 4:36am
Adrian Howard
2005

On 22 Oct 2007, at 13:12, Peter Boersma wrote:

> Adrian wrote:
> > Personally I would expect the developers to just refine, rather than
> > rewrite. [..] What [functional designers/developers?] do need to
> do is take
> > the domain concepts form the IxD/UX-oriented documents and
> understand
> > them well enough to embody them in the code.
>
> What form do these refinements and understandings take?
This is an excerpt of something I posted over on agile-usabilty last
year... hopefully it illustrates the sort of thing I'm talking about.

--
[...] a workflow I designed that always had one
"happy path" from each stage - the route that most users would follow.

This was highlighted in the visual appearance of each page of the
workflow. The "happy path" button was a different colour and size,
and always appeared before any buttons on the page on the right hand
side.

Now - we already had a system for implementing basic HTML workflows
(a little state transition network glued to some basic templating).
The developers could have just implemented workflows with a "happy
path" using this, styling the default-route buttons appropriately.

The problem with doing this is that none of the design concepts of
the "happy path" route end up in the code. Later on somebody could
implement pages with multiple "happy path" buttons, or ones that are
in the wrong position, or pages with no default route.

So instead we subclass the state transition code and add the
HappyPath concept. We make sure that it's impossible to instantiate
an instance of a workflow that has pages with multiple happy paths,
or no happy path at all.

We subclass the template code so that happy path buttons are
automatically styled appropriately and are only permitted in certain
areas of the page layout. We even make the CSS for the "happy path"
button linked to an id rather than a class so it's impossible to have
more than one on a page.
--
So we're taking a IxD design concept (the "happy path" + button +
location) and refining it a little bit more so we can make it an
explicit concept in the code.

Make sense?

Cheers,

Adrian

23 Oct 2007 - 4:42am
Adrian Howard
2005

On 22 Oct 2007, at 21:54, Christopher Fahey wrote:

>> A few thoughts - first I often call "What a product should do"
>> Business requirements - not functional requirements.
>
> Yes!
>
> My ideal process:
>
> 1) Business Requirements -- what the business wants to do
> 2) UI Spec - what the user experiences to deliver #1 successfully
> 3) Functional Spec - what the machines do to deliver #2 successfully

Personally I find doing 2 & 3 at the same time to be more effective
than doing all the UI work up-front. So much of (2) needs to be
communicated to (3) I find it saves an enormous amount of time
producing artefacts when it would be much easier to have everybody in
the same room.

Adrian

Syndicate content Get the feed