The Documentation View of Design

29 Apr 2008 - 2:01pm
6 years ago
1 reply
667 reads
Oleg Krupnov
2008

I'd like to validate the following sentiment that dawned at me.

Wireframes and prototypes suggest primarily that the design solutions are
presented visually, annotated with callouts or footnotes at the sidebar.

However, the same thing can be also presented in form of documentation (text
or spreadsheet). Moreover, during certain phases of
wireframing/prototyping, it is often more desirable to abstract from the
visual layouts and rather to work with the documentation.

My idea is that the wireframing/prototyping tool should allow the designer
to work with the both views (visual and documental) simultaneously or
interchangeably, when either is more appropriate. While the both views share
the same data source, i.e. the changes made to the wireframe are reflected
in the documentation, and vice versa.

The existing tools used for wireframing and prototyping seem to
underestimate the frequent need for annotating and documenting design
elements. If you need to annotate something, you a) draw your footnote or
callout as a yet another graphic object, and maintain its connection to the
annotated object manually, because the tool does not "understand" it is an
annotation or b) select the element to be annotated and enter plain text
somewhere far in the sidebar "Properties" panel, and then lose it out of
sight when you select something else. Both approaches become clunky when you
need to create different layers of annotations for different audiences,
which is a common task.

Afterwards, the existing tools can usually spit out a functional spec in
Word or PDF that is rather a formal red-tape "deliverable". Or if you are
not satisfied, you can go to a word processor or a spreadsheet and write the
documentation manually (and I often do), but then it will not be connected
to the wireframe/prototype anyhow but in your mind, so you have to maintain
them in sync manually as well. Besides, you find yourself dealing with many
documents and tools instead of one.

Am I on the right track? What are your hardest challenges of documenting
design? Have I overlooked something?

Thanks,

Oleg.

--
View this message in context: http://www.nabble.com/The-Documentation-View-of-Design-tp16967831p16967831.html
Sent from the ixda.org - discussion list mailing list archive at Nabble.com.

Comments

29 Apr 2008 - 2:29pm
pyces
2007

Hi Oleg,
iRise enables you to do this in their Document tab. It's a clunky tool,
but you can easily tie requirements and your own or reviewers' comments
to widgets in the Document tab. Unfortunately, the tool itself is
difficult for non-programmers to use, and what you see (in the design
state) is very often not what you get (in the simulation state)
especially without irise training courses, so a more usable tool would
be well received!
Unfortunately, I can't check out your app due to the NET version
restrictions.

Thanks,

Courtney

-----Original Message-----
From: discuss-bounces at lists.interactiondesigners.com
[mailto:discuss-bounces at lists.interactiondesigners.com] On Behalf Of
Oleg Krupnov
Sent: Tuesday, April 29, 2008 3:02 PM
To: discuss at lists.interactiondesigners.com
Subject: [IxDA Discuss] The Documentation View of Design

The existing tools used for wireframing and prototyping seem to
underestimate the frequent need for annotating and documenting design
elements. If you need to annotate something, you a) draw your footnote
or
callout as a yet another graphic object, and maintain its connection to
the
annotated object manually, because the tool does not "understand" it is
an
annotation or b) select the element to be annotated and enter plain text
somewhere far in the sidebar "Properties" panel, and then lose it out of
sight when you select something else. Both approaches become clunky when
you
need to create different layers of annotations for different audiences,
which is a common task.

Afterwards, the existing tools can usually spit out a functional spec in
Word or PDF that is rather a formal red-tape "deliverable". Or if you
are
not satisfied, you can go to a word processor or a spreadsheet and write
the
documentation manually (and I often do), but then it will not be
connected
to the wireframe/prototype anyhow but in your mind, so you have to
maintain
them in sync manually as well. Besides, you find yourself dealing with
many
documents and tools instead of one.

Syndicate content Get the feed