What the f**k is an Experience Architect? Understanding the Role

What the f**k is an
Experience Architect?

What the f**k is an Experience Architect?

¨© Justin Tauber, Head of Platforms, Profero Sydney 2013

A story in 137 slides and 2 diagrams



But the answer’s obvious, right?



Experience = Customer experience
!

Architect = The guy who does the blueprint



Therefore...
an experience architect creates a blueprint
of the ideal customer experience
for the rest of the team to build



There’s some truth to this



Personas capture and summarize
customer needs and expectations



Wireframes are like an architect's
blueprints - all "boxes and arrows"



Functional speciﬁcations often read
like a development contract



But it misunderstands our role



It underestimates the need to
understand the business...



... and the technology



It undervalues the creative input of
designers and developers



I’ll attempt a better description



< refrain >



Experience Architects are
problem designers



Who build a shared
understanding of value



By doing research, analysis and
construction



< /refrain >



Say wha...?



Let’s break that down



What do I mean: “problem design”?



Anytime a brief is written,
a problem is being articulated



There are better and worse
ways of articulating a problem



“What are we trying to do here?”



“Are you building the right thing?”



The target audience just won’t care



Designing a problem isn't always hard



Experience architects aren't the only
ones who can do this



But experience architects are good at
designing complex problems



A well-designed problem has clear
criteria for evaluating solutions



Two kinds of criteria...



Objectives & Constraints



Your objective is your focus;
it is the point of the exercise



The objective is where the value is



Poorly designed problems tend to focus
on the effort, or the features



They focus on output,
rather than outcomes



“We need a better sign up form”
vs
“We need more people to sign up”



Badly-designed problems
presuppose solutions



Experience architects try to focus on
customer-centred outcomes



Allowing people to...
Encouraging people to...



This is why I go on about
User Stories



As a...
I want to...
So that...



As a... someone
I want to... do something
So that... something good happens



If you can’t say what the something
good is, the story is ﬁctional



Articulating outcomes as user stories
helps build a shared understanding of
where the value is for users



What about constraints?



Constraints are the conditions under
which a solution holds it value



...for the business
!

(“is it sustainable?”)



...for the team
!

(“is it achievable?”)



Constraints are the difference
between design and art



Experience architects help
articulate constraints



Experience architects help
turn problems into design problems



By articulating constraints, we build a
shared understanding of value for a
project team and their stakeholders



<rant>



Usability is not an objective



...because it is not a reason
for doing anything



Usability is a constraint



Usability = the conditions
under which someone
can extract some value
from your site



You can’t make a site “usable in general”



A site is usable
for someone
who is trying to
do something



</rant>



3 bags of tricks
(in no particular order)



Bag #1: Research



Research = asking pointed questions



... of the business



... of consumers



... of the team



(At Profero...)

The point of research is
not to gather information



1) to uncover hidden constraints



2) to test assumptions about value



Because every brief
and every design
contains a theory



...about what users want



...how they behave



...what the business can offer



...and what’s technically feasible



Bag #2: Analysis



Analysis = interpreting patterns
(in the performance team)



Analysis = digging up metaphors
(in the UX team)



Metaphors are pictures we use
as a shorthand for reality



They always conceal forgotten
assumptions



Metaphors get buried
...inside requirements



...inside designs



...even inside databases



Experience architects dig up
buried metaphors to ensure
they are actually ﬁt for the job



and build better metaphors
as required



Because a bad metaphor is
like a bad smell



It’s very hard to track down,
and makes everything seem just
a little bit... off



But a good metaphor can make
the next step obvious



...and helps everyone make
better compromises



Bag #3: Construction



I don’t mean building things



I’m thinking about geometry



Constructions are visual
thought-experiments



Constructions are a way of
stress-testing problems



... to reveal a way of simplifying
them



...to break them down into
smaller, more digestible parts



... or, at worst, to get a handle on
the kind and level of complexity
we’re dealing with



Most of the time, wireframes are
constructions in this sense



That’s why wireframes are not
like blueprints



What’s important is the act of
wireframing, or explaining the
wireframes.



Because that’s how we clarify
and articulate the problem



Ok, last bit...



So...
What’s the point of all those
deliverables?



Research Plans
Recommendations
Roadmaps
Personas
User Stories
Site Structures
Navigation Patterns
Wireframes
Prototypes
Functional Speciﬁcations
Usability Tests


Sometimes these deliverables
do end up deﬁning the solution



Because, often, expressing a
problem is ﬁnding the solution



But that’s not their purpose



We make them to share our
understanding of the problem and
the value trapped within it



The more these deliverables
dominate the design process, the
less creative that process can be



and the less room there is for
other creative members of the
team (incl. the client)



Ideally, these deliverables are
more like scaffolding...



... supports for creative
engineering.



But no less important...



... because, without a shared
understanding of the problem



... you can’t even begin to ﬁnd a
solution worth having.



</thanks>



What the f**k is an Experience Architect? Understanding the Role

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a What the f**k is an Experience Architect? Understanding the Role

Semelhante a What the f**k is an Experience Architect? Understanding the Role (20)

Último

Último (20)

What the f**k is an Experience Architect? Understanding the Role