The document provides an overview of the user experience design process, beginning with gathering observational data through site visits and analyzing it to create experience maps and personas. It then discusses techniques for idea generation like scenarios and storyboarding, as well as paper prototyping and testing. The whole team should be involved from the beginning in order to truly incorporate user needs. Observational research is emphasized as the foundation for an empathy-driven and user-centered approach.

1. User Experience
by Chris Nodder
!
!
User Centered Design - UCD
1. Gather observational data
2. Analyze: Experience Map
3. Create personas
4. Ideation techniques
5. Scenarios, storyboarding
6. Paper prototype design and testing
7. Plan dev cycle
The key principle of user centered design,
is that if you gather data from users and then
incorporate your findings into your product
design, you'll be more likely to meet their true needs. Which means they'll probably like your
product more, and be more efficient using it.
It's often hard to turn empathy based concepts like users thoughts, feelings, frustrations
and desires into something systematic, that team members can use to build products.
Add emotional impact to products. Team
members are often experts in their domain,
with a great understanding of technology,
with a systematic approach to thinking about
the world. Users in contrast, are often not so
expert at working with software and apps.
And don't have such a focus on
understanding how technology works. They
just want to their tech stuff to help them in
their lives
Follow the data trail. Identify PAIN POINTS. Create personas. Ideation. Multiple solutions.
Scenarios, storyboards, working set, Lo-Fi paper prototypes.
Although you might have one user experienced specialist on the team, the real benefits of user
centered design only happen when the whole team buys into the concept. Doing design
work in isolation and then throwing it over the wall to a developer, is never a good solution.

2. Unless everyone from development, to test, to marketing,
to content creation to product management is involved
right from the beginning.
!
Quantitative (stats) data - What
Qualitative (observation) - WHY
!
YOU are not your users! Take a field trip A SITE VISIT to users work and home, better than
bringing them in. Making use of SITE VISIT DATA: Users quotes. Turning observations into
actionable data. Extracting PAIN POINTS
!
OBSERVATIONAL DATA - Morning field visit
- well defined target user
- visit them where they work
- doing their activities
- 3 visits per type
- at least 5 times
- interviewing does not work!
- 2 or 3 people on visit
!
Watch and Listen. Note book and pen, take notes. No recording, thats lazy and a barrier. Duct
tape your mouth. 90% words from them. Active observation. Take notes. Be humble apprentice
Hand written notes. No laptop. Take photos. Engage. Ask open ended questions. No
conversations. “Can you tell me more about what you just did?”
!
When you're done with each visit, it's nice to ask the person you observed whether they have
any questions for you. It's also usual to thank and pay people for their time. Either cash, if it's
a member of the public, or gift cards if it's someone inside your organization.
EXPERIENCE MAP - The whole team that afternoon
• Creating a visual story from observations
• Put all observations on STICKY NOTES
• Overcomes observer bias

3. •Experience Map is like an affinity
diagram but adds the element of time
•Direct quotes - yellow stickies
•user goals
•actions, behavior counting
•pain points
On a large sheet of butcher paper.
associations. Green sticky note label of
group. Activities are blue stickies. Add
orange for design ideas and keep
going. Questions on pink, wished we
asked users, means needs more site
visits.
Site visits in morning, map in same
afternoon. Don’t use computer. Put
user attributes on left side. Put team
members initials in corner of sticky.
!
PAIN POINTS TO GOALS
Dot vote, 5 or 6 dots each, all at the same
time. Then translate on to piece of paper,
most dots on the top, descending. Rewrite
pain points as GOALS. And the benefits.
Reorder user goals considering business
goals.
METRICS
What does success look like for
goals? Make data actionable

4. PERSONAS
Attributes, goals, concerns, quotes. Use data from site
visits to create descrip. imaginary but realistic,
believable. Not “the user”. Must get BUY IN by whole
team. Design for key individuals. Just like songwriting.
Do it right after site visits and analysis. Helps make
personas. Use user attributes.
Common vocabulary for whole team. “Susan”
becomes representative. Using names is a sign of
success, rather than a description. Remove just-in-case options for streamlined ui. Prefer
consistent and focused interface.
Bring it down to a small number of specific. Assumption personas vs data-driven personas
where each characteristic is backed up. More believable. Here’s where you use an online tool
-Field visits
-Market research & segmentation
-Metrics, logs
-Helpdesk calls, listen in, top ten
-Sales team
!
!
!
Third Party Data
- Pew
- International Monetary Fund
- stats.org
- Nielsen Norman Group press releases
Approach with question in mind. Maintaining a persona data file. Do NEW RESEARCH.
Iteratively.
!
IDEATION - avoid local maximum problem,
explore multiple possibilities to resolve pain
points. Again with team. Such as brainstorming
(dominant one forms groupthink). Individuals
work separately at first. Expand. New ideas
contain delight. Less than 2 hours.

