Based on a podcast (link here) by Karen McGrane and Ethan Marcotte, featuring Fidelity’s Steve Turbek, SVP, User Experience Design and Brian Hurley, SVP, Fidelity.com Platform Experience. Originally posted Sept. 1, 2014.
Fidelity is redefining their company with a customer/user-centric focus, rather than a product- and feature-centric focus
MAIN TAKEAWAYS
Take all user feedback seriously and learn from it–don’t react defensively. Iterate, iterate, iterate–only your users can lead you the best possible solution
You need to have facts (user research, testing and feedback), faith (in your carefully chosen methods) and fortitude (accept that the experience will start out with lower satisfaction rates than your current site and that it takes time and iterations to get consistently high rates)
——————————————
Fidelity realized switching to responsive design was key to their future success:
- Most users are multi-platform so the platforms all need to offer the related experiences
- There aren’t experiences which are primarily accessed on a single type of device–customers experience all of the major pages on all types of devices depending on their own context–so you can’t privilege one device over another
- Treat all devices equally and fix the gaps rather than say, nobody’s gonna do this on a phone. Because they will!
- Accessibility with screen readers etc is a company priority so those requirements were integrated from the start and not slapped on at the end
- Devices will continue to proliferate and creating native apps for all would be difficult–and expensive
So how did Fidelity move over to a responsive platform? (Luckily they had recently updated and streamlined their content strategy so that wasn’t a large factor.)
Going in, they weren’t sure how to scope such a large new project. Taking their base assumptions and budget allocation, they:
- Started from scratch–no attempt to update the current site
- Started with an MVP beta version–a fairly robust one since that’s what was minimally necessary for customers already using their site–which customers could opt to use and then opt out to the old site if desired
- This opt in/out functionality was considerable extra work but it allowed them to get feedback and iterate live with small, constantly evolving groups of customers
- Committed to release with the best possible MVP experience as the “go live” target–not a specific date
- The first release took 3 months longer then initially estimated and cost 10-20% more than initially estimated–not surprising and not bad given that the initial scope was developed with so many unknowns
- Made some large changes to significant core structures based on user feedback–something the beta environment gave them to flexibility to discover while it was still relatively easy to change without effecting most users
- Studied Gmail and Yahoo Mail’s relaunches–both relied on user feedback to keep the focus on what the users wanted from the redesign (not the product owner) and to evolve the site without completely confusing existing customers
- Iterated on getting the experience right for the 10 most-trafficked pages before iterating on less-trafficked sections
- Worked with their native app counterparts to keep the experience fairly uniform across web and native apps
- Found that many users would perform complex financial transactions on phone–at a much higher rate than expected
- Prioritized development based on user volume, user intent and business value
- Linked to “hidden gems” of great (but previously undiscovered) functionality on the top 10 pages
- Learned that holding on to some key parts of the old design so users could orient themselves in the new responsive experience didn’t pan out–something stakeholders struggled to let go of
- Found they needed front-end developers who could design and code simultaneously–making sure an experience renders well across all devices from the very beginning
- In a different project, they found mid-range Android devices in particular had scrolling issues–which required retooling parts of the core experience when they throught development was finished
- This helped in terms of speed, quality and overall cost to the responsive project
- Continuous integration also gave them confidence that the end products would be great experiences
- Accepted that the integration of the new site and old site’s content meant that sometimes content labels, voice etc won’t match until the older parts get updated
- Worked closely with the legal team due to all the regulations–sometimes the design really has to respond first to the legal regulations
- Fidelity is actually working with the legislative bodies to change the rules so that they work better in a responsive context
After the responsive site launched, development continues:
- They continuously test with users every 2 weeks
- Sometimes small in-person qualitative tests and sometimes large scale online quantitative tests involving 500 users
- They continuously iterate and progressively release updates
- They introduce new capabilities in a beta environment to elicit user feedback and validate that the capabilities are wanted and needed before changing the main site
How did they measure success for the new responsive site?
- Keep in mind that a beta launch has limited functionality by design and therefore isn’t going to be well received by users who need the missing functionalities. So sheer quantity of negative feedback isn’t a fair measurement—negative feedback to missing functionalities is a point of learning rather than a measure of success
- They elicited ratings from users
- They looked at things like NPS (net promoter score)
- They had a variety of business metrics (trading volumes, accounts opened etc)
