Big Sky Dev Con 2015 presentation by Jason Moore on Interaction design in enterprise teams.

1. Interaction Design for
Enterprise Teams
Jason Moore, UX Manager
jason.moore@workiva.com

2. Agenda
I’d like to leave you with 3 ideas
1. What is Interaction Design (IxD)?
2. How IxD’s are structured to support Workiva’s
success within our product teams
3. How product discovery plays a key role in our
teams

3. Idea #1
What is Interaction Design?

4. What is Interaction Design?
A design discipline dedicated to defining the
behavior of artifacts, environments, and
systems ...i.e. products
The Interaction Design Group’s (IxDG) definition of IxD can be found at http://define.ixdg.org/

5. If it were only that simple

6. Our challenges continue to grow

7. Idea #2
The day-in-day-out of UX life at Workiva

8. What people think we do
image used from http://jmoo.re/1HMEWj7

9. What we don’t do

10. What we actually do
User Experience deals with:
● The interaction itself
● UI ≠ UX
● It includes UI but, is not bound by it
● Deals with all perceptions the user has while
interacting with it

11. We think of it like this
Content
“What People are looking for”
Images used from: http://jmoo.re/ux-ui-diff
UI
“Tools to use the content”
UX
Consumption

12. Problems we are solving today
How do users
retrieve and trust
the integrity of
financial data?
How do we allow teams
of 3 to 1000 to collaborate
securely and effectively
across desktop and
mobile?
How would our users most
benefit from tracking their
document lifecycle and the
resources involved?

13. Discovery ‘triads’ are at the core
Image From: Jeff Patton. “User Story Mapping.”

14. How did we get from here in 2009...

15. ...to here in 2015?

16. Idea #3
What role does Product Discovery play in
Workiva teams?

17. What is “Product Discovery”?
Product Discovery is a set of tools and methods that
allow you to evolve a product idea into an actionable
delivery plan, within just a few days.

18. Why is discovery important?
Ever ask questions like,
● Does my product solve my customers
problems?
● What works?
● What could be better?
● Where do we go from here?

19. Stuff I said
“I've never met an engineer who wanted to
build something over and over for a user
who has ZERO interest in using it.”
- Jason

20. Ever have feature discussions like this?
Illustration by Luke Barrett

21. What shared understanding looks like
...So, how do we arrive at this place?
Illustration by Luke Barrett

22. The Goal of Product Discovery
Image From: Jeff Patton. “User Story Mapping.”

23. Quick! To the UX Toolbelt
● Maps! (of all kinds)
● Customer Calls
● Sketching
● Prototypes
● Validation

24. We love mapping problems (+solutions)
● Maps are a CORE component of our UX
Toolbox.
● Visualizing information is infinitely more
powerful.

25. Our Compass
http://jmoo.re/jp-story
read it
learn it
love it
...and use it.

26. When should I engage in discovery?
Not often, only when you have a need to:
● Build an entirely new product
● Add new features to an existing product
● Innovate on existing features
Ok...so, a lot.

27. Empathy Maps
Rather than sympathy (pity), empathy allows you to
immerse yourself in a user’s environment

28. How we plan for a customer Call

29. If you make a habit of this, you’ll...
Do not ever ask, “what do you want?”
Image recreated from http://jmoo.re/3-better-questions
What do you
want?
Feature 2Feature 1 Feature 3

30. ...end up chasing features till you retire (or worse).
Build solutions, not features

31. What’s our alternative?
1. What are you trying to get done? Why?
a. Getting background information about what a person is trying to do is
critical to understanding your users.

32. Example
What are you trying
to get done? Build a Fence Why?
Image recreated from http://jmoo.re/3-better-questions
So I can surround my
front yard.
Why?So that I can plant a
garden.
Why?
So I can grow my
own food.
So that I can save
money on groceries.
USE CASE!Why?

33. What’s our alternative?
1. What are you trying to get done? Why?
a. Getting background information about what a person is trying to do is
critical to understanding your users.
2. Can you show me how you currently do this?
a. After understanding the scale of the ‘why’ and what they want to, step
into their shoes and see how they do it.

34. What’s our alternative?
1. What are you trying to get done? Why?
a. Getting background information about what a person is trying to do is
critical to understanding your users.
2. Can you show me how you currently do this?
a. After understanding the scale of the ‘why’ and what they want to, step into
their shoes and see how they do it.
3. Can you tell me what’s painful about this?
a. If you jump to asking users about how they think something can be better
from the start, you only get their opinion, not how they actually deal with
their current problem.