5. Design Charrette or “studio”
1. review problem statement as team
2. alone sketch problem solution
3. group critique each design ideas
4. synthesize best in pairs
5. group
!
Site visits, experience map, pain points, personas, scenarios and story boards. Sketch together
10-15 mins big paper big colorful markers, partial or wacky ideas are ok. Narrow down ideas
you want to keep. Then in pairs. Group/pairs/individual… then final critique. Or act out the
system theatrically.
!
SCENARIOS - bring it back to earth. People rush into wire framing. Better to go through a
cohesive iterative process.
1. Site visit observations
2. Experience maps
3. Pain Points
4. Personas
5. Ideation to solve pain points
6. Scenarios and Storyboards - avoid any
description of UI
7. Wireframes, prototypes, proof-of-concept
!

6. Scenarios - should be like comics. Written out. Use index cards or sticky notes. Work in pairs…
STORYBOARDS
Turn scenarios into storyboards. Emotion and
action, drawing attention to specific items.
Visualize each scene. Animation techniques,
camera angles, callouts. Perhaps draw the
elements individually, like draw the persons,
phone, all the visual elements, then
rearrange them. I am
cataloging the important
points. This is still not a
wireframe, it is a comic.
http://designcomics.org/
the BOMB
!
PAPER PROTOTYPES
Fast, easy to change, fun,
also not focused of design or
interface. More about
concepts. Very disarming
because it looks like its
made by kindergardeners. Building it. Work through using all your previous work. Scenarios
almost make it for you. Keep it simple and DO NOT ADD anything extra. This is Lo-Fi.
Use colored paper, index cards, sticky notes,
glue stick, scissors, magic markers and
sharpees. Hand create, draw them. 4x as large.
Don’t use ruler. Hand made look. Use separate
pieces of paper for each element. Really cut
and paste. Sheets of paper represents screens.
Usability testing. Users are more honest in
their comments and responses. Thank them
and pay them. Tell them they are seeing
product development for the first time.
Tests the interaction, not the design.
Rehearse first. 5 participants then move on.

7. IMPLEMENTATION PLAN - the entire UCD
process can take one to two weeks.
Story mapping was first described by Jeff
Patten, one of the biggest proponents of
user centered design in agile environments
Story map - use painters blue tape. Lean
methodology, workable prototype not frills.
Minimum viable, majority requirement, nice
to have. Divide into these three fields.
Get feedback. Keep releasing iterations.
Continue testing and getting feedback.
Quantify and collect metrics.
!
!
TIE IN WITH OOP SOFTWARE DEVELOPMENT
by Simon Allardice
A typical approach using five steps to software dev
1. gather REQUIREMENTS - what need does it meet? Must
not can.
2. DESCRIBE app
3. IDENTIFY main objects
4. Describe INTERACTIONS - sequence diagram
5. CLASS diagram
!
No code yet! Requirements. “must” Functional and non-
functional requirements. TBD is ok in iterative.
FURPS+
• Functional requirements
• Usability
• Reliability
• Performance
• Supportability

8. - Design requirements
- Implementation
- Interface with external mech
- Physical
Write it down.
UML - unified modeling language for object o system. Just a little. don't let the tail wag the
dog
• name
• attributes
• methods
Sketch on paper.
USE CASE SCENARIOS - user focused. non
technical. 1 or 2 days at most. Written text.
1.Use case (not fully dressed - too formal)
2.User Story
Use Case
1.Title - short phrase with active verb
“Register new member, transfer funds,
purchase items,
2.Actor - not user. Customer, member,
administrator, server: external entity
3.Scenario - a paragraph, steps or list. normal
and expected flow. Goal in single encounter. Not “log in to…” Purchase item, balance
account, user goal. Multiple scenarios. Sunny day, typical.
Just like in good writing, use active voice. And keep it simple. Focus on intention. Diagram, like
UML. A supplement to written use case.
!
USER STORY - simpler and shorter, one or two
sentences using INDEX CARDS. Not as details
1. As a … type of user
2. I want … goal
3. So that … reason
“As a bank customer, I want to change my pin,
so I don't have to go into a branch”.

