Poll: Are you still writing UX specs?

31 Jul 2011 - 6:29pm

Last reply:
1 year ago

21 replies

4147 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

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

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.

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

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.

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.

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.

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=111Tim

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.