Poll: Are you still writing UX specs?

31 Jul 2011 - 6:29pm
14 weeks ago
21 replies
3415 reads
eriklevitch
2008

Are you? If so, do you feel it is necessary?

Comments

31 Jul 2011 - 9:32pm
Yvonnia Martin
2009

Hi Erik,

Yes, we are still writing specs in our department...very detailed specs. We have now added simulations along with these detailed specs. Sometimes I think: "Dear God, if I write one more 'OnClick' or 'IF' I'm going to scream". But then there are other times, when during a heated discussion about functionality, I can pull up an archived spec that clearly states the standards for how a certain component is supposed to function. I think a good balance would be an archive/library of simulations accompanied with basic specs.

JMHO,

Yvonnia

1 Aug 2011 - 3:05pm
tstutts
2008

Hi Erik,

In my experience, it's whatever you need to do to make functionality and graphics completely clear, when it's absolutely imperative that it be that way. If your client doesn't mind a component sort of looking and sort of functioning the way it does within the wires (and some just don't or are willing to leave it engineering to come up with the easiest solution), then I may not spec it out, especially if the budget won't cover those details, but every now and then, yep, I will have a wire that drills down the to the exact dimensions and functionality of a component, showing ever behavior/state. So in answer to your question, sometimes.

Tim

On Mon, Aug 1, 2011 at 6:37 AM, Yvonnia Martin wrote: > Hi Erik, > > Yes, we are still writing specs in our department...very detailed specs. We > have now added simulations along with these detailed specs. Sometimes I > think: "Dear God, if I write one more 'OnClick' or 'IF' I'm going to > scream". But then there are other times, when during a heated discussion > about functionality, I can pull up an archived spec that clearly states the > standards for how a certain component is supposed to function. I think a > good balance would be an archive/library of simulations accompanied with > basic specs. > > JMHO, > > Yvonnia > >

1 Aug 2011 - 10:05pm
Christine Boese
2006

Perhaps the real question here is, "Is anyone reading your specs?"
I've worked all different ways, in quick cycle Agile situations with "lite" specs, in CYA spec'ing for backup in the face of a less-than-stellar IT department, and when working in isolation to hand-off designs across the continent to a huge dev team who would have to execute and build the project out after we'd all rolled off. 
In all cases, there is an even bigger problem with basic specifications: the "interface design" of spec-documents (basically a tech writing task) SUCKS. 
The spec documents are nearly unusable and unreadable, whether as spot reference documents for later site updates (how many have you seen that had no tables of contents?), or a rambling "annotation-style" organization, or are just pages and pages of tables.
We worry about the usability of what we design. What about the usability of specs and the spec'ing process?
I'm not saying the specs are always to blame. There has been a general decline in literacy levels over the past 20 years. Cross-cultural communication studies speak of "high-context cultures" vs. "low-context cultures," which, removed from their cultural associations, generally also map out to high-context=highly literate and able to contextualize things for themselves vs. low-context=skimmers who expect to be spoon-fed everything they need in very basic terms. Like See Jane run terms. I've seen this in college students over the decades as well, and it is why textbooks have necessarily gotten so dumbed-down in the US. 
Maybe our specs have to be more dumbed down too? Time-pressured teams, trying to work with the specs, or worse, blowing them off entirely, using the philosophy of "Build it first, and let QA check it against the specs"? I'm certain, on a number of instances, developers never read the specs once. They just grabbed the comps and wires and waded in.
Just some stuff to think about,
Chris

On Mon, Aug 1, 2011 at 4:32 PM, Tim Stutts9 <timstutts@gmail.com> wrote:

Hi Erik,

In my experience, it's whatever you need to do to make functionality
and graphics completely clear, when it's absolutely imperative that it
be that way. If your client doesn't mind a component sort of looking
and sort of functioning the way it does within the wires (and some
just don't or are willing to leave it engineering to come up with the
easiest solution), then I may not spec it out, especially if the
budget won't cover those details, but every now and then, yep, I will
have a wire that drills down the to the exact dimensions and
functionality of a component, showing ever behavior/state. So in
answer to your question, sometimes.