9. WRITING PSEUDOCODE - You CAN make the team understand this!
I'm particularly fond of Jeff Patton's work at agileproductdesign.com, the work of the
balancedteam.org members, and Jeff Gothelf's work on Lean UX. I also host my own site,
questionablemethods.com, and you can search online for terms such as design thinking,
service design, lean user experience or user-centered design.
It's hard to develop a truly user-centered product. Initially, the team might be worried that this
isn't the best use of their time. But investing a bit of time up front, saves a lot of time and
MONEY later on during development.
•Collecting and analyzing user data
•site visits
•personas - fictional person narratives and data
•Everyone can propose new ideas, invested in the
whole process
•Scenarios is a written narrative
•Storyboarding plan out interactions
• Paper prototype is easy and bypasses distraction by computer-human-interface HCI issues
and are often more candid about responses. Helps to create pseudocode.
!
SOFTWARE DEVELOPMENT METHODOLOGIES
Extreme programming - advocates frequent
"releases" in short development cycles, which is
intended to improve productivity and introduce
checkpoints at which new customer requirements
can be adopted
The Agile Manifesto reads, in its entirety,
as follows:
•We are uncovering better ways of
developing software by doing it and
helping others do it. Through this work we
have come to value:
•Individuals and interactions over
Processes and tools

10. • Working software over Comprehensive documentation
• Customer collaboration over Contract negotiation
• Responding to change over Following a plan
• That is, while there is value in the items on the right, we
value the items on the left more.[1]
CHECK OUT: Star UML http://staruml.io/
!
IDENTIFY OBJECTS in the applications. Take use cases
and highlight all the NOUNS.
Primary message, is it getting through? Find out: http://clueapp.com/

11. http://clueapp.com/about CLUE is the BOMB
!
TEST DRIVEN DEVELOPMENT - TDD
Automated testing as a part of dev. OOP. Unit Testing.
Testing our code. Test as we write. Automated unit
testing.
Normally, write logic, then test. That may be unit
testing. But TDD asks us to write the test FIRST. Write
test first, which fails, then the least amount logic to pass the test.
Incremental test, try to pass, test, try to pass… Very common in Java, not so much in Objective-
C. Eclipse has testing. Assert.
This fits very nicely with AngularJS. TDD tools Karma for Unit Testing, Protractor E2E.
COOL SOFTWARE
MVC framework AngularJS sees itself as adding meaning to HTML. I think the implication is in
common use, HTML is too stripped down. Yes, you can see the structure, but you cannot see
the meaning.
Moreover, the role of JavaScript has become more to manipulate the DOM than provide
interactivity. This cannot be a good thing; why build your house on one side of the street and
then move it to the other side?
According to Wikipedia, “AngularJS is built around the belief that declarative programming
should be used for building user interfaces and wiring software components, while imperative
programming is excellent for expressing business logic.[1] “
If you have seen ng-apps, they contain considerably less code. The HTML is more readable and
and the JavaScript is focused on interactivity. Plus, as I mentioned Angular lends itself to TDD
with Karma and Protractor
Ruby on Rails as far as I can tell, as I have only so far been dabbling, exemplifies OOP par
excellance. Dynamic Ruby is interpreted. Clean undertandable code (not bad for a C-based
kind of guy). Rails framework is DRY, emphasizing Convention over Configuration. Perfect.
PHP by contrast is, quite frankly an ubiquitous mess of spaghetti code. Java is a bit verbose
and “run once, compile twice”? Yeesh. Ruby on Rails plays nice with AngularJS and is happy to
accomodate all orders of custom data structures (graphs? document store?) and collections.
RESOURCES
CHECK OUT: Star UML http://staruml.io/
http://designcomics.org/ the BOMB. from Sun Microsystems and Cisco
http://clueapp.com/about CLUE is the BOMB