35. We try and remember that...
When talking to our customers,
● Great discovery feels like a conversation, not
an interrogation.
● We never assume that we know what a user
means. Ask.
● Silence is our friend.

36. Journey Maps

37. Journey Maps
● Allows us to understand what
the user is doing TODAY.
● It’s about mapping the process
of observing, and describing all
the experiences and emotions
the our user has as they
encounter a product.
● There will most-likely be gaps!
○ That’s why we’re here!

38. Time to Pause!
The tools mentioned previously are meant to
help create shared understanding about who
our user is and the pain around their current
solution(s).
Going through the motions without reaching the
why’s is called “Discovery Theatre”.

39. Do we know the user now?
Let’s map a solution!
“Story maps are really about discussion,
conversations, breaking big ideas into granular
detail..”
- Jeff Patton

40. What’s a Story?
A story is a named item that we might build in
our software
● It names what we might build
● It avoids saying how it would be built

41. Why Stories?
User stories act as the narrative with which you can have
conversations in and around your triad (PM/UX/DEV) and team:
Illustration by Luke Barrett

42. How do we write stories?
● Keep the language simple
○ Express stories in a language most people can
understand
● Build wide, then deep
○ Start with the big ideas and then backtrack.
○ Details should be discussed in other pertinent
meetings, where they are useful.

43. The life of story map

44. How it breaks down
Big Ideas (concepts)
User's steps
- smaller
steps
- UI details
- technical
details/steps
MVP/Release level
MVP/Release level

45. Build better maps
● Build a physical map when possible...and
let the rest of the team see it!
● Start with the ‘Walking Skeleton’
○ build wide, then deep
● Focus on the MVP’s or MVR’s (Minimum
Viable Release *)
● Add UI to the map to spark discussion
● Revisit the map constantly (during the
project)

46. Milemarker: Storymap Progress
A good way to understand if our story map is on
the right track is to sketch it out.
● Everyone on the team is invited to participate.
Yes, Engineers too!
● We pick a vertical column of our map and
timebox 5 minutes sessions to walk through it.
● Have each person share and discuss.

47. Sketching ideas … is a good idea
Rough sketch of user interface flow on a mobile app.
Image by Fernando Guillen.
Interaction Flow Single Screen

48. Why do we prototype?
To EXPLORE concepts
for ourselves
To VALIDATE concepts
with users
To COMMUNICATE
concepts with stakeholders
and teams

49. How we select the right fidelity
What is the FASTEST, cheapest way to
explore
validate
communicate
[ insert what you are prototyping ] ?

50. Prototyping: One size does not fit all
Low High
live data, polished ui, html
or axure
wireframes and lo-fi ui.
clickable interactions
paper or balsamiq, high
level flow

51. After we validate our hypothesis
Time to build ... aka define the MVP!
“The minimum viable product is the smallest
solution release that successfully achieves its
desired outcomes.” ← solves our clients pain!
Excerpt From: Jeff Patton. “User Story Mapping.” iBooks.

52. This is NOT MVP
Illustration by Henrik Kniberg
This is a beautifully incorrect product plan for MVP.
At every release the user gets something they can’t use, until the
last release when they get something that they finally can.

53. Bingo. MVP FTW
Illustration by Henrik Kniberg
If we build like this, our user gets something
at every release that they can use!

54. Define MVP
Excerpt and Images From: Jeff Patton. “User Story Mapping.”
“Focus on outcomes—what users
need to do and see when the
system comes out—and slice out
releases that will get you those
outcomes.”

55. Wait, that’s a lot of maps...
Q: How do I know which
one to use and when?

56. A: You won’t...right away.
The key is to build habits around around
each of these tools so that you can
recognize what’s appropriate and when.

57. It eventually becomes second nature
photo: boltmade.com

58. A sample week might look like…
Be ready — the plan will change. Adapt with it.

59. The way our interaction designers, product
managers and engineers continue to build and
iterate, is never ending.
There is no finish line…There is no finish line…
The way our interaction designers, product
managers and engineers continue to build and
iterate, is never ending.

60. @mooreplusone
Thank you!
Feedback + Questions
Welcome!
Thank you!
Feedback + Questions
Welcome!
@mooreplusone