Do you ask for Functions or Scenarios?
Before testing: If you want a product with good UX, do you give the
programmers a list of functions or a list of scenarios?
Usually people write a functional spec for a software/website they want,
which they then give to the programmer. The programmer will create a
program/website with the functions you requested. The programmer comes back
and feels great about this product he created for you, with all the
functions you asked for, maybe even threw in a few extra.
You try the program and it has all the functions, but it is impractical. You
want to add a new item to a list; it takes 5 clicks, etc. etc.
So my questions are: Do you provide scenarios in your functional spec or
does this get done afterwards? Should you be providing a list of functions
or will a list of scenarios provide better results?
Comments
(My 2 devaluated cents.)
We should structure our deliverables under the same philosophy of our
general UX work. In other words, do user testing. In this case the
users are the developers. Present both of the above-mentioned
alternatives and find out which one works best for them.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=28356
On Apr 23, 2008, at 6:53 AM, "AJ Kock" <ajkock at gmail.com> wrote:
> Before testing: If you want a product with good UX, do you give the
> programmers a list of functions or a list of scenarios?
Neither. If I want a product with a good user experience, I give the
programmers a detailed specification that describes and visualizes
exactly the way every function should be made available, look, and
behave.
Good design a feature list or scenario does not make.
Jack
Unfortunately, I think that most programmers wouldn't know what to do
with a scenario. In an elevated organization where everyone "gets it",
then the programmers would have been involved in the design from the
beginning and would have a deep understanding of what/why they are
building.
So, in most organizations, a functional spec is expected and you'll
deliver what's expected. Can you give scenarios to the testers? Can
you give both to the programmers and see which works better for them?
...Dan
On Apr 23, 2008, at 3:53 AM, AJ Kock wrote:
> So my questions are: Do you provide scenarios in your functional
> spec or
> does this get done afterwards? Should you be providing a list of
> functions
> or will a list of scenarios provide better results?
The reason why I thought scenarios might assist programmers (on top of
the feature list) is that scenarios might help programmers understand
how the user will use the program. If they understand that users will
need access to point A,B,F,G on a particular page and that they need
to send it all via email in a certain time period, they will hopefully
not design a program where you would have to go to point A,B,F,G on
seperate pages and add the info to the email. But rather have access
to A,B,F,G's content directly from the particular "page" you are at.
I thought it was pretty obvious that "feature list thinking" is what
leads to mobile companies creating phones with a list of non-used
features. If they understood scenarios, we might have had more "good"
mobile phones.
Tell them how you want your program to behave in doing dealing with stuff.
The interface is the program to the users, all the functions behind don't
matter in their eyes.
And the best interface is a plain simple one.
In my opinion, only 5% of users do need more than the basics and those were
quite happy with the Word Perfect coding possibilities for more complex
tasks...
Pieter Jansegers
http://webosophy.ning.com
I would say give programmers all the results of your work as they move
into development. Don't make assumptions regarding what they will
find useful or what they will understand. The best programmers "get
it" and want all the info. The best thing you can do is bring
programmers into the project early and work collaboratively in areas
of overlap (like IA and wire framing).
If you give them a list of specs then all you'll get in return is a
set of functionality. Share the process with them and the result will
reflect their deeper understanding.
Similarly, you may find that your work is better informed and fully
leverages the technology if you maintain a dialog with programmers
through out the process.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=28356
It's interesting to note that some agile methodologies -- like SCRUM
-- start the development process from "user stories", which can be
based on user scenarios.
{ Itamar Medeiros }
http://designative.info/
http://www.autodesk.com/
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=28356
It seems that the guys/girls over at 37Signals also prefer design over
functional spec.
http://www.37signals.com/svn/archives2/the_interface_as_a_spec_including_stories_inline.php
Wow - if only they could actually design an interface they would rock!
On Tue, May 13, 2008 at 7:48 AM, AJKock <ajkock at gmail.com> wrote:
> It seems that the guys/girls over at 37Signals also prefer design over
> functional spec.
>
> http://www.37signals.com/svn/archives2/the_interface_as_a_spec_including_stories_inline.php
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> Unsubscribe ................ http://www.ixda.org/unsubscribe
> List Guidelines ............ http://www.ixda.org/guidelines
> List Help .................. http://www.ixda.org/help
>
--
~ will
"Where you innovate, how you innovate,
and what you innovate are design problems"
---------------------------------------------------------------------------------------------
Will Evans | User Experience Architect
tel +1.617.281.1281 | will at semanticfoundry.com
twitter: https://twitter.com/semanticwill
---------------------------------------------------------------------------------------------
Yes, you're right, I think it will take some time to resolve this
Ioana, Bucuresti
I am al about involving the programmers from the beginning. I present
my wireframe%u2019s, mockup%u2019s, findings from my paper
prototypingsession. I Also make my field study documents available.
Within the company I managed to get my own space to place all the
information and guess what everyone loves it. My boss is happy
because he sees that there is stil progress in the project even
though nothing has been build. The users are happy because they are
taken seriously en they are being listened to. And the programmers
actually know what to do!
To spread awareness I also developed a poster and distributed it
throughout the building(s)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://www.ixda.org/discuss?post=28356