Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:00):
Welcome to the IPX
TrueNorth podcast, where we
connect people, processes andtools.
Hello everybody, welcome back.
This is the IPX TrueNorthpodcast, where we explore the
intersection of operationalexcellence, digital
transformation and the peopledriving that change.
My name is Brandi Taylor, yourhost for this episode, and today
(00:22):
we're diving into a topic thatevery organization faces when
rolling out new digital toolshow do you ensure that your
users are actually going to usethese tools?
So rightfully so?
Digitization projects focus onbusiness requirements and
configurations, sometimes onlyto realize maybe too late that
(00:43):
the system feels clunky, maybeit takes too many clicks or it
frustrates users to the point ofresistance.
So joining me today is NickKaufman, a UX specialist with
deep experience helpingorganizations translate business
needs into user-friendly,efficient and effective software
(01:04):
experiences.
Thanks for joining me, nick.
Speaker 2 (01:07):
Brandy, that was an
excellent description and you
even got the pronunciation right.
Thank you so much.
Speaker 1 (01:12):
Oh good, I would hope
you'd correct me if I made that
mistake.
Speaker 2 (01:17):
Thank you for having
me.
Speaker 1 (01:18):
Oh yeah, it's a
pleasure.
So today, really, it's aconversation in my mind about
designing for adoption from dayone.
Right and why.
Good UX is good business, andwe often discuss on our side at
IPX the organizational changemanagement piece of adoption,
but we don't often enough talkabout it from a usability
(01:40):
perspective.
So you know, let's go ahead andjump into this perspective.
Speaker 2 (01:48):
So you know, let's go
ahead and jump into this.
Yeah, you had a great lead inwhen you talked about business
requirements and clunkyexperiences.
That's sort of my bread andbutter and where I live the
notion that if we have asix-month design and development
process, that we can save itall towards the end and do
usability testing and figure outacceptance testing and all
those aspects of did we do theright thing.
I think that that gets throwninto question of what do we ask
(02:12):
ahead of time?
What kind of usability studiesor in-depth interviews or
qualitative research can we doto ensure that it never feels
conky, that it just works?
And those are the areas that Ilike to play in.
The British Design Council hasthis double diamond analogy very
abstract, but it starts withthis generative thought of not
(02:35):
pretending you know the answer,but going out and validating
that you're making sure youdesign the right thing and then,
with enough research andunderstanding of strategy and
differentiators in the market oremotions and vulnerabilities
that the users might go through,you gather back and then you go
from a generative thoughtprocess and for those of you who
(02:56):
are listening at home, my handsare moving outward on the left
side of a diamond to now asynthesis process, where you're
trying to understand what it iswe just heard and that leads you
to think okay, now that weunderstand requirements and
where we're going to save theuser's time and improve their
experience, how could we do this?
(03:18):
Let's take from a green slateand that goes back to a
generative and then a synthesisat the end.
That's the double diamondapproach and that's where UX
comes in.
It helps facilitate thatprocess amongst PMs, amongst
engineers, stakeholders, andtries to be that human in the
loop, that user-centric approachto the design and development
process of any product orexperience.
Speaker 1 (03:37):
I love it.
So, you know, I think everyonetypically thinks of this as
something that's developed intothe tool, and there's a lot of
that.
But I also want to make surethat you know today we're
thinking about this from animplementation perspective too,
right, because these tools aremeant to be configured, you know
, and so we want to make surethat.
Are there things that we can do, you know, from our perspective
(03:59):
as well, as companiesimplementing tools or as users
or as IT team or whoever'swriting these requirements.
Is there something we caninclude there to try to have
some of that as a forethought?
So I guess, before we jump intoo deep, I would love, do you
mind just giving our audience anintroduction of yourself and
maybe a little bit of yourbackground, so we understand
kind of your experience andwhere you're coming from.
Speaker 2 (04:21):
Sure, here's the
origin story.
For those of you who arelistening during the summertime
of 2025, and that might haveschool-age kids in the house,
this is camp season, where theygo off to their various camps.
And I remember a time maybe Iwas eight or nine years old
where I was at a camp and one ofthe counselors sat us down at
the table to do some drawingexercises, and I remember that I
(04:44):
came away from that 15, 20minutes of a drawing exercise.
I'm really pleased with myoutcome and what it is that I
had done, and I had sort of heldon to that memory many, many
decades later now as one ofthese affirmation of you know,
this is not a bad thing to dowith my time and with my mindset
(05:04):
.
I think I was one of the earlyinstances of a flow state where
you know as a kid you don'tquite know what flow states are
and how rare and wonderful theycan be to all of us that are
constantly trying to achievethem.
But that has given me reflectionabout who it is and what I want
to do, and I've held on ontothat throughout the universities
(05:27):
and then into my early career,and so those visual designs into
interaction design and theninteraction design, when it
became more of aexperience-based concept, where
it wasn't just the interactionor the interface, it now became
the entire experience ofsomebody as they went through a
(05:49):
product tool, technology event,whatever it might be, that spun
us designers off into beingresearchers as well, so that our
subjective presentation of a uior design was now being
processed by somebody else.
And where did they get confusedand where was it intuitive?
And that has been sort of whereI've sit ever since is to be
(06:13):
able to conduct research andstrategy to inform educated
design decisions, to sort ofmitigate risk of are you
designing the right thing?
It's like no, we can prove thatwe did the homework, so that
it's not just this showcase oftechnology or shiny new tool.
This, in fact, is meeting auser need and will be adopted
(06:35):
upon arrival.
That's about 40 years and 30seconds, so thank you for
letting me know that.
Speaker 1 (06:43):
Awesome, okay, no,
that's perfect, thank you.
So to kind of continue on withour discussion.
So, from your perspective, whatare the biggest misconceptions
that organizations have aboutuser experience?
And I know we keep saying UX.
I just want to make sureeveryone understands that we're
talking about user experiencehere with enterprise software
projects.
Speaker 2 (07:00):
Yeah, you know,
misconceptions 20 years ago was
that anything with a perceivedaesthetic was seen as weak or
not enterprise grade, if youthink of the old sort of Oracle
databases of the past or the SunMicrosystem CD ROM where you
install or have just really badUX of their interfaces.
(07:24):
But there was a badge of pridebecause it was built by
engineers for engineers and sothat must be of quality.
A horrible metaphor that I'musing is a Russian tank isn't
known for its seat cushions.
A Russian tank is big androbust and, current geopolitical
(07:49):
situations aside, it brings tomind this sort of impenetrable
efficiency because we built itto be big and strong.
But the iPhone changed that,where this notion of it just
works, and that it clearlyplayed attention to it and it
had a design aspect to it and,most importantly, was wildly
successful and it made Apple themost valuable company in the
world at the time.
(08:09):
And it changed the perception ofdesign and there was also this
notion of Apple products of justworking is that they changed
the perception of experience,where they anticipated human
needs and points of confusionand were very good at
understanding those paths ofdecision and consideration and
(08:30):
really began to be the forefrontof what it meant to deliver an
experience.
Another early example is Uber,where there was this notion of a
peer-to-peer economy thatwasn't as commonplace as it is
today in the airbnbs and all theother gig economy companies of
the world, where when you openedup that uber app and you saw
(08:53):
these taxi cabs driving around,those were fake, but what the ux
provided you was an affirmationthat oh, they're everywhere and
I've never used before, but Ican see all around me that there
are people inside of them.
So therefore it must be safe, itmust be convenient, because a
reason that I'm using this appis A I don't want to talk to a
(09:15):
dispatcher and B I don't want tostand on the side of the road
with my arm in the air becauseit's embarrassing.
And so Uber was wonderful withthat little animation,
alleviating two of thevulnerabilities that the
consumers might have had inadopting what was a fairly new
concept of a ride sharingservice and that came with
(09:35):
research and understanding ofthe user and providing of a good
user experience.
Even if it was fake when youopen the app, it helped
alleviate that adoption considerit adoption any of those
barriers as well as sort of gaveyou affirmation that it was
going to be more easier andconvenient than a traditional
way of doing things.
Speaker 1 (09:56):
I love these examples
because you know, I think a lot
of the people that work in theorganizations that we deal with
you know they get tools, theyjust use them right, whether
they like them or not, they'renot really thinking about this
too much and they're just doingit because they're told to and
it's their part of their jobs.
But I love the iPhone exampleand the Uber example, but for me
(10:18):
, iphone I just I can't help butthink back to the Blackberry I
had before my first iPhone andyeah, it was cool and everybody
had that.
But my gosh, like, that littlekeyboard was absolutely awful.
It tried to, you know, it triedto mimic a small laptop, right,
and it did a terrible job ofdoing such and so it was so easy
for when the iPhone came in,that made such sense with that,
that small size and and just thethe user intuitiveness, you
(10:41):
know, and the ease of operation.
So it's such a great examplefor those who aren't familiar
with this concept.
Speaker 2 (10:46):
And that keyboard was
a huge barrier to adoption for
many was they wanted a tacticalsensation of typing.
They couldn't imagine a virtualkeyboard.
But now I've got a couple ofthose sort of antique relics
displayed in my living room ofall of these technologies that
either I'd burned through orjust want to touch again
(11:07):
Everything from the Visor PalmPilot to the Blackberries and
the Nokia Flip Bones of theworld.
But there was a sort of a dayin which that was a concept that
a lot of people weren't wantingto give up is that tactical
keyboard, and I think the samething is true with the
technologies that are washingacross our bow right now is that
(11:28):
there's elements of trust andprivacy and patience and
curiosity that come in withadopting new tools, of which you
must see on a daily basis,Brandy with change management
and organizational design ofwho's willing to adapt and who
wants to stay the way they are.
Speaker 1 (11:43):
You got it.
I mean even me with small hands, or even my kids with small
hands, like I think about anygeneral man I've ever met like
there's no, they're fatfingering those little tiny
keyboards.
But I agree with you, oncewe've gotten past what our bias
is and open to new things, Ithink there's just lots of
opportunity there.
So that's kind of key tochanging culture and things.
(12:05):
So you know, how does tell me alittle bit from your lens, like
, how does user experiencedirectly influence user adoption
?
Thinking about it from like abusiness perspective, when
they've implemented a newsoftware tool, it's rolled out
within organizations.
How does user experience affectadoption and the effectivity of
the tool?
Speaker 2 (12:23):
I think that Uber
example is a good one because it
isolated the embarrassing part,or the frustrating part of what
was traditionally a taxiservice, where always the
dispatchers weren't really goodat understanding English or what
you were trying to say, To haveto call and negotiate with
(12:43):
somebody and not have a clearunderstanding of how long it
would take for a taxi cab toarrive at a desired pickup point
.
I remember there's a littlestory about my past.
I remember when I was incollege, you know, back before I
knew how taxis work and I waslate to the airport, as many
college kids are, and I calledthree different taxi cab
(13:06):
companies, all telling them topick me up as soon as possible
because I was going to miss myflight and all three everything
into the ring at the same timeand so those kinds of points of
(13:28):
frustration.
To go back to your questionabout user adoption is that the
researcher would understand thevisibility and transparency of
how long it's actually going totake, which suggests that a
service that can calculate itfor you, at least give you a
number to look at, is going tobe a huge differentiator from a
service that previously wasn'tchallenged.
And I had mentioned thosepoints of standing on the curb
(13:50):
and waving your hands in the air, which is embarrassing because
it says, hey, I need a ride,anybody please pick me up.
And now to be able to do sofrom the privacy of your own
device was a fairlytransformational moment.
I think that that analogy ofending the context for which
it's being used in will help anybusiness improve their
(14:13):
experience.
Another quick one I am oldenough to remember when Snapchat
first came out and it was asort of culture gap for me when
I first opened it, because itopened up to a camera and I
wasn't used to a social mediaapp opening to a take a picture,
(14:36):
because I was just wanting tosee what was there and sort of
what.
There was a feed or something,and it was a jarring experience.
But what I would guess is thatthe researchers or the
strategists, the productdesigners for Snapchat, what
they did was they said you wantto be able to take a picture as
quickly as possible.
Our lifeblood is in peoplesharing photos, so push this.
(14:58):
As the very first experience andyou can see an analogy is that
with my, with my pixel, AndroidPixel, if I double click the
power button, it jumps into acamera, because life happens
very quickly and if I want totake a picture of something
again, kids are a very fastmoving species If I want to take
(15:18):
a picture of something, I don'thave time to unlock the phone.
Scroll through my home screen,find the photo app, open the
photo app and take the picture.
I want to be able to jump intothat action extremely quickly so
I don't miss the moment.
And those kind of shortcutsaren't evident to everybody, but
they're a good example of howthere can be an element of
(15:39):
frustration, of I missed themoment because I was fiddling
around and I couldn't get intothat execution very quickly.
So those were two examples ofhow UX might lead to adoption.
Speaker 1 (15:51):
I love it.
You know, I think before Ubers,you know, with the cabs, like
you said, even someone likemyself who I'm not super worried
about being embarrassed butit's just feeling confident I'm
not.
I don't live in a big city, sowhen I do travel to a big city
and now I have to hail a cab,like what Uber did was just
eliminate all of the guesswork,right, and I feel in total
(16:11):
control.
I can see where the gentleman'scoming or the woman's coming, I
can see their face, I can seetheir car like I know what to
look for, I know exactly wherethey're at and where they're
going to show up.
It just the experience isdrastic and it's huge.
So I love thinking about someof these things that we didn't
even realize were poorexperiences when we had them.
Speaker 2 (16:31):
When you travel
abroad, the notion of how much
does it take for me to get fromA to B, and the language
barriers in a different country.
I, my wife and I, when we usedto travel into Portofino, into
the Italian Riviera, there, Iremember one time we got hustled
because the cab driver saidsomething that we thought we
heard, and when we got there theprice was 4X and we're like,
(16:54):
wow, okay, here's the money.
We'll be walking homeno-transcript.
Speaker 1 (17:13):
Yes, I love being
able to feel like I'm empowered
to make good decisions and evenwhen it's really expensive
because I'm in a big city, Istill have options.
I still can pick someone who'sgoing to be here in three
minutes as opposed to 15.
And I can decide whether or notI want to save money or not.
But it it makes me feelempowered.
I love that feeling.
So it's it works for me.
Okay, very cool.
(17:52):
So one of the recurringchallenges that we see with our
clients is we write and IPXhelps this right.
We help them with businessprocesses, lead and tools follow
.
So we write and help peoplewrite formal configuration
requirements and then.
But what people don't know iswhat truly ends up feeling
clunky or inefficient untilthey've gotten to the point
where they're at user acceptancetest or even after go live and
it's kind of, in some light,seen as scope creep or new
requirements.
(18:12):
So, from your experience, howcan organizations think about
that up front?
Is there anything we can do tohelp drive usability
expectations early during thatrequirements gathering phase?
Speaker 2 (18:24):
I've come across this
many times in my career,
especially with largeorganizations, where a product
is dead on arrival and how doyou mitigate the risk so that
all of the time and investmentthat has gone into that product
makes sure that it sees thesuccess that it was designed for
?
And I think that there's alsothis fallacy of that we are
(18:47):
experiencing within ourprofessional lives, that we can
jump to the end much faster nowthat we have these tools at our
fingertips that will improve thedevelopment, the design and the
speed in which those occur.
And if we're able to conductuser-centric activities with an
(19:07):
admittance of, how would wethink about this if we did have
time savings in the back end,rather than saying, well, we can
do it in half the time, solet's make half the timeline and
we'll just rush to the end?
An analogy I use a lot iselectric bicycles, where these
generative tools have given usthis newfound feeling of speed
(19:30):
and velocity and augmentation.
And the danger is that you areon an electric bicycle and you
are in 30 miles the wrongdirection.
Well, that speed and efficiencyhas just carried you further
from the true north that you'retrying to go to and now put you
even further in the wrongdirection.
And so to save that time at theend of the development process,
(19:54):
of the business process, to usethese new tools to buy you time
to do more strategy research iswhere we're going to see
improved experiences and againmitigate the risk that
everything we did up until thatpoint.
I spun up a landing page aroundthis Sorry for the shameless
plug, but it comes to mind andthe URL is doa
(20:16):
deadonarrivalgageio and it talksabout all the different methods
that one can do Prototyping.
Again, prototyping is somethingthat admits that you have an
idea you want to put people infront of in this case, an
application, whether it bemobile or desktop, or an
experience, and that you'rewilling to iterate that
(20:38):
prototype quickly so that by thetime you get to the end
deliverable, you've goteverything locked down, it
doesn't feel clunky, it feelsintuitive and that it takes into
account all the data in anelegant manner.
Speaker 1 (20:50):
I like that and I
also think you know we all from
a company perspective, you knowwe all talk about being agile.
I think from an implementationperspective, I think it's really
helpful to to not have that bigbang approach right when the
developer goes off and does abunch of configuration and then
comes back and says here, we'vemet the requirements.
(21:10):
So how do we think about it?
From an iterative fashion,where we're seeing snapshots of
of capabilities throughout time,so that way we have some
visibility throughout and we'vealready incorporated maybe a
percentage of resources.
We've scoped it in, not knowingexactly what this is yet, but
(21:31):
we want to make sure that we'rethinking about these things so
as they come up.
It's not saying well, thatscope creep right, like we've
met the requirement.
Well, we didn't really know.
You're always going to uncoverrequirements as you start to
implement and use thesesolutions.
So how do we make sure thatwe're thinking about that
throughout, ahead of time andthen as well, throughout the
development of the project?
Speaker 2 (21:51):
Yeah, the good PMs
build this in and you know, as a
consultant, I come into contactwith two or three a year with
two or three different projects.
And the ones that have thatsense of time, have that sense
of pressure of we need to launchthis by this date, are the ones
that often rush the strategyand the research and the
(22:14):
conversations that need to occurand the requirements that need
to generate from thoseconversations and, as I
mentioned, there is going to bethis time savings through the
ability to generate engineeringdesign deliverables at a very
faster rate than we've everexperienced before.
And so you used a good wordallow for ourselves to take
(22:36):
those inputs in and schedule andbudget and resource them
accordingly, so that theincreased philosophy is met with
informed decision-makingprocess.
And so I think that also goesinto the curiosity of an
organization to say, okay, howdo we start to think about this
in a new way?
How do we bring in the honestyto say that we don't know
(22:57):
everything, but we do haveeducated guesses and want to go
confirm that before starting.
That vulnerability from anorganizational standpoint or a
departmental standpoint issomething that needs to be baked
in to say, you know, we arethis human-centric organization.
Here in San Francisco there area number of SaaS products, very
small companies, series A,series B even Seed Round that,
(23:20):
because they're so concernedwith user adoption, within their
onboarding process they willsend a link into their CEO's
calendar and I'm sure they'vesort of guarded the time
effectively so that you knowthere's not more than one or two
a day or not more than ahandful a week, but to be able
to book time with a CEO or afounder of a product and
(23:44):
communicate to them directly tosay here's how you think I'm
using it, but here's how I'mactually using it.
It's failing on these measures,but here are ways that you never
thought I was using it before.
I try to adopt a lot ofdifferent tools into our process
here and every time there isthat link into a CEO's calendar
(24:05):
to show them hey look, this ismy interpretation, my evaluation
and context of use, what do youthink?
And it's wonderful to see thesecompanies, from an
organizational standpoint,allowing for that input cycle to
be constantly occurring so thatthe decision making that
they're choosing of is thisvaluable direction to take my
(24:27):
company into.
Is this a loop?
But that needs to beestablished and maintained as a
constant feedback cycle, andthat's healthy for any
organization, whether it beSeries A or Fortune 500.
Speaker 1 (24:49):
Yeah, I agree, and I
think about user acceptance
testing.
You know, I know a lot of timesorganizations, you know they
lean on their system integratorto do all the things because
they say these are thecapabilities that are included
in this contract.
And to me, when that happensand this is not against the
system integrators they're thereto get the project done and to
(25:10):
meet the requirements.
But what we see sometimes isthat they've just included Happy
Path.
So they've, they've done thisuser acceptance test plan and it
walks through exactly what thebusiness process says and walks
everyone through their roles inan ideal world.
But in real life that's notalways what people do.
They're not always going tohave their how to right next to
(25:32):
them.
They may go in and they'regoing to try to do different
things.
So to me, I think it's reallyimportant that organizations own
their user acceptance test planand try to think about it from
I don't know if it's a misuse orjust a, you know, like more of
a off case kind of scenarios aswell, and see what they can do
to I don't want to say break it,but just, you know, to make
sure that we're trying to thinkabout these things so that way
(25:53):
these things are caught now, asopposed to.
You know, we typically use ouracceptance test with the subject
matter experts.
Then, after it goes live,everybody's happy.
The rest of the world thenstarts to use the tool.
That's when you start to haveissues.
And you know, we've seen thiswhere we call it.
We've fed the organization foodpoisoning in some way, right,
because now they don't want touse it.
(26:15):
But the money's gone, theproject's done.
Speaker 2 (26:22):
Tell me a little bit
there about your perspective on
user acceptance tests and how dowe be better at that?
I think it needs to be aconstant cycle.
It becomes not as the end pointof a process but as an ongoing
point of the process, where it'sa voice of the customer program
and it's not from a salesperspective but it is informing
strategy and PMs as much asanybody else.
(26:43):
And that feedback cycle canhappen at conferences, it can
happen through observed UATtesting on specific products and
it can happen as an openinvitation of come find my time
on the calendar.
The community of users willalso help each other, and so to
foster out forums and to be ableto facilitate those who are the
(27:06):
rock stars of your usercommunity is a customer
experience feedback cycle.
We've seen UX get reappropriatedinto that CX term, where now're
trying to really make it feellike you've made a choice,
you've joined a community.
We are fostering an open andit's not transactional where
(27:27):
every time it's at the end of asale or at the beginning of a
sales cycle, but instead it'sthat a friend just calling to
say how's it going or how areyou using it, what's happening
in your life, a friend justcalling to say how's it going or
how are you using it, what'shappening in your life.
That is good user experiencebecause, again, you're
absolutely keeping theconversation open for honest and
vulnerable feedback to theproduct.
Speaker 1 (27:48):
So tell me a little
bit about how can both sides
maybe the from the vendor sideand the client side collaborate
better to avoid this scope creeplabel that comes.
You know that are for thingsthat are discovered late in the
process and you know, typicallywe see, you know we're trying to
get the best price, so we'venegotiated these suppliers and
(28:08):
vendors, system integrators,down as much as we can and
that's why we've chosen them.
So you know, from almost fromboth sides honestly vendors and
the clients UX is kind of a niceto have and it's the way that
we've set it up from design bynegotiating down is that you
know the nice to haves areprobably not the things that are
(28:28):
going to get prioritized.
So how can we be better on bothsides of this?
Speaker 2 (28:32):
So how are you?
You've taken me to a dark place.
Welcome to my world, where youhave now identified the nice to
have, and it goes back to thisnotion of aesthetics, or there's
a misunderstanding of theimportance of UX and the risk
that's involved with notincorporating.
And, as I referred to, thereare organizations and
(28:56):
representatives that see thevalue or don't see the value or
care about the risk.
And so, to look at theorganizations that are known for
good design and Apple at thetime was this wonderful calling
card I was like well, they areconstantly rated as having the
(29:17):
best design principles and thebest UX and, again, at the time,
the most valuable company inthe world, and so it's hard to
write that off as not beingimportant or crucial to the
lifecycle.
It starts within product, wherethe VP of product or whomever
is going through and makingthose decisions about how much
(29:38):
to over or under engineer or howto prioritize what we do, and
we don't know where thosedecision-making processes exist.
That tends to be our sponsor.
We want to make sure we bringin somebody that's able to
extract information, emotionsand voices and present it in an
(29:59):
indifferent manner so it doesn'tlook like it's being accusatory
of one department or the other,but is absolutely neutral in
how I'm using this, how this isaffecting me.
And it's a great alignmentexercise too, before kickoff of
a project or before everythinggets going to say, oh, we all
(30:19):
see and hear the same thing.
You know, there's no skin inone opinion or the other.
We're presenting this out sothat the team can be more
efficient in a unified, truenorth goal together.
So I know that answer wasn'tdirect.
It really comes in seeing thevalue of mitigating your risk
(30:41):
and increasing the likelihoodthat all this work will be well
received and the product itselfor the service itself will
succeed.
Speaker 1 (30:50):
These tools are so
expensive and licensing is so
expensive and you know, I thinkwe've pushed at IPX on the
organizational change managementside, as I said, that this is
not a nice to have right Like.
This needs to be its ownproject that runs in parallel it
needs to not be an afterthoughtin order for this solution to
(31:11):
be adopted, used and successful,efficient and effective for
your business.
All of the things that has beenpromised is pending on these
things, and to me, userexperience is no different.
So how can organizations buildthat culture where user
experience is not anafterthought, that it's a
(31:32):
strategic part of what we'recalling operational excellence
right.
How can we at IPX help theseorganizations see things
differently?
Excellence right.
How can we at IPX help theseorganizations see things
differently?
Speaker 2 (31:40):
Yeah, I mean show the
horror stories.
One of them comes to mind asyou describe your engagement
Adobe, a number of years ago,was looking at their auditing of
the technology in place fortheir support team that would
handle ticket requests overseas,and the notion of what the UX
of their current solution wasdoing versus the reality of how
(32:04):
that team would operate was avery stark difference.
And this comes through processauditing and in-depth interviews
and over-the-shoulder show mehow you handle these kinds of
workflows service design,customer journey blueprints but
what was revealed is the numberof workarounds due to the bad UX
(32:24):
.
They were fighting constraintsof infrastructure and bandwidth,
as well as the feature set thatthey thought they would use
that didn't actually use it, andbecause data was being passed
from one system to another, toanother, to another and they
were on the receiving end oftrying to find out that customer
information so that they couldbetter handle the ticket.
And the number of ancillarytools that this team was
(32:48):
spinning up and using on theirown, unofficially licensed, in
order to fulfill the job thatthey were meant to do, showed
that the UX of the tool that wasprovided for them they were
meant to do showed that the UXof the tool that was provided
for them was suffering, as wellas the environment in which they
were doing the work under wasalso needing a revamp.
(33:08):
So those kinds of horrorstories of the expected use
versus the actual use are greatillustrators of hey, here's why
and how we need to improve Again.
I'll go back to a young kidreference.
For those of you listening athome.
Jurassic Park is something thatis popular somewhere with the
release of the new movie and wewere watching Jeff Goldblum in
(33:32):
the original talking about humanbehavior or animal behavior,
where you think you know howit's supposed to work, but
there's this chaos theory of itwill never behave how you think.
And I think that software andhumans using software is very
similar to Isla Nubla, wherethey're going around in the
carts and then the dinosaurs eatthe people.
That usage is what's worthillustrating as expected
(33:57):
experience versus actualexperience worth illustrating as
expected experience versusactual experience.
And how does that translateinto our next product cycle of
where do we start to guideexperience so that we don't have
to do the workarounds and thecopy and paste and all of the
error prone and redundant tasksthat can have reverberations?
I've come off of a financialservices client where it was an
(34:19):
internal team of about 12 peopleand the workflow was as such,
where if there was a mistakemade and they were making deals
with other financialinstitutions, but if they made
an error, you use the word fatfinger but if there's a sort of
a digit or a number off, theimpact of that was in the tens
of millions of dollars in remitsthat this financial services
(34:42):
firm would have to pay the dealpartner and then the cost not
only involved with having toredo the entire deal but have it
backed up was in such a highimpact and that was 100% a user
experience challenge of make itso that there's error validation
happening earlier on that thecontextual information of just
(35:03):
enough data to be displayed onany one screen as not to
overwhelm the end user so thatthey're not seeing everything
they need to see from alegibility perspective.
Those kinds of impacts are realand not just aesthetic or
subjective but have a truefinancial cost to somebody
getting their job done veryeasily and somebody flaming out.
Speaker 1 (35:25):
Yes, unfortunately, I
think it's those examples of
what are you missing by notincluding this?
I don't know if it's a scaretactic, but I don't know how
else to get that across is.
Try to communicate those thefood poisoning examples, right,
(35:45):
that's.
That's the only way, unlesssomeone has lived this and done
this, and then they're justterrified.
They've had a really badexperience implementing
something.
It didn't go well, and thenthey're they're gun shy, moving
forward instead of trying totake those lessons learned and
work them in.
So you know, I think we, I thinkthe iPhone example and the Uber
example.
So you know, I think the iPhoneexample and the Uber example,
those companies have spoiled usin some way, right.
And so when we think about thisfrom an organizational
(36:23):
perspective, with big companiesimplementing tools like ERP or
PLM or, you know, requirementsmanagement tools, things like
that, I think we all expect, weall want a simple interface,
right, like, in theory, we wantthis and we want user experience
, but we assume that it'simplemented by the developer in
the out of the box tool.
So that's why everyone wantsout of the box, because we don't
want to make things complicated, but we have very complex,
heavy industries.
So how do we what are?
Are there any common mythsabout what people are expecting?
They want this simple interfaceand a complex, process-heavy
(36:44):
industry.
How do we solve that?
Speaker 2 (36:46):
Yeah, lack of
customization, where it is just
this way because it's just thisway To challenge that or to have
an arrangement again.
I know you work with largeplatforms for large
organizations, but to work intothe contract is that there's
this sort of ongoing iterationof our workflow process is not
(37:10):
going to be similar to everyother customer you have and
you're going to sell ussomething.
But we're also going to have aprofessional services agreement
built into this so that you cancontextualize different steps
along the way.
We'll help provide yourequirements for that.
We'll give you the research andthe insight for why this should
(37:30):
be in this manner or thisshould be in this manner.
But what we don't want to do isstart to create noise in which
drags down our internal team orour external users where it's
not quite right for them andwe're trying to fit a square peg
into a round hole, and that, Ithink, is, from an
organizational standpoint, justa call sign to say, look, we
(37:54):
have to choose something that isagain a large enterprise
solution.
But what we want is to make surethat you will work with us to
help it meet our specific needsand that, if it doesn't, or if
we see that these workaroundsare happening again.
In this case, it was a lot ofsort of going into other
documents and pasting data backand forth things that should
(38:16):
have been propagated within theplatform itself, communication
tools through other channelsthat weren't being used, and
forth things that should havebeen propagated within the
platform itself, communicationtools through other channels
that weren't being used, becausethe UX of the chat apps inside
the platform was insufficient torefer back to what was
happening in real time.
And so to have thatprofessional services engagement
with the company, to say thatyou will customize these things
(38:39):
or help us make it better forour team, I think is an
admittance that it is an ongoingprocess, so it's not a one-time
transaction, is experience, andit is that workflow, that flow
state that we hope to achieve.
Speaker 1 (38:56):
You said.
One thing that I wanted to justdiscuss a little bit more in
detail is the copy-paste right,data copy-paste.
And you know, sometimes wethink of user experiences as
focused at a developer or onetool, and I really want to
change perception that we needto own it as someone who's the
(39:17):
user side, the business side,and because we need to think
about this from an enterpriseperspective, that user
experience is the digital threatas well.
Right, it's end to end and thathas to do a lot with our tools
also being connected and havingthe single source of truth and
the data being edited in thesource of truth and also then
(39:38):
shared amongst tools.
To me, that is also userexperience, would you agree?
Speaker 2 (39:43):
Yeah, your analogy
rings true.
I had a conversation withsomebody at a large IT services
company yesterday and she hadmentioned that a new CEO had
come forward and was told thathere's the Salesforce numbers
and here are the real numbers,numbers, and here are the real
(40:04):
numbers.
Yes, see, it goes like we can'tdo this.
Those numbers have to be thereal numbers and that's it.
There can't be multiple sourcesof truth.
There has to be a single sourceof truth, and copy and pasting
is an evidence that integrationisn't working.
Is that this system isn'ttalking to this system or we
haven't added a bridge in placeto remove that manual process of
redundant tasks and I knowthere are tools out there coming
(40:26):
onto the market very quicklythat will do that for us and
hopefully eliminate those jobsor those parts of our jobs,
because they are so error proneand also a high cognitive load
is to do that repeatedly, allday, of data entry and transfer,
manual transfer of data fromone system or platform to
(40:48):
another, when this is what weshould be paying for is to
improve that kind of efficiency.
Speaker 1 (40:54):
Yes, and I think
that's the minutia that takes
over people's lives at work on aday-to-day basis.
If we could actually estimatethat and capture that, it's an
activity that should be done.
Reducing and eliminating someof that minutiae, I think, is
key, and it's about you knowmaking your resources that are
already stretched thin, you knowactually doing the value-added
(41:17):
tasks that they were hired toperform, as opposed to some of
this minutiae, right.
So, which brings me into youknow one.
I'd like to just touch base onAI here for a second, as we're
talking about that and you know,maybe tell me a little bit
about your brain on AI, of howmaybe it's you know, low-code,
no-code platforms or whatever itmay be, or just AI in general.
(41:39):
How is this changing the UXdynamic in enterprise software?
Speaker 2 (41:44):
Yeah, I consider
myself lucky to have been around
long enough to have seen cycleslike this in the past, and
there was the initial wave ofdigital transformation that was
going to eliminate pen and paperand fax machines and make
everything now in spreadsheetsand word documents.
(42:04):
And there were those whoaccepted digital transformation
at that first stage and thosewho resisted against it, and
some of those are the mostcharming, uh, and intimate
restaurants and store ownersthat you can imagine, where
everything is written down.
Oh yeah, they're cute, but interms of my life and my work I
(42:35):
was one of the first generationsto come into were designing for
didn't need to be constrainedin the 640 by 480 desktop screen
at the time.
Now there was this mobiledevice in which our context had
to shift how we were designingfor and I know that's a separate
(42:56):
sort of line of thought interms of UX, specifically
because the waves oftransformation are even larger.
Because, as the cloud becameindustry standard in maybe 2010,
2015, there were those whodidn't trust it, who wanted to
see the icon on the desktop, onthe hard drive, because they may
(43:19):
have had a bad experience withlosing data in an early instance
of the cloud, and they stillstay within spreadsheet
applications to do tasks thatthere are, for example, crms or
hour tracking or things likethat.
That's not or budgeting orinvoicing and their familiarity
was with on-prem or on-laptopsolutions and didn't ever make
(43:43):
that to cloud-based because ofissues around privacy, of trust,
reliability, and I think thosethree emotions are now going
into the privacy, the trust, thereliability of the information
that these generative servicesare giving us.
So, to answer your questionmore directly, brandy, it is a
huge deal about what it is.
(44:05):
I do because one of the thingsthat the algorithms are good at
are establishing patterns, anddesign is a lot about standards
and patterns, just asengineering and code is
functions and formulas, andwe've had these tools that have
been trained on our last 10years of work of designing
(44:25):
patterns and principles andorganizations, and now, with the
snap of your fingers, you canreference and recreate all of
that, and so it brings into thequestion of where is that value
of design now If it's not in theinterface?
Now it's in the experience, andso we'll start to find more of
(44:45):
an emphasis on help me give someunderstanding about what it is.
I can design and develop evenfaster, but help me give some
understanding of what it is Ishould design and what kind of
emotions do those refer to?
Because I don't think ouralgorithm is quite there yet to
really have that.
When somebody stands on thecurb and puts their hand in the
(45:06):
air, that's a humiliatingexperience for them.
That's something that you and Ihave shared experiences on, and
that we can help guide thosetypes of decisions early on in
the strategy process.
Speaker 1 (45:17):
Yeah, you know, like
you said, like waving your hand
for the cab is embarrassing.
So Uber eliminated pain.
Now, when we think about thisfrom an organizational
perspective or a culturalperspective, you're trying to
automate the minutiae thatpeople are comfortable with.
So, instead of eliminating pain, you may be eliminating pain
for the organization, but forthe user you're taking away
(45:38):
their safety blanket right ofthe ways that they've always
done things.
So it's a different challenge.
Speaker 2 (45:44):
It's true from an
organization perspective.
We talked about UX a lot.
I think EX the employeeexperience is just as important.
We're going to see thisadoption of AI tools as a core
competency within the workplace.
Just as somebody has to be goodat email, somebody has to be
good at file management,somebody has to be good at
understanding where thealgorithm should and should not
(46:05):
come into play.
The first time you get anautomated reply which is clearly
a generated email from somebodythat you know, you're kind of
an eye roller like, couldn't youhave taken the time to actually
write that, rather than clickthe button and do a pseudo voice
, something written in yourvoice but not actually by you?
I think that that literacy ofwhere the algorithms will help
(46:29):
us and where it will hinder usor just is not appropriate is
going to be a competency withinthe workplace.
It's going to be extremelyimportant over the next couple
of years.
Speaker 1 (46:39):
So I guess, just kind
of closing our discussion today
, if you could give one piece ofadvice to anyone or any
organization planning a digitaltool implementation today any
words of wisdom from yourperspective of what could it be
to ensure user adoption?
Speaker 2 (46:56):
Yeah, I'm going to
again apply DOAgaugeio.
I want to mitigate the risk ofhaving gone through these
processes and user adoptionstarts to fail to allow for the
saved time.
You'll, or should, hear fromyour design and development
teams on the back end ofimplementation to really
(47:19):
emphasize what kind of feedbackcycles can we establish before
we begin To start with the?
How might we, before we pick upour pencils and pens and begin
to draw I think that's going tobe increasingly important
because the velocity is going toallow us to make worse
decisions even faster.
And then the same thing is truewith the backend is to have
(47:42):
this feedback cycle and envisionhow, when we design this as an
experience, not just as aproduct how to incorporate
feedback loops so that we caniterate.
And it's not a two-week periodat the end of development to say
we're going to do UAT testingand that's no, it's going to be
(48:04):
something that's an ongoing.
Part of our organization, ofour ethos, is to really connect
with that human experience,because that's what's not going
to get left behind from thealgorithm.
That kind of voice and opinion,a conversation like this go a
long way, and thank you againfor having me.
Voice and opinion Conversationslike this go a long way, and
thank you again for having me,because I think that's going to
be again one of the importantparts about what it is we do is
(48:33):
our ability to interpret andcommunicate human experiences.
Speaker 1 (48:34):
Yes, I agree, I think
so many times we think, hey,
you know it's people's jobs,we're going to give them a tool,
they're going to use it.
It's just is the way it is.
You know, do it, do your job.
But I think just being mindfuland intentional about success of
the project after the fact, Ithink is is just important.
That's the recommendation today.
So this has been super fun forme, nick.
It's a it's an interestingdiscussion and you know it's
(48:56):
things that we come into contactwith.
You know almost on everyproject in some light, and you
know it's things that we comeinto contact with.
You know almost on everyproject in some light.
And so I just want to thank youso much for joining us today
and I just want to give you aminute, you know, to give
yourself those humble plugs.
So where can listeners learnmore about you, the work that
you do, and about Gage?
Speaker 2 (49:13):
Yeah, for those of
you who are in the product or
design industry, I'm doing amaturity assessment for the
community or design industry.
I'm doing a maturity assessmentfor the community.
I will start to report back anykind of segmentation or factor
analysis as I see more and moreresults come in, and you can
find that at retraingaugeio.
I do have some concerns aboutmy fellow designers and what
(49:34):
will happen when we getautomated, and so I want to be
able to nurture and growawareness of what tools and
constraints might be out there.
So that's retraingaugeio.
I think I name dropped thedoagaugeio, the dead on arrival
of what happens when you'rewithin this large sort of
(49:54):
enterprise design and acceptancecycle.
It's like how do you start tomitigate the risks of something,
um, becoming DOA, uh, and soyou could find that there, or
else just find me on LinkedInand I'd love to start the
conversation and figure out whatyou're working on and how I
might be of help.
Speaker 1 (50:09):
I love it.
So you know, uh, we talked alot about requirements gathering
and everything today.
You know, I guess, uh, justjust to remind everybody,
requirements gathering is notbrainstorming in Word and it's
not pulling everyone together ina room and talking about
previous tools and what theywant in the future tools.
So business processes really doneed to lead and tools need to
follow and be implemented toautomate those processes in a
(50:32):
proper way.
So IPX does that and Nick doesthat, so we'd be happy to help
with any advice anyone needs asthey're approaching the next
digital transformation withintheir business.
All right, thanks to everyoneso much, and we'll talk to you
guys next time.
Thank you for tuning in today.
Don't forget to subscribe andreview the show and for more
information on IPX, visitIPXHQcom.