Honestly, I find myself in 100% agreement with AV’s thoughts
regarding path analysis. As he suggests – and as I’ve discovered in my own
experience – the web is an incredibly dynamic place. Most often, there are a
myriad of ways a customer might arrive at a landing page, find an item they’re
looking for, or come to discover a certain piece of information. Usually, the
paths we (as developers) envision the customer “following” become warped, (or
are totally different) than what we were anticipating.
In my view, the web isn’t a place where you can simply work
the user over and develop a conditioned response – we’re not Pavlovian dogs,
after all. :-P
There are a couple situations where – as AV suggests – that
path analysis might prove useful (i.e. during a structured checkout process, or
through a page set with a structured end). In these instances, one can see
where the process is effective and efficient, and where it might “drop-off,” or
need work.
GMI more often uses path (process) analysis offline. I use
it everyday in my line of work designing workflows for automation processes,
making sure that the automation system follows an exact path, from end-to-end.
Online, though, GMI could use path analysis when having
customers take a survey about their website experience (to see if they get
fatigued or if they actually complete the survey), or we could use it to ensure
that the customer support process performs as expected.
In the end, I feel that path analysis provides some concrete
advantages when the process is a closed, end-to-end process (i.e. a survey) in
making sure that the expected end result is achieved. However, using path
analysis to try to structure a website user down a certain path seems a
complete waste of time to me – as the web is far too dynamic to attempt to
elicit a conditioned response from a statistically significant number of users.
No comments:
Post a Comment