User testing at Intelligent Environments, part 2

Author: Alan Brown

In the second of our articles about user testing we look at the five challenges of user testing white label banking software.

In my first article on the subject of user testing I set out why usability is a critical success factor for software and how we ensure that usability is embedded in our digital banking products at Intelligent Environments.

One of the biggest challenges we face in ensuring the usability of our products is for white label products – software that’s branded and customised for each customer and then placed into the hands of users and supported by those customers.

In this article I set out the five biggest challenges of usability for white label products and how we’ve overcome them at IE.

1. Getting close to users  

Finding ways to put ideas, prototypes and products into the hands of users and observing how those users respond is the bedrock of usability best practice. The easier it is to reach your customers, the easier it is to test new things.

However, in a white label environment there’s often no opportunity for direct contact between suppliers and users. This reduces our choice of testing techniques and in particular it reduces our ability to do perform A/B testing.

To overcome this we run joint user tests with clients and hold regular reviews to ensure that the feedback coming into their support and customer service teams, and from their own in-house user testing if they do any, finds its way to us.  

2. Ensuring usability during customisation

Our core product is user tested from the start but before users see it it’s branded, and often heavily customised, for each of our clients. We have to ensure that the core product is usable before it’s customised and that it remains usable as it’s transformed according to each client’s priorities.

This means that there will always be two distinct teams involved in producing the end product – a product team that develops a universal core and a product delivery team of programmers, analysts and project managers that works on behalf of each client.

To keep those teams well aligned they are all housed under one roof, here at Intelligent Environments, and the staff are rotated though the different team so they understand what it’s like to supply the core framework and what it’s like to consume it.

screen-shot-2014-12-22-at-095458_499x280

Screenshot taken from Interact demo video.

3. The digital banking user is not the buyer

White label products have two masters – the users who use the product and the organisations who buy and support them.

In theory these two masters ought to be aligned but in practice they often have different priorities. For example, organisations might place more emphasis on security and conversion rates whilst users want the speed, convenience and ease of use that might be sacrificed to get them.

There is simply no substitute for good communication and trust in this scenario. It’s our job to explain the business imperative of our usability choices but it’s also our job to listen and adapt if we need to.

4. Long feedback loops

Because our software is produced as a core that’s then tailored for each customer there can be a gap of several months between a new version of our core software leaving the development team and it reaching customers.

That long feedback loop means that our core team is well into development of the next version before customer comments start to trickle in.

We use three techniques to compensate for this; we do shared user testing with clients on their versions of our core so we can generate feedback before going live, customisation of the core is performed by delivery teams inside Intelligent Environments, and our prioritisation process operates on a short, three-month cycle.

5. Prioritising and developing the right software features

Usability starts with making good, user-centric choices about what features our developers should build into our core product. Because we don’t have direct access to customers or B2C product data this can be the biggest challenge of all.

Because of our long feedback loop it’s important that the company stays on its toes – so rather than plotting intractable, long-term road maps we review and adjust our development targets every quarter.

Our principle sources of intelligence and inspiration are competitor analysis, emerging technology, customers, prospects and technology partners.

Asking people what they want is a great source of ideas but nobody knows your products and market better than your own organisation so it’s important to develop ideas from within, even if nobody’s asking for them.

“If I had asked people what they wanted, they would have said faster horses.”

– Henry Ford

The content management functionality in Interact is a great example of this. It came about because we noticed that one of our clients was making regular, small changes to their mobile app.

Every time they changed the app, no matter how small the change was, they’d have to wait days whilst the new version made its way through Apple’s review process and users would have to download a fresh copy of the updated app.

Nobody asked for content management because there wasn’t anything broken – what was happening was orthodox app development – but by being close to our customers, listening and observing we realised it could be done an entirely different way.

19 Dec 2014

Author: Alan Brown

In the second of our articles about user testing we look at the five challenges of user testing white label banking software.

In my first article on the subject of user testing I set out why usability is a critical success factor for software and how we ensure that usability is embedded in our digital banking products at Intelligent Environments.

One of the biggest challenges we face in ensuring the usability of our products is for white label products – software that’s branded and customised for each customer and then placed into the hands of users and supported by those customers.

In this article I set out the five biggest challenges of usability for white label products and how we’ve overcome them at IE.

1. Getting close to users  

Finding ways to put ideas, prototypes and products into the hands of users and observing how those users respond is the bedrock of usability best practice. The easier it is to reach your customers, the easier it is to test new things.

However, in a white label environment there’s often no opportunity for direct contact between suppliers and users. This reduces our choice of testing techniques and in particular it reduces our ability to do perform A/B testing.

To overcome this we run joint user tests with clients and hold regular reviews to ensure that the feedback coming into their support and customer service teams, and from their own in-house user testing if they do any, finds its way to us.  

2. Ensuring usability during customisation

Our core product is user tested from the start but before users see it it’s branded, and often heavily customised, for each of our clients. We have to ensure that the core product is usable before it’s customised and that it remains usable as it’s transformed according to each client’s priorities.

This means that there will always be two distinct teams involved in producing the end product – a product team that develops a universal core and a product delivery team of programmers, analysts and project managers that works on behalf of each client.

To keep those teams well aligned they are all housed under one roof, here at Intelligent Environments, and the staff are rotated though the different team so they understand what it’s like to supply the core framework and what it’s like to consume it.

screen-shot-2014-12-22-at-095458_499x280

Screenshot taken from Interact demo video.

3. The digital banking user is not the buyer

White label products have two masters – the users who use the product and the organisations who buy and support them.

In theory these two masters ought to be aligned but in practice they often have different priorities. For example, organisations might place more emphasis on security and conversion rates whilst users want the speed, convenience and ease of use that might be sacrificed to get them.

There is simply no substitute for good communication and trust in this scenario. It’s our job to explain the business imperative of our usability choices but it’s also our job to listen and adapt if we need to.

4. Long feedback loops

Because our software is produced as a core that’s then tailored for each customer there can be a gap of several months between a new version of our core software leaving the development team and it reaching customers.

That long feedback loop means that our core team is well into development of the next version before customer comments start to trickle in.

We use three techniques to compensate for this; we do shared user testing with clients on their versions of our core so we can generate feedback before going live, customisation of the core is performed by delivery teams inside Intelligent Environments, and our prioritisation process operates on a short, three-month cycle.

5. Prioritising and developing the right software features

Usability starts with making good, user-centric choices about what features our developers should build into our core product. Because we don’t have direct access to customers or B2C product data this can be the biggest challenge of all.

Because of our long feedback loop it’s important that the company stays on its toes – so rather than plotting intractable, long-term road maps we review and adjust our development targets every quarter.

Our principle sources of intelligence and inspiration are competitor analysis, emerging technology, customers, prospects and technology partners.

Asking people what they want is a great source of ideas but nobody knows your products and market better than your own organisation so it’s important to develop ideas from within, even if nobody’s asking for them.

“If I had asked people what they wanted, they would have said faster horses.”

– Henry Ford

The content management functionality in Interact is a great example of this. It came about because we noticed that one of our clients was making regular, small changes to their mobile app.

Every time they changed the app, no matter how small the change was, they’d have to wait days whilst the new version made its way through Apple’s review process and users would have to download a fresh copy of the updated app.

Nobody asked for content management because there wasn’t anything broken – what was happening was orthodox app development – but by being close to our customers, listening and observing we realised it could be done an entirely different way.