Speaker: Colleen Roller
"Decision Architecture" - how do we architect to make better decisions.Why is financial decision making so difficult?
- Ambiguity; the future is unknown. There's no guarantee that what we save will ever come back to us.
- Temporal Distance; distant future is abstract, and hard to plan for. We don't necessarily have the ability to envision it.
- Inertia; hard to get started, aversion to "work" or extensive effort.
- Reward system; there are consequences to our actions. When we save, we lose out today—while if we don't, we get rewarded!
- Too many choices. Consumers have fear of making the wrong choice, and believe that their choices are unique. Leads to paralysis.
- Overconfidence. People believe that everything will work out, sometimes despite evidence to the contrary.
How people assess value
- Comparison. People constantly compare just about everything. How do you build comparison opportunities into your design?
- Gain vs. Loss. People have more pain with a loss than they do happiness with a gain. How do you minimize the pain that goes with a "loss?"
- Framing. How a question is asked, or how a sentence is stated, impacts the emotional response. People don't reframe things. They will take the information you present as you present it.
- Salience. What is distinctive, prominent or obvious? What's relevant to you right now?
They are interaction designers, apply visualization to research findings.
Bring back frameworks, and methodologies
Shedding light on research
What is the diff between
Visual communication: transfer of information from one person to another using visuals
Visualization: the process of transforming the message into visuals.
Key word: message.
- Target the visuals towards a specific audience. Know who you are targeting
- Visuals stay persistent. They last much longer than you do.
- Helps make sense of "big data". Reveals info about what patterns underly the numbers.
- Helps justify and explain the data or reasoning behind a decision
Visual communication/storytelling framework
- What information are you trying to communicate?
- Not sure? Go find it.
- The tool is not the outcome; it's what you are going to use to get the outcome
- What is the context of this message?
- Where and when is this information taking place?
- Why are you communicating?
- Need to request an action
- Who is the audience you are communicating to?
- Hint: it is NEVER "everyone"
- Who is the message about?
- Characteristics, attitudes, etc.
- Use "comm to" to tailor the message; use "who about" to build a visual language
- Get the visual language right, then get creative
- It's not just pie charts.
- Know your design principles
- Use your tool of choice and bend it to the task.
Make them more interesting.
- Search for inspiration.
- What are other visual designers doing?
- Log them
- Use the 5 w's to select the right metaphor for visual design
- Use design tools (illustrator, etc)
- There's no particular order to it, but: Remember the what and Remember the how
Chart suggestions: a thought starter (chart)
Qualitative vs. qualitative deliverables/communication
Examples: discover persona families; find ways to present infographics instead of paragraphs in personas.
- Who they report to
- What they are doing
- Text clouds
- Geographic location
- Put five w's at bottom
Experience map: borrowed from adaptive path (anatomy of article online)
- Everything is in one condensed format
- Record experience in different dimensions
- Incorporate usability findings:
- What are blockers, what are good, what is just okay
- Define focus
- Add emotions in addition to task
- Platform selection: zone maps
- Define where priorities lie
- (Think: start with landscape tablet, then move to portrait)
- Note where adaptation is required.
- Ux concept map
- Focus on user intentions
- What are the major intentions we want to focus on?
- Think of it as a unit or a module.
- Look at different dimensions
- User journey: more detailed workflow of a specific dimension
- Comics: solution definition messaging and tell the story
- Design problem statement
- Use to validate concept with customers; use as opening statements.
- Use different methods to show results of research data.
- Design the visualization as you would any project
- Test and iterate
- Know the message
- Kow the audience target
- Keep it simple
- Know who and what your message is about
- Follow the visualization guidelines
- Creativity can be learned
- Use templates as often as possible: find keynote or illustrator templates
- Show me the numbers
- One morning a sprint
- Test 3 users a morning
- Invite everyone to attend
- Debrief over lunch: 1 hour
- Focus on most serious problems
- Only people who attended tests can attend
- Report takes half hour to write
- Devote one day to fix most serious issue
RITE plus Krug:
- Require that a stakeholder from dev, pm and design to attend
- Can change prototype between participants
- Run 3-4 participants over a few days
- Findings discussed in 1 hour debrief
- Minimal report (bullets on wiki page)
- Add test plan
- Add results
- Add findings
- Add next steps
- Sessions went viral: 12+ observers remote and in person
- Before: hold kickoff meeting with stakeholders to get buyin into process/time required
- During: keep running notes and send to stakeholders 30 minutes after last participant
- Convo has changed from "what is Agile?" To "how can we adapt it and make it our own?"
Recommendations re: research:
- Conduct research before dev cycle if possible
- If you can't, fit it in anyway
- Predictable and repeatable user feedback sessions during the cycle
- Create good hygiene for user testing and iteration.
- Complement user feedback sessions with fast, low-cost data collection methods:
- Customer phone calls
- Web analytics
- Card sorts
- Unmoderated usability tests
- Agile UX Design
- The RITE way to prototype (uxmag,com)
- Informal cognitive walkthroughs (grigoreanu)
- Successful user experience in an agile enterprise environment
Jason Stehle: @jasonstehle
The 8 wastes in prototyping
- MUda (waste): wasted time, materials, energy
- Don't try this at home:
- Assume that your team can do something that Huge company did with time and budget crunch
- Developer disconnect
- Premature development
- Debs start building system before design is done
- Won't change things to suit design
- Developer redesign
- Change design without consulting designers
- Overwhelmed by constraints or
- Making edits to multiple deliverables in order to make a single change.
- Edge case surprise
- Find out design is broken when real time data is loaded
- A design that can't be built
- Just impossible or
- Can't be done within project constraints
- Solving a problem that only exists in your imagination
- You're off I the sky, but have no data to back it up
- Channeling the devs energy in the right direction
- Find out quickly if things can't be built
- Invest stakeholders in the process
- Avoid surprises in design, grow fidelity over time.
- Avoid edge case surprise; create lightweight models and build them into a prototype
- Make sure designs can be built
- Show interactions before they are built
Imagineering: need a combo of customer development and prototype/simulation
Prototype vs. simulation:
- Simulation simulates software
- Prototype IS software
Building in the medium helps explore how the real data works.
Thought: prototyping mediums that work with Drupal (not Axure)?
Get the server out of the way
- Focus on front end
- Presentation logic
- Fake interactions
- Shallow logic to avoid bottlenecks
Trying to design along with development makes you not as strategic as you need to be
- Content in markdown
- Layout in HTML and CSS
- Annotations inline or JSON
- Interactive refinement in Js
- Visual refinements with visual refinements and CSS
Goal: everything is clickable and refined
Goal: find the show stoppers early when team is most energizes and nothing is locked in
Show stoppers found during the slog of development don't get the attention they deserve.
How do you know what to build?
- Everyone has their own opinions
- Have to find some common ground
- The right thing: An implementable solution to a real problem that we can deliver for a profit.
- Source: customer validated prototypes.
12 lean practices
- Imaginations fail.
- Don't ask customers to use their imagination
- Benevolent dictatorships:
- Don't work for a committee if you can avoid it
- Have someone who can answer "what should we do" and "what can we do"
- Laziness is a virtue:
- Leave the prototype rough
- Don't waste time developing stuff nobody wants
- You get better feedback when it's rough
- Nobody wants to critique a "finished" project
- Learn hard:
- The real work is in understanding the problem domain and the platform.
- Learn the mechanics of your platform and its limitations
- Everybody has an attention deficit, and it's only a matter of time before you trigger it
- Avoid long design review meetings
- Avoid huge deliverables
- Send features one at a time for user testing or stakeholder reviews
- Look stupid
- Deliver flawed designs early and often
- Many ideas are better when transplanted into another person's mind than when they are in your own.
- No geniuses here
- Don't innovate for innovations sake
- Challenge assumptions
- Apply good design
- Strategic embarrassment
- Put your effort where your users live
- Everything else can suck
- Exceptions: initial user experience (payment, user login, landing, etc.)
- Code before comps:
- Don't optimize prematurely
- Understand component libraries before applying visual treatment
- Get visual designers in early, but know that everything is done first
- Prevent devs from doing too much work.
- I want to believe:
- Take the prototype and carry it forward within a released application
- Leave slots open in your software to present in process code
- Progressive ux enhancement
- Create good, better and best level design for difficult to implement features.
- Give options
- Give devs something they *want* to work on and they'll go forth!
On Tuesday, December 18, 2012, I lost my father, Eric John Nordin, to a two-year-long battle with lung cancer. Dad spent his life trying to turn his passion into a career. Sometimes, he was successful (for example, turning a passion for motorcycles into a 15-year career as a bike mechanic); other times, not so much (like his side business selling public domain software at the local flea market). I became interested in computers from an early age by watching him muck around in the dining room, building his own PC systems and playing text-based games like Zork—games which I soon fell in love with. He was responsible for my own passion for technology, and my interest in being an entrepreneur. In his later life, we were able to bond over our mutual love of karaoke, and his newfound love of fine cooking.
The Saturday before he passed, I took my daughter Charlotte down to Kent County Hospital to spend some quality time with her Pop-Pop before he was gone. The tumor that took him was taking up a third of his lung. By the next morning, it had doubled. By Tuesday, he was gone.
I try to keep things professional on this site, but sometimes "professional" language isn't enough. Cancer is a fucking bitch. It took him too soon, and put him in too much pain for too many years. Watching my dad's mother pass away—also at 63 years old, also of lung cancer—was the reason I never became a smoker. I will miss him always, but I'm grateful that he's finally at peace.