This talk was designed and aimed at summer of code students - computer science interns for summer. But would still love to hear your thoughts in communicating designs to developers and businesses.
3. problem solver
ent
r
f fe &
information architect
di s
hat s
e
rol strategist
evaluator
facilitator
communicator
critic
sales person
teacher
mentor
implementer
interaction designer
business person
3
4. ple d
peo rke
wo
i’ve with
Logos I could find...
4
11. er
sw is
n
A th
in
es
li
ANSWER:
When do you design?
11
12. s
ces
pro
ent
m
p
velo
e
ed
war Analysis Build & deliver
t
sof
Technical
Requirement “Gathering” Build Test
Design
Who will use it?
What’s the
GAP
What should it DB code
do? and structure
tive s
fec ent
f
ine rem
ui tion
req fini Gap
in Delivery
de the
proc
ess
Adapted from Cooper, Interaction Design Practicum course material.
12
13. ess
c
pro
ent
m
lop
e
dev
are Analysis Design Build & deliver
tw
sof
Technical
Requirements
Design Build Test
Design
Definition
What
Who will interaction
use it? meets
requirements? What’s the
What DB code
Common practise
should it What does it and structure
do? look like?
How does it
r
tte nd
Be n a behave?
o ser
niti
efi r to u
d e Gap
los eeds Delivery
c filled
n
by
Des
ign
Adapted from Cooper, Interaction Design Practicum course material.
13
19. Documents that communicate...
• What the THING is pictures
conversation
• What the THING Looks like
see what
• How the THING works you’re
discussions
getting
• Why the THING is needed
• Who will use the THING
see what you
• How the THING will behave will be building
19
21. Design specifications...
• Communicate:
• Front end - user interface elements
• User experience of your web site or application
• Technical implications on the end-user’s experience
21
22. Different types
• Site maps
• Navigation pathways
• Activities overview
• Task flows
• Page layouts - structural
• Interactions specifications for tasks within an Activity
22
23. f
so n Concrete Completion
ent at
s software interface io Web as hypertext system
pon plic
m
Co ite/ap Visual Design: visual treatment of text,
Visual Design
ebs in quot;look-and-feelquot;)
esign: graphic treatment of interface
graphic page elements and navigational
ts (thew
quot;lookquot;
components
e Design: as in traditional HCI: Navigation Design: design of interface
of interface elements to facilitate elements to facilitate the user's movement
Interface Design Navigation Design
eraction with functionality through the information architecture
Information Design
tion Design: in the Tuftean sense: Information Design: in the Tuftean sense:
ng the presentation of information designing the presentation of information
tate understanding to facilitate understanding
Interaction Information
ion Design: development of
Information Architecture: structural design
time
Design Architecture
tion flows to facilitate user tasks,
Typ
of the information space to facilitate
how the user interacts with
ical
intuitive access to content
com
ctionality
ly
mun
for
Functional Content content elements required inica
nal Specifications: quot;feature setquot;: Content Requirements: definition of
elem the site te
descriptions of functionality the site
Specifications Requirements
ents
clude in order to meet user needs in order to meet user needs
o
UX
User Needs: externally derived goalsf
eds: externally derived goals
User Needs
site; identified through user research, for the site; identified through user research,
chno/psychographics, etc. ethno/techno/psychographics, etc.
Site Objectives
jectives: business, creative, or other Site Objectives: business, creative, or other
ly derived goals for the site internally derived goals for the site
riented information-oriented
Abstract Conception
This picture is incomplete: The model outlined here does not account for secondary considerations (such as those arising during technical or content development)
that may influence decisions during user experience development.of User experience - Jesse describe a development process, nor does it define roles within a
Elements Also, this model does not James Garret
user experience development team. Rather, it seeks to define the key considerations that go into the development of user experience on the Web today. 23
24. Site Maps
• AKA Site overviews - BIG PICTURE view of the site or application
• Main areas of the website/application
• Information hierarchy
• Identify where people will potentially start from or end up at
• Identify types of pages or templates
• Identify main navigation pathways
24
26. Navigational Pathways
• Aka navigational patterns
• Main ways to navigate around the site or application
• Identify where to strategically place information
• How pages link to each other
• Validates templates and scalability of these pages
• Clearly shows which template to use when
26
28. Task flows
• User’s experience – Flow
• Objective look at “Flow”
(as opposed to Form)
• Identifies gaps
• Scenario based
28
29. yes
selects Name
1 2 no
yes My Sci
Page sign up/ Email MySci
register/ Password
no (try again)
Any Page Logout
Some content my kete
Tools
Some content
Any Page Any Page
Register
Name
Email
Some content Register
S
YE
Password
2
Tools
Some content Some content
NO
Tools
My Sci Logout
Some content
Some content
Some content
Alternate path
Detailed
functionality
Page content
to be further
analysed
1 is email address correct format? is it unique? (i.e. not in database)
Page Function
2 is user in the middle of adding an item to kete?
DISCLAIMER: The layouts displayed in this diagram represent information structure only and should not be construed as final screen designs
MORST & UoW / ScienceLearn Hub Information Architecture Framework 29 March 2007
CLIENT / PROJECT DATE
29
F5 / Registration 1.1 Page 6 of 28
ID / PROCESS TITLE VERSION
34. Annotations - overview
• General description of the screen/
wireframe
• What users can do from this screen
• Default display
34
35. +$,(-quot;*=>$'(:('&#()quot; 7&-$*9*):*;<
!quot;#$%&'%()*quot;+,-%.#/0,quot;1%&*%-2)%3&+'$)1%4,quot;$$)'5
Name of the screen/activity
$%H, .*K$8> .*2)quot;#&'#*)%*-(L$*:$$CG&'D* % !quot;#&$(quot;$%&#quot;#2*#'$=(*-$,$7(quot;*$/.$,77$'#quot;(32,*#'$=,7>(23$,2'$):)7(23$%,*-quot;$=(*-(2$*-#$
M)-)5# N ,&#,$*-,*$*-(quot;$?#3(/2,7$@/02)(7$)/+#"4$A*$(quot;$B//C#'$(2$,*$*-#$-(3-#quot;*$7#+#7$/.$*-(quot;$
Description & intention )/02)(7$)/+#&,3#4$D77$%,*-quot;$,*$*-(quot;$7#+#7$7//>$*-#$quot;,C#4
8$'#()quot;*):*%$-()quot;F
!quot;#"$),2E
What users can do F4$@-,23#$*-#$C,(2$7#+#7$/.$./)0quot;$1#*=##2$*-#$8$)/02)(7quot;$/.$5G?@H
I4$J#7#)*$*/$+(#=$*-#$'#*,(7$/.$,$%,*-=,:H
K4$L//C$(2$*/$quot;##$*-#$'(..#)#$1#*=##2$G,7>(23$,2'$@:)7(23$%,*-quot;H
7%(quot;#*O&> .*BH&(8*O&> M4$?#.(2#$*-#$7(quot;*$1:$(/2$/&$quot;010&1H
N4$5#*$'(&#)*(/2quot;$.&/C$,2'$*/$)#&*,(2$%/(2*quot;H
O4$P(#=$1/*-$G,7>(23$,2'$@:)7(23$%,*-quot;$/&$.(7*#&$*-#$7(quot;*$1:$#(*-#&$C/'#H
O&>
,X 84$P(#=$,77$'(quot;*,2)#quot;$/&$#2*#&$*-#$'(quot;*,2)#$,2'$.(7*#&$*-#$7(quot;*$1:$*-,*$'(quot;*,2)#4
Q4$R*-#&$<,%$.02)*(/2quot;$&#C,(2$*-#$quot;,C#$,quot;$/2$L//C(2$/&$5//37#$C,%quot;4
S(quot;%7,:E
F4$A2quot;*&0)*(/2quot;$,2'$7,1#7quot;$,quot;$quot;-/=2H
Default elements on the page
I4$;##'1,)>$/2$-/=$C,2:$(*#Cquot;$0quot;#&$(quot;$+(#=(234
! !quot;#$%&#'()*(+#$quot;#,&)-$./&$quot;010&1quot;$,2'$(/2quot;4
quot; 5#*$'(&#)*(/2quot;$6$quot;##$'#*,(7$/2$%,3#$84$9&/+('#quot;$,1(7(*:$*/$#2*#&$quot;*,&*$,2'$'#quot;*(2,*(/2$
%/(2*quot;4
# 35
36. Annotations - Detail
• •
Detailed descriptions of elements and Reference to other technical document
behaviours (e.g. Business rules or SOW or
Requirements) if relevant.
• For each annotation provide:
• UI Rules: Element > Action > Result
• Default display
• Any notes
36
37. +$,(-quot;*=>$'(:('&#()quot; 7&-$*9*):*;<
!quot;#$%&'%()*quot;+,-%.#/0,quot;1%&*%-2)%3&+'$)1%4,quot;$$)'5
=&$11quot;6 .*J$%H, .*K$8> .*2)quot;#&'#*)%*-(L$*:$$CG&'D* % !quot;#&$(quot;$%&#quot;#2*#'$=(*-$,$7(quot;*$/.$,77$'#quot;(32,*#'$=,7>(23$,2'$):)7(23$%,*-quot;$=(*-(2$*-#$
M)-)5# N ,&#,$*-,*$*-(quot;$?#3(/2,7$@/02)(7$)/+#"4$A*$(quot;$B//C#'$(2$,*$*-#$-(3-#quot;*$7#+#7$/.$*-(quot;$
)/02)(7$)/+#&,3#4$D77$%,*-quot;$,*$*-(quot;$7#+#7$7//>$*-#$quot;,C#4
$%*3*H&6*G$*C(::$%$quot;#*:)%*C(::$%$quot;#*')5quot;'(8,*G&,$C*)quot;*5,$%I,*,$8$'#()quot;*):*%$-()quot;F
Name of the panel or block on the screen !quot;#"$),2E
F4$@-,23#$*-#$C,(2$7#+#7$/.$./)0quot;$1#*=##2$*-#$8$)/02)(7quot;$/.$5G?@H
I4$J#7#)*$*/$+(#=$*-#$'#*,(7$/.$,$%,*-=,:H
K4$L//C$(2$*/$quot;##$*-#$'(..#)#$1#*=##2$G,7>(23$,2'$@:)7(23$%,*-quot;H
7%(quot;#*O&> .*BH&(8*O&> M4$?#.(2#$*-#$7(quot;*$1:$(/2$/&$quot;010&1H
UI Rules: Element > Action > Result N4$5#*$'(&#)*(/2quot;$.&/C$,2'$*/$)#&*,(2$%/(2*quot;H
O4$P(#=$1/*-$G,7>(23$,2'$@:)7(23$%,*-quot;$/&$.(7*#&$*-#$7(quot;*$1:$#(*-#&$C/'#H
O&>
Y&C$*O&> S$6,X 84$P(#=$,77$'(quot;*,2)#quot;$/&$#2*#&$*-#$'(quot;*,2)#$,2'$.(7*#&$*-#$7(quot;*$1:$*-,*$'(quot;*,2)#4
Q4$R*-#&$<,%$.02)*(/2quot;$&#C,(2$*-#$quot;,C#$,quot;$/2$L//C(2$/&$5//37#$C,%quot;4
S(quot;%7,:E
F4$A2quot;*&0)*(/2quot;$,2'$7,1#7quot;$,quot;$quot;-/=2H
I4$;##'1,)>$/2$-/=$C,2:$(*#Cquot;$0quot;#&$(quot;$+(#=(234
>
?
! !quot;#$%&#'()*(+#$quot;#,&)-$./&$quot;010&1quot;$,2'$(/2quot;4
9 E%)5#$*quot;&H$F*ESH,F*E?%,F
E&L-*$8$L&#()quot;F
EH)C$F
quot; 5#*$'(&#)*(/2quot;$6$quot;##$'#*,(7$/2$%,3#$84$9&/+('#quot;$,1(7(*:$*/$#2*#&$quot;*,&*$,2'$'#quot;*(2,*(/2$
E&##%(G5#$,F
%/(2*quot;4
E%&#(quot;-F*E>?)#),F*E')HH$quot;#,F
T*UCC*#)*O6*4)5%quot;$6
; # ;(7*#&$1:$</'#quot;
C
T*78"*&*V)5%quot;$6*)quot;*#?(,*%)5#$
/$#*C(%$'#()quot;,*#)*#?(,*1)5#$ N
;*'<).*0&8D(quot;- .*26'8(quot;-*%)5#$,
UI Rules: Element > Action > Result
D
W)#? .*8$&/012 .*26'8(quot;-*%)5#$,
! $ ;(7*#&$1:$S(quot;*,2)#
!quot;#$%&%'((quot;)*%+,%-(%
9&&):07'$14quot;7).*Bquot;#$%*C(,#"'$
.)//+,0-(,%1)0+(,%#2)#3
+(,#"'$*(quot;* ,- EF7).*K%,
A
+(,#"'$*(quot;*SH, .* = ?67
@
& ;##'1,)>$/2$*-#$7(quot;*$/.$(*#Cquot;4$
B
' T(quot;*$&/0*#quot;$U(*#Cquot;V$6$quot;-/=$0%$*/$FW$,*$,$*(C#4
37
38. Components
Task flow or context
About the doc scenario
Cover
Flow of interactions – step by step
interaction and experience
38
39. Design specs are used by...
eve
r yo
ne
invo
lved
• !!
Visual designers
• Integrators or user interface developers (HTML/CSS people)
• Developers or programmers
• Testers to know what to test for
• Business people to understand the evolution of the software and plan
future enhancements
39
40. “
You’ll know what to build
when you know what the
Design looks like...
40
41. Thanks!!
lulu@lushai.com
More about Summer of Code
http://www.summerofcode.co.nz
Photos found on Flickr and Google images
41