Published on Sunday, 31 Mar, 2013
So, third party systems eh? We love them for saving us time, for meaning we don’t have to focus our allocated hours, budgets, and effort on things that we know someone has already successfully built. Hands up anyone who has ever used a third party payment processing gateway, booking/registration system, or retail solution? That’s most of you then, apart from you there. Yes, you. The one who wants to build everything from scratch every time because then it’s done your way and you get off on the control. And that’s the trade-off that we face – our lives made easier in return for letting someone else run the show.
As part of my job, I encounter a lot of third party systems. Very often these are already in place to due to existing contracts and relationships, and it’s my responsibility to work out how best to stitch together the new site to be created and the third party requirement. Sometimes I’m also brought in with a view to being able to improve the third party system in conjunction with a new development. If this is the case, I very often start by performing a technical audit, sometimes called an expert review. Others have a different view on the terminology.
These reviews are helpful in determining the status of the current system, including any dependencies, requirements, or limitations. They help us better understand the way the third party works, and as such be able to better integrate it seamlessly into whatever we’re creating. They can also help us easily pick out areas which need improvement, whether this is technically, visually, or with the overall user experience.
Having reviewed a number of systems recently, one thing is apparent. The web community at large may be falling over themselves to advocate the use of responsive web design, however third parties are lagging severely behind. This needs to change.
Your client is redeveloping their website. You’ve meticulously planned everything for the new site, the client is thrilled with your work to date, and you’re all looking forward to champagne and slaps on the back at the launch party when you can instagram a photo of yourself stood beside a banner saying that conversions are up 10,000%. There’s only one slight problem. To get those conversions the visitor has to jump off your site, your beautiful, strategically planned responsive site, and on to a third party ecommerce partner’s site. Everyone’s tried their best to avoid thinking about this bit. It’s not your responsibility, right?
Your users flock to the site on launch day, fed by your shiny new social campaign, and are driven by the dynamically personalised calls to action to visit the shop. They do so in their droves. And one by one you watch the cross-site analytics that you’d battled to introduce show frustration after frustration.
Users frolic on your site. They’re consuming the content they want, how they want. Then they make the jump, and they’re fed content how someone else wants. Someone else who happens to want them to consume it as if it had been built in 1999. No consideration for screen sizes, no consideration for whether they can use form controls effectively, maybe some consideration that it works but not whether it works enjoyably.
At this critical point, users are frustrated, you’re frustrated, your client is frustrated, and as a result the relationship with the third party may sour. Everyone loses.
In recent times I’ve worked with a wide variety of systems, each of which were prerequisites and non-negotiable. In each instance they had to be shoehorned into an otherwise responsive experience. In the majority of cases the user is simply taken to a ‘full’ site experience. The problem here is that this is firstly very jarring, the experience is no longer seamless, but in the worst case certain functionality may be inaccessible to users on devices because they just haven’t been thought about full stop. Other instances tried to cater for mobile, but went down a dedicated site route because a RWD approach was “too difficult” to implement. This again leads to a jarring experience, with tablet users potentially being served a huge, stretched interface due to bad decisions or detection, or users losing functionality that they’d have access to on a desktop. It also raises the usual questions of maintainability long-term. In the worst case I have experienced, users were at one point prompted to carry out an action on the desktop site before they could proceed on mobile. You can imagine my thoughts on that one.
Many people who work on systems like these would love to do mobile improvement but are faced with being employed by slow-moving, risk-averse organisations, or those who simply don’t see enough “benefit” from RWD yet to justify large changes to their core system. Some however were built in the past, worked on by people whose skills have similarly stagnated, and as such have stayed in the past ever since, with little intention to change.
Many systems work on the basis where improvements are not organic, and are instead done on an ad-hoc basis when one client requests something in particular. Development is funded by the client (whether they know it or not), and changes can then be rolled out to others. As such I think we’ll start seeing a responsive focus, eventually, but only when requests reach a critical point, or when businesses realise they are losing out.
Back in time:
Data migration strategy
Forward in time:
Making visitor sign-in simple
Sally is the lead consultant and founder of Records Sound the Same, helping people with digital transformation. She's also a speaker, coder, gamer, author, and jasmine tea fiend.