Tim

On Mon, Aug 1, 2011 at 6:37 AM, Yvonnia Martin wrote:
> Hi Erik,
>
> Yes, we are still writing specs in our department...very detailed specs. We
> have now added simulations along with these detailed specs. Sometimes I
> think: "Dear God, if I write one more 'OnClick' or 'IF' I'm going to
> scream". But then there are other times, when during a heated discussion
> about functionality, I can pull up an archived spec that clearly states the
> standards for how a certain component is supposed to function. I think a
> good balance would be an archive/library of simulations accompanied with
> basic specs.
>
> JMHO,
>
> Yvonnia
>
>

(((
1 Aug 2011 - 11:21pm
Aditya Saxena
2009

Hi, I have just one question and please forgive me if this is not the right forum - can someone share good resources of how to write a UI / UX spec.

Thanks for the help!

- Aditya

2 Aug 2011 - 12:15am
eriklevitch
2008

I tend to write interaction specifications while avoiding overtly technical specifications. In my mind, it is the best use of my time to write annotations from the user's perspective. If I add technical specifications to wireframes, then I feel like my document is trying to accomplish too many things at once. 

However, how many interaction designers are completely bypassing wireframes and just prototyping? Obviously, a prototype communicates functionality/interactivity more than a static document ever could.

Do you still create documentation or do you use other methods to communicate your design?

 

- Erik

2 Aug 2011 - 3:06am
Sonali Bendre
2009

My experience is that people don't like to read. They understand visuals better.
I make interaction specifications a part of wireframes. It appear as call-outs on wireframes. And people do read and comment on it. I also add technical questions there if any. It helps them correlate it with the interaction specs.
It works well! Making a separate document just for UI specs works for our own understanding. But may not be finally read by the stakeholders.
 
-Sonali

 

> To: sonasb@hotmail.com
> Subject: Re: [IxDA] Poll: Are you still writing UX specs?
> From: eriklevitch@gmail.com
> Date: Tue, 2 Aug 2011 00:32:55 -0500
>
> I tend to write interaction specifications while avoiding overtly technical
> specifications. In my mind, it is the best use of my time to write
> annotations from the user's perspective. If I add technical specifications to
> wireframes, then I feel like my document is trying to accomplish too many
> things at once. 
>
> However, how many interaction designers are completely bypassing wireframes
> and just prototyping? Obviously, a prototype communicates
> functionality/interactivity more than a static document ever could.
>
> Do you still create documentation or do you use other methods to communicate
> your design?
>
>  
>
> - Erik
>
>

2 Aug 2011 - 5:05pm
Mimi Hui
2009

I agre w/ Sonali.  We use Axure and even then, developers and clients frequently don't read anything.
Mimi

On Tue, Aug 2, 2011 at 8:22 AM, Sonali Bendre <sonasb@hotmail.com> wrote:

My experience is that people don't like to read. They understand visuals better.
I make interaction specifications a part of wireframes. It appear as call-outs on wireframes. And people do read and comment on it. I also add technical questions there if any. It helps them correlate it with the interaction specs.
It works well! Making a separate document just for UI specs works for our own understanding. But may not be finally read by the stakeholders.
 
-Sonali
 

> To: sonasb@hotmail.com
> Subject: Re: [IxDA] Poll: Are you still writing UX specs?
> From: eriklevitch@gmail.com
> Date: Tue, 2 Aug 2011 00:32:55 -0500
>
> I tend to write interaction specifications while avoiding overtly technical
> specifications. In my mind, it is the best use of my time to write
> annotations from the user's perspective. If I add technical specifications to
> wireframes, then I feel like my document is trying to accomplish too many
> things at once. 
>
> However, how many interaction designers are completely bypassing wireframes
> and just prototyping? Obviously, a prototype communicates
> functionality/interactivity more than a static document ever could.
>
> Do you still create documentation or do you use other methods to communicate
> your design?
>
>  
>
> - Erik
>
>

(((Ple
2 Aug 2011 - 9:05pm
Cindy Lu
2006

Hi!

I agree that people don't read UI specs in general. However, we have found that we still need the UI specs because, some behaviors are not easily demonstrated in the prototype or mockup. Even we can explain the behavior but developers may misunderstand it or we may forget to explain it in reviews.

Since we only document the behavior when it is not obvious in the prototype or mockup so our UI spec is usually thin. We also put all the messages in the UI spec. It helps both dev and QA team. It also serves as a reminder for our team.

If the delivery is mockup, it is ok to write the specs as notes by the design instead of a separate document. The goal is just to serve as a reminder.

  • Cindy

Sent from my iPad

On Aug 2, 2011, at 18:38, Mimi Hui wrote:

> I agre w/ Sonali. We use Axure and even then, developers and clients frequently don't read anything. > Mimi > > On Tue, Aug 2, 2011 at 8:22 AM, Sonali Bendre wrote: > >> My experience is that people don't like to read. They understand visuals better. >> I make interaction specifications a part of wireframes. It appear as call-outs on wireframes. And people do read and comment on it. I also add technical questions there if any. It helps them correlate it with the interaction specs. >> >> It works well! Making a separate document just for UI specs works for our own understanding. But may not be finally read by the stakeholders. >>
>> -Sonali >>
>> >> > To: sonasb@hotmail.com [2] >> > Subject: Re: [IxDA] Poll: Are you still writing UX specs? >> > From: eriklevitch@gmail.com [3] >> > Date: Tue, 2 Aug 2011 00:32:55 -0500 >> > >> > I tend to write interaction specifications while avoiding overtly technical >> > specifications. In my mind, it is the best use of my time to write >> > annotations from the user's perspective. If I add technical specifications to >> > wireframes, then I feel like my document is trying to accomplish too many >> > things at once. >> > >> > However, how many interaction designers are completely bypassing wireframes >> > and just prototyping? Obviously, a prototype communicates >> > functionality/interactivity more than a static document ever could. >> > >> > Do you still create documentation or do you use other methods to communicate >> > your design? >> > >> >
>> > >> > - Erik >> > >> > >> >> (((Ple >> >

2 Aug 2011 - 11:06pm
yoni
2009

I agree with your points about developers and/or clients not reading (or understanding) any sort of specs or wireframes. I've always hated them, no matter what role I've been in.

As a prototyper, my prototypes are my primary deliverable. Consequently, my first rule is that I do not just "deliver" the prototypes. Prototypes are delivered (first seen and/or made available) in a review meeting or call. This allows me to steer the discussion, and make sure the purpose of the prototype is understood (rather than peripheral aspects of the things, which are not central).

This helps, but of course, people don't pay attention, or they often forget. So, in addition to any research-related artifacts, I typically deliver some manner of simple design description with screenshots (wireframe-y) for each major piece. More importantly, I provide annotated screen-recordings of the prototype in action. This allows clients, developers, and QA to understand precisely what is desired from an interaction -- no language barrier.

"What do you mean by this yada yada yada on click?" "This!"

It also expresses flow, in general, far better than any flat static deliverable I've ever seen.

"What happens here? Where will the user go after/next?" "This! There!"

No confusion, no communication barrier, no big-ass document or diagram that is unlikely to be read or understood by critical project/team players.

~ yoni

~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~

Jonathan S. Knoll email: jonathan@infinityplusone.com web: http://infinityplusone.com/ linkedin: http://www.linkedin.com/in/jonathanknoll twitter: @yoni

On Aug 2, 2011, at 11:06 PM, Cindy Lu wrote:

> Hi! > > I agree that people don't read UI specs in general. However, we have found that we still need the UI specs because, some behaviors are not easily demonstrated in the prototype or mockup. Even we can explain the behavior but developers may misunderstand it or we may forget to explain it in reviews. > > Since we only document the behavior when it is not obvious in the prototype or mockup so our UI spec is usually thin. We also put all the messages in the UI spec. It helps both dev and QA team. It also serves as a reminder for our team. > > If the delivery is mockup, it is ok to write the specs as notes by the design instead of a separate document. The goal is just to serve as a reminder. > > * Cindy > > Sent from my iPad > > On Aug 2, 2011, at 18:38, Mimi Hui wrote: > > > I agre w/ Sonali. We use Axure and even then, developers and clients frequently don't read anything. > > Mimi > > > > On Tue, Aug 2, 2011 at 8:22 AM, Sonali Bendre wrote: > > > >> My experience is that people don't like to read. They understand visuals better. > >> I make interaction specifications a part of wireframes. It appear as call-outs on wireframes. And people do read and comment on it. I also add technical questions there if any. It helps them correlate it with the interaction specs. > >> > >> It works well! Making a separate document just for UI specs works for our own understanding. But may not be finally read by the stakeholders. > >> > >> -Sonali > >> > >> > >> > To: sonasb@hotmail.com [2] > >> > Subject: Re: [IxDA] Poll: Are you still writing UX specs? > >> > From: eriklevitch@gmail.com [3] > >> > Date: Tue, 2 Aug 2011 00:32:55 -0500 > >> > > >> > I tend to write interaction specifications while avoiding overtly technical > >> > specifications. In my mind, it is the best use of my time to write > >> > annotations from the user's perspective. If I add technical specifications to > >> > wireframes, then I feel like my document is trying to accomplish too many > >> > things at once. > >> > > >> > However, how many interaction designers are completely bypassing wireframes > >> > and just prototyping? Obviously, a prototype communicates > >> > functionality/interactivity more than a static document ever could. > >> > > >> > Do you still create documentation or do you use other methods to communicate > >> > your design? > >> > > >> > > >> > > >> > - Erik > >> > > >> > > >> > >> (((Ple > >> > > > >

2 Aug 2011 - 11:06pm
yoni
2009

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Arial} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Arial; min-height: 14.0px} p.p3 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Arial; color: #164fae} span.s1 {color: #000000} span.s2 {text-decoration: underline} span.Apple-tab-span {white-space:pre}

I agree with your points about developers and/or clients not reading (or understanding) any sort of specs *or* wireframes. I've always hated them, no matter *what* role I've been in.


As a prototyper, my prototypes are my primary deliverable. Consequently, my first rule is that I do not just "deliver" the prototypes. Prototypes are delivered (first seen and/or made available) in a review meeting or call. This allows me to steer the discussion, and make sure the purpose of the prototype is understood (rather than peripheral aspects of the things, which are not central).


This helps, but of course, people don't pay attention, or they often forget. So, in addition to any research-related artifacts, I typically deliver some manner of simple design description with screenshots (wireframe-y) for each major piece. More importantly, I provide annotated screen-recordings of the prototype in action. This allows clients, developers, and QA to understand *precisely* what is desired from an interaction -- no language barrier. 


"What do you mean by this yada yada yada on click?"


<press play>


"This!" 


It also expresses flow, in general, far better than any flat static deliverable I've ever seen.


"What happens here? Where will the user go after/next?"


<press play>


"This! There!" 


No confusion, no communication barrier, no big-ass document or diagram that is unlikely to be read or understood by critical project/team players.




~ yoni


~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~


Jonathan S. Knoll

email: jonathan@infinityplusone.com

web: http://infinityplusone.com/

linkedin: http://www.linkedin.com/in/jonathanknoll

twitter: @yoni


On Tue, Aug 2, 2011 at 11:06 PM, Cindy Lu <cindylu01@gmail.com> wrote:

Hi!

I agree that people don't read UI specs in general. However, we have found that we still need the UI specs because, some behaviors are not easily demonstrated in the prototype or mockup. Even we can explain the behavior but developers may misunderstand it or we may forget to explain it in reviews.

Since we only document the behavior when it is not obvious in the prototype or mockup so our UI spec is usually thin. We also put all the messages in the UI spec. It helps both dev and QA team. It also serves as a reminder for our team.

If the delivery is mockup, it is ok to write the specs as notes by the design instead of a separate document. The goal is just to serve as a reminder.

* Cindy

Sent from my iPad

On Aug 2, 2011, at 18:38, Mimi Hui wrote:

> I agre w/ Sonali. We use Axure and even then, developers and clients frequently don't read anything.
> Mimi
>
> On Tue, Aug 2, 2011 at 8:22 AM, Sonali Bendre wrote:
>
>> My experience is that people don't like to read. They understand visuals better.
>> I make interaction specifications a part of wireframes. It appear as call-outs on wireframes. And people do read and comment on it. I also add technical questions there if any. It helps them correlate it with the interaction specs.
>>
>> It works well! Making a separate document just for UI specs works for our own understanding. But may not be finally read by the stakeholders.
>>
>> -Sonali
>>
>>
>> > To: sonasb@hotmail.com [2]
>> > Subject: Re: [IxDA] Poll: Are you still writing UX specs?
>> > From: eriklevitch@gmail.com [3]
>> > Date: Tue, 2 Aug 2011 00:32:55 -0500
>> >
>> > I tend to write interaction specifications while avoiding overtly technical
>> > specifications. In my mind, it is the best use of my time to write
>> > annotations from the user's perspective. If I add technical specifications to
>> > wireframes, then I feel like my document is trying to accomplish too many
>> > things at once.
>> >
>> > However, how many interaction designers are completely bypassing wireframes
>> > and just prototyping? Obviously, a prototype communicates
>> > functionality/interactivity more than a static document ever could.
>> >
>> > Do you still create documentation or do you use other methods to communicate
>> > your design?
>> >
>> >
>> >
>> > - Erik
>> >
>> >
>>
>> (((Ple
>>
>

(((
2 Aug 2011 - 9:41pm
Jared M. Spool
2003

Hi Erik,

I had a chance last year to talk to Bill Scott from Netflix who told me about a technique he uses called an "Interesting Moments Grid."

It's basically all the objects in the design down the side (such as sources, targets, or the cursor) and all the states across the top ("before selection", "after selection", "while dragging", or "mouse release"). He then can quickly document how each elements behaves during each state, filling in only those intersections that are interesting to the development process.

You can read more about the technique here: Capturing the Interesting Moments

Hope that helps,

Jared M. Spool

3 Aug 2011 - 4:06pm
uxtweaker
2009

There's also an interesting video about "Interesting Moments" at http://www.youtube.com/watch?v=thdfW4aCQjc

On 3 August 2011 09:42, Jared M. Spool <jspool@uie.com> wrote:

Hi Erik,

I had a chance last year to talk to Bill Scott from Netflix who told me about a technique he uses called an "Interesting Moments Grid."

It's basically all the objects in the design down the side (such as sources, targets, or the cursor) and all the states across the top ("before selection", "after selection", "while dragging", or "mouse release"). He then can quickly document how each elements behaves during each state, filling in only those intersections that are interesting to the development process.

You can read more about the technique here: Capturing the Interesting Moments [1]

Hope that helps,

Jared M. Spool

(
2 Aug 2011 - 10:48pm
yoni
2009

I agree with your points about developers and/or clients not reading (or understanding) any sort of specs *or* wireframes. I've always hated them, no matter *what* role I've been in.

As a prototyper, my prototypes are my primary deliverable. Consequently, my first rule is that I do not just "deliver" the prototypes. Prototypes are delivered (first seen and/or made available) in a review meeting or call. This allows me to steer the discussion, and make sure the purpose of the prototype is understood (rather than peripheral aspects of the things, which are not central).

This helps, but of course, people don't pay attention, or they often forget. So, in addition to any research-related artifacts, I typically deliver some manner of simple design description with screenshots (wireframe-y) for each major piece. More importantly, I provide annotated screen-recordings of the prototype in action. This allows clients, developers, and QA to understand *precisely* what is desired from an interaction -- no language barrier. 

      "What do you mean by this yada yada yada on click?"

      <press play>

      "This!" 

It also expresses flow, in general, far better than any flat static deliverable I've ever seen.

      "What happens here? Where will the user go after/next?"

      <press play>

      "This! There!" 

No confusion, no communication barrier, no big-ass document or diagram that is unlikely to be read or understood by critical project/team players.

~ yoni

~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~ ~~ ~
Jonathan S. Knoll
email: jonathan@infinityplusone.com
web: http://infinityplusone.com/
linkedin: http://www.linkedin.com/in/jonathanknoll
twitter: @yoni

 

3 Aug 2011 - 12:53am
jasonmesut
2010

Yes, we still use them.

It's dissapointing seeing specifications being so disregarded in our industry. I've had problems with them throughout my career, especially around people not reading or following them, but I still value them as a part of what we should often do, or at least have done a fair bit of in our careers.

One of the best things about writing a specification is forcing you to think through every state and every permutation of interaction. It actually helps you refine your design better, in my experience. As does prototyping, but prototyping shouldn't necessarily cover every eventuality. If it does, then it might as well be the real thing.

Nothing replaces dialogue and interaction between disciplines, but even with this, having something that clearly articulates any rules, interactions and states can be useful for developing better software.

I understand, that there are levels of specification and that sometimes you just don't have time or the need, but that shouldn't mean that young Interaction Designers or IAs shouildn't learn to better conssider and define their design for others to understand.

It's simply not black and white, and making it seem as though it is could be incredibly detrimental for our industry.

3 Aug 2011 - 12:56am
eriklevitch
2008

Thank you everyone! I suppose the purpose of your work always depends on the project, but I'd like to get to a point where I don't have to focus on specifications. I don't know if they are going away anytime soon, but it would be nice: P

3 Aug 2011 - 9:07am
Jack L. Moffett
2005

Jason makes an excellent point. The process of creating the specification (in whatever form it may take) is an important step of the design process. If you are doing it well, it forces you to think about details that may have been overlooked in sketches, wireframes, and mockups. 

As for specifications not being read, that's a process/management problem. I'm responsible for creating a specification that is complete and correct. If I deliver a spec to the developers that is insufficient, I'm taken to task by my manager. On the flip side, if a developer doesn't follow my spec, they take the heat.

To put this into context, I should also point out that my company does contract work for the military, and the specifications are contractual delivarables, so we probably think about the specifications a little differently than, say, a design firm doing marketing sites or an iPhone app shop.

I'm currently on the lookout for methods to optimize my specification workflow for both efficiency in production and robustness of the content. I like the concept of the Interesting Moments Grid, so thanks for that reference, Jared.

3 Aug 2011 - 5:06pm
timsheiner@gmail.com
2007

Agree strongly with Jason that writing the spec is a crucial part of helping me think through all the cases.  I see it as a kind of prototyping--I'll find a bunch of the missed cases when I write the spec, but of course I'll find even more if I build an interactive prototype. 
I've used the "interesting moments" grid and think it is a great approach.  I got it from the book Bill wrote with Theresa Neil.  I've also extended or modified it where I use the same idea of grid but to explain cases.  In other words, the entire grid is about a single component, and then down the left side are listed cases that might affect its behavior (for example, UI modes) and then across the top will be events like mouse over, etc.  Developers absolutely love this kind of thing because it is then just a bunch of rules for them to code.
Another technique I use is that I've developed a specification framework that covers all aspects of a UI/UX design, and I start with that framework for my specs, as a wiki page, but then I only fill in the parts I think are relevant/need clarification for the given project at a given stage.  What often happens is that over time more and more of the framework gets filled out, but I only do this in response to a specific question from a developer (or product manager) about something that is ambiguous.  Because it is a wiki page the versioning issue more or less goes away.
I created based the framework on Jesse James Garrett's Elements of User Experience; here is a link to the framework on my blog:  http://timsheiner.com/blog/?p=111
Tim


On Wed, Aug 3, 2011 at 2:09 PM, Jack L. Moffett <jackmoffett@mac.com> wrote:

Jason makes an excellent point. The process of creating the specification (in whatever form it may take) is an important step of the design process. If you are doing it well, it forces you to think about details that may have been overlooked in sketches, wireframes, and mockups. 

As for specifications not being read, that's a process/management problem. I'm responsible for creating a specification that is complete and correct. If I deliver a spec to the developers that is insufficient, I'm taken to task by my manager. On the flip side, if a developer doesn't follow my spec, they take the heat.

To put this into context, I should also point out that my company does contract work for the military, and the specifications are contractual delivarables, so we probably think about the specifications a little differently than, say, a design firm doing marketing sites or an iPhone app shop.

I'm currently on the lookout for methods to optimize my specification workflow for both efficiency in production and robustness of the content. I like the concept of the Interesting Moments Grid, so thanks for that reference, Jared.

(((Please
5 Aug 2011 - 2:05pm
Louise Hewitt
2010

:D I write them, I charge for them, they ignore them. But when it comes out wrong I can hit them over the head with them. Only reason to do them in Axure - you get lottttts of paper.

On 4 Aug 2011, at 01:35, timsheiner@gmail.com wrote:

> Agree strongly with Jason that writing the spec is a crucial part of helping me think through all the cases. I see it as a kind of prototyping--I'll find a bunch of the missed cases when I write the spec, but of course I'll find even more if I build an interactive prototype. > I've used the "interesting moments" grid and think it is a great approach. I got it from the book Bill wrote with Theresa Neil. I've also extended or modified it where I use the same idea of grid but to explain cases. In other words, the entire grid is about a single component, and then down the left side are listed cases that might affect its behavior (for example, UI modes) and then across the top will be events like mouse over, etc. Developers absolutely love this kind of thing because it is then just a bunch of rules for them to code. > Another technique I use is that I've developed a specification framework that covers all aspects of a UI/UX design, and I start with that framework for my specs, as a wiki page, but then I only fill in the parts I think are relevant/need clarification for the given project at a given stage. What often happens is that over time more and more of the framework gets filled out, but I only do this in response to a specific question from a developer (or product manager) about something that is ambiguous. Because it is a wiki page the versioning issue more or less goes away. > I created based the framework on Jesse James Garrett's Elements of User Experience; here is a link to the framework on my blog: http://timsheiner.com/blog/?p=111 [1] > Tim > > On Wed, Aug 3, 2011 at 2:09 PM, Jack L. Moffett wrote: > >> Jason makes an excellent point. The process of creating the specification (in whatever form it may take) is an important step of the design process. If you are doing it well, it forces you to think about details that may have been overlooked in sketches, wireframes, and mockups. >> >> As for specifications not being read, that's a process/management problem. I'm responsible for creating a specification that is complete and correct. If I deliver a spec to the developers that is insufficient, I'm taken to task by my manager. On the flip side, if a developer doesn't follow my spec, they take the heat. >> >> To put this into context, I should also point out that my company does contract work for the military, and the specifications are contractual delivarables, so we probably think about the specifications a little differently than, say, a design firm doing marketing sites or an iPhone app shop. >> >> I'm currently on the lookout for methods to optimize my specification workflow for both efficiency in production and robustness of the content. I like the concept of the Interesting Moments Grid, so thanks for that reference, Jared. >> >> (((Please >> >

6 Aug 2011 - 7:07pm
tstutts
2008

To an earlier comment from Erik...

> However, how many interaction designers are completely bypassing wireframes and just > prototyping? Obviously, a prototype communicates functionality/interactivity more than a > static document ever could.

But it could be a total waste of time and money down the road, if the client decides to switch gears after seeing an initial prototype design. I say do everything you can in wireframes until A) you have total commitment from the client on a concept or B) they are not able to grasp a concept, and need to interact with it to understand it or C) you already know exactly what they want from the get-go because it's super straightforward, thus wires are a waste of time. When I started out as an interaction designer I had an attitude of always going directly to a prototype, but was proven that this was the wrong approach enough times, that now I know better.

19 Apr 2012 - 4:02am
PaulWeb
2012

Writing specs is actually a good habit, but sometimes, it depends on the requirements of my clients. My dedicated clients who know their stuff often request that I write UX specs, and even though I hate writing them, I have to follow their instructions.

30 Apr 2012 - 2:00am
PaulWeb
2012

I think the effect of skipping the specs totally for a small project might not be apparent, but in a large scale project, these will come in handy and save a lot of time for everyone.

Paul - http://www.connetu.com

Syndicate content Get the feed