Pondicherry Escorts Service Girl ^ 9332606886, WhatsApp Anytime Pondicherry
Journey over Destination: creating an effective framework with UX tools
1. Journey over Destination
creating an effective
framework with UX tools
Stephanie Troeth
ParisWeb 2010
Friday, October 15, 2010
2. Who?
User eXperience Strategist/Designer
Previous hats:
* Co-founder of an innovative publishing startup
* Director of Interactive Technology & Solutions
@ a Montreal web agency
Played active part(s) within the Web Standards Project
since 2002 until 2 months ago.
Friday, October 15, 2010
3. This is a
conversation
about “how”...
Friday, October 15, 2010
4. which depends on “what”...
d eliverables
tools
and “when we do what”.
process
Friday, October 15, 2010
5. Classic Waterfall
a plan!
plan
reports
requirements
define
research Specs / briefs
design
concept code
develop
build
deploy
launch
key performance indicators
extend
measure
Adapted from Chapter 4: Project Objectives & Approach, A Project Guide to UX Design, Russ Unger & Carolyn Chandler.
Friday, October 15, 2010
6. Agile approach
user stories
define design
roadmap sketches/wireframes
plan mockups
adapt
code
deploy
measure
Friday, October 15, 2010
7. “It's really the act of designing that
matters, so we should focus on
designing rather than design.”
Mark Baskinger
“From Industrial Design to User Experience: The Heritage and Evolving Role of
Experience-Driven Design”, UX Magazine, June 2010
http://uxmag.com/design/from-industrial-design-to-user-experience
Friday, October 15, 2010
9. Process = act of designing?
Deliverables = design?
Friday, October 15, 2010
10. It’s easy to see design
represented as deliverables of
a design process.
you get
st uff at the end
of e ach design activity
Friday, October 15, 2010
11. Todd Warfel’s
Design Process Diagram
plan define design develop deploy
http://www.boxesandarrows.com/files/banda/card_sorting_a_definitive_guide/designProcessDiagram.jpg
Friday, October 15, 2010
15. “Wireframes are representations of a design made before final specifications exist,
which is problematic because in comparison to sketches they are higher fidelity
wireframes are
representations of design. Unfortunately, although
meant to inform design processes and design
decisions, they often can be viewed as more concrete than sketches, and
therefore considered more final.”
Will Evans, “Shades of Grey: Thoughts on Sketching”, UX Magazine.
http://www.uxmag.com/design/shades-of-grey-thoughts-on-sketching
Friday, October 15, 2010
16. “Wireframes, flow diagrams, personas, card sorts, content strategy documents, etc. All of
these things are important to design, and designers need some combination of them to
synthesize their user research and communicate what they’re doing with the other members
of the team.
But too often these deliverables are the last line of contact for designers. Too often these
deliverables are what designers prepare and then hand off to implementors. Then they
shuffle off to create more deliverables and the cycle is repeated.
In the end deliverables are merely artifacts of the
design process. They are not the final design, they are not the artifact of
experience. The end user never interacts with them…they interact with the product or
service that is actually delivered.”
Joshua Porter, “Deliverables vs Delivery”, 52 Weeks of UX
http://52weeksofux.com/post/346650807/deliverables-vs-delivery
Friday, October 15, 2010
17. “We get so lost in our deliverables and sharing
information that we forget that we’re really trying
to collect and share knowledge. Just like the software we build, the
persona document is hopefully an interface to a much deeper connection and store of insight
or ‘institutional memory.’ In most cases, I fear that we’re just leaving the document, not the
knowledge.”
Chris Baum in response to Jared Spool’s post, “Personas are NOT a Document”, UIE.com
http://www.uie.com/brainsparks/2008/01/24/personas-are-not-a-document/#comment-104179
Friday, October 15, 2010
18. Mini-survey/interview:
“Do people you work with expect detailed
wireframes and functional specifications
even if they may or may not be necessary,
or the best tool?”
Friday, October 15, 2010
19. Response #1
“They do expect [it], unfortunately.”
Friday, October 15, 2010
20. Response #2
“For the most part, yes, that has been my
experience, when it hasn’t been just Photoshop
mockups.”
Friday, October 15, 2010
21. Response #3
“They do. Totally. And it's freaking moronic. Clients tend
to get all focused on the list of deliverables they'll get
for their money. The thinking, of course, is what they're
paying for—the deliverables are just for communication
purposes.”
Friday, October 15, 2010
22. Response #4
“In my experience freelancing, small clients don't
expect any UX deliverables, they just wait for the
designs. At larger companies, they seem to fixate on
process and lose sight of outcome. Agencies get
fixated on deliverables. Seems like a lot of ‘thought
leaders’ in the UX space fall prey to that too. Seems
like so often people obsess over the terms we use,
the steps we follow, etc. thinking of problem solving
as a one size fits all type of thing.”
Friday, October 15, 2010
26. Cook up the procedure
based on the
ingredients we have.
Friday, October 15, 2010
27. 1
Establish context:
Frame the problem
Friday, October 15, 2010
28. Classic Agile
waterfall approach
plan define design
define
plan
research
design
adapt
concept
develop
build
deploy deploy
measure
launch
extend
measure
Friday, October 15, 2010
29. What’s the goal/objective?
What’s the actual problem
we are solving?
Who are we solving it for?
What impact do we want
to have?
Friday, October 15, 2010
30. What’s the goal/objective?
What’s the actual problem
we are solving?
Who are we solving it for?
What impact do we want
to have?
Friday, October 15, 2010
31. What’s the goal/objective?
What’s the actual problem
we are solving?
Who are we solving it for?
What impact do we want
to have?
Friday, October 15, 2010
32. What’s the goal/objective?
What’s the actual problem
we are solving?
Who are we solving it for?
What impact do we want
to have?
Friday, October 15, 2010
33. How “out there” is it?
evolutionary revolutionary
analytics
prototyping
SWOT analysis
competitive analysis
user research
Friday, October 15, 2010
34. Longevity?
ephemeral permanent
set process
more iterative process
market research
user research
Friday, October 15, 2010
35. What type of solution?
content interactive
-focused application
information architecture interaction design
content strategy
visual design
copywriting
user research
Friday, October 15, 2010
36. Social context?
individual social/community
support
community management
social design
mental models
Friday, October 15, 2010
37. Common user research methods
surveys
card sorting
“feedback army”
focus groups
“five-second test” interviews
usability testing
“listening labs”
heuristic evaluation “contextual enquiry”
personas
close-ended open-ended
refi nement
discovery
Friday, October 15, 2010
39. Example: user modelling (motivations)
Making sense of
research,
extrapolating
user models.
Friday, October 15, 2010
40. 2
Set the stage:
Design together
Friday, October 15, 2010
41. Classic Agile
waterfall approach
plan define design
define
plan
research
design
adapt
concept
develop
build
deploy deploy
measure
launch
extend
measure
Friday, October 15, 2010
42. Creating
sketches help
you think.
Sketching together helps you
think together.
Friday, October 15, 2010
43. Example technique: Leah Buley’s six-up.
Sketch six different
versions of
interface within a
limited time.
Friday, October 15, 2010
44. Sketchboarding example
James Downes, “Using Sketchboards to Design Great User Interfaces”
http://www.boxuk.com/blog/using-sketchboards-to-design-great-user-interfaces
Friday, October 15, 2010
45. Engage everyone in the process, so
that everyone’s in on the journey.
Friday, October 15, 2010
46. “Sketching is hardly a new technique in UX design. I would imagine
that the vast majority of UX / UI designers start by putting their
thoughts on paper, but how often do clients get to see these
We firmly believe that this collaborative
sketches?
technique can communicate the ideation
process much better than wireframes, can
save you time and make your clients happier.
What’s not to like?”
James Downes, “Using Sketchboards to Design Great User Interfaces”
http://www.boxuk.com/blog/using-sketchboards-to-design-great-user-interfaces
Friday, October 15, 2010
48. Classic Agile
waterfall approach
plan define design
define
plan
research
design
adapt
concept
develop
build
deploy deploy
measure
launch
extend
measure
Friday, October 15, 2010
49. Document all the time,
but not everything!
Friday, October 15, 2010
50. Keep trace of changes
and decisions made.
Friday, October 15, 2010
51. Think of it as leaving
pebbles to remember
whence you have come.
Friday, October 15, 2010
52. 4. Hang in there...
lo y!
ep
...till the end
d
y to
re ad
and beyond.
Friday, October 15, 2010
53. Classic Agile
waterfall approach
plan define design
define
plan
research
design
adapt
concept
develop
build
deploy deploy
measure
launch
extend
measure
Friday, October 15, 2010
54. Ensure vision is
carried all the way
through.
Friday, October 15, 2010
55. Time is saved in maximising
communication and not
generating artifacts.
Friday, October 15, 2010
56. Act of designing is
the act of
crystalising ideas.
Friday, October 15, 2010
57. Choose your
weapons tools
wisely.
Friday, October 15, 2010
58. “We tend to try and automate everything in our lives so that we can achieve
the power of design is its ability to
more, faster. However,
make the inanimate more human. This is not
something that happens when design becomes a
checklist, a process or a formula. Inevitably, as the designer
yields to the design system, we find ourselves faced with products that don’t
emotionally resonate with us as human beings.”
Joshua Brewer, “Design Systems Need to be Challenged”, 52 Weeks of UX
http://52weeksofux.com/post/1215278826/design-systems-need-to-be-challenged
Friday, October 15, 2010
59. Embrace the
design journey.
Friday, October 15, 2010