Given that IT projects typically include a design phase, why is it then that so many enterprise applications look like they were designed by someone intent on making their users’ lives as awkward as possible?
In technical terms the design phase refers to the creation of a logical structure for the system, however from the users perspective, design is usually all about look and feel. There is no doubt that a well-designed technical architecture will enable a great system, but it also needs to look good and function beautifully for everyone who lives and works with it.
One of the things that we love to focus on at Walpole Partnership is the question of user experience (UX). An often-overlooked challenge with the Configure, Price, Quote (CPQ) systems that we implement is how to make the system a pleasure for a wide variety of users. So how do we go about doing this?
Consider the cast of characters:
Salespeople need an unobtrusive system that enhances their chance of selling. They need a quick answer to the questions “What have I got to sell?” and “How much can I sell it for?” Salespeople are usually an expensive resource so you want them spending their time on selling rather than on data entry.
A CPQ system should ask a salesperson to enter data only when they are the sole source of this information, or the best-placed to capture it, e.g. information about a client’s needs, specific product features or service levels which are all required to make salespeople efficient. Other details (e.g. exact customer addresses, current contracts or detailed service descriptions) may be provided more cost-effectively elsewhere or better still, integrated and automated. Perhaps the information does have to be provided by sales, but maybe not at the same time that a speculative quote is being generated. Speed is of the essence. Quick answers, rapid approvals and automatic generation of professional documentation are required to make salespeople efficient.
Technical advisory teams need details which can be the critical difference between profitable and loss-making deals, or indeed between achievable and impossible ones. If your CPQ system involves expert contributions to a deal, then you need to clearly think through what they need to provide and when. Which of their choices will impact the financials of the deal? Which affect the deliverability and which are just about dotting ‘i’s and crossing ‘t’s? Remember that these teams may have different drivers and that a range of personality types may be involved. A good CPQ design provides a workflow and UX that takes this into account.
Approvers also need detail, which is obvious, but we also need to ask “What information is truly needed to make a decision?” Some data is absolutely necessary (e.g. margin for an FD), and some is contextual information like a customer sector. We don’t need to give every piece of information to every approver: these people are often in senior positions and are deluged daily with data. Instead, present the optimum amount of data, structured with clarity to make their touchpoint with your system a pleasure. Failure to do so can have dire consequences – we have seen systems grind to a halt because approvers are delaying making their decisions and quotes are left in limbo.
Think through the logic of approval chains. Should these be serial or parallel? In too many organisations we see a standoff where no approver will invest the time to analyse a deal until all other approvals are in place. Their valid fear is that they will waste time scrutinising a quote, only for another department to reject it.
Back-Office / Order Entry teams must be able to get to get an organisation working and ensure that business happens, so we need to build systems that are efficient for them too. This is true whether you have integration to downstream Enterprise Resource Planning (ERP) / back-office systems or if youre in organisations where everything is manual.
Perhaps there is more tolerance within these teams of the functional over the aesthetic, but often this is due to a legacy of 20th Century systems where capabilities were limited. We like to challenge this norm. Back-office UX can be the hardest to get right, so we always try to allow sufficient time and resource to plan for this.
Thousands of transactions can flow through a CPQ system daily and back-office teams need to be able to get to the information they need to keep transactions flowing. They should be able to populate deal details easily when they have access to this information. Remember that teams in the back-office need to be enabled by a system, not to be fighting against it.
So, having considered the designing of CPQ systems with its users in mind, we now turn to focusing on the most important stakeholder, the customer. We will look at their point of view and conclude with some thoughts on how to plan for success in UX design.
Customers are the most important community in so many ways. If you’re using CPQ to provide your customers with a portal or guided selling screens you MUST realise the importance of their experience. They are not your salespeople. They are not your technical specialists. They are definitely not your back-office! The flows, the screens, the questions you must present to them may be the most different of all.
Prototyping and testing response to UX is the single most critical activity you can undertake, and you must talk to customers before you commit a design to build. Even the early engagement and the exposure of your thought process is a brand touchpoint, so plan it, choose your audience wisely and take the time to get it right.
If you’re trying to use CPQ in a B2C environment, the stakes are higher still, and the brand and bulletproof UX demands may be too challenging for most off-the-shelf CPQ systems. If this is the case our typical recommendation is to invest in a specialist e-Commerce solution, but ensure you can integrate your CPQ system with it. This way you can share your product catalogue and use the CPQ configuration engine to offer complex products in a smooth and simple way.
Summary
We always recommend that our clients clearly identify UX design in their plans, schedule it early and review it throughout a project. If you expect to tidy things up at the end then be aware that this can easily eat into the project contingency time set aside to fix other problems.
It’s wise to plan for post go-live enhancements because User Acceptance Testing is often limited to functional requirements. Engage your users early and often; perhaps launch a pilot site for key users to test. This is easier in agile projects, but use wireframes and mockups if not, and listen to what users tell you. Understand the day-to-day lives of users and spend time with them, but be aware that when you describe a system to a user, the picture in their mind may differ greatly from yours.
Our belief is that it is important to have a system with solid core functionality that works well for users. This kind of system will give benefits to users straight away and will be actively used and liked. Users will ask for more because they like it, rather than ask for fixes to get back to their expectations.
Which kind of system gets further investment? One that works and is loved, or one that is a result of a project that has overrun, under-delivered and is liked by no-one?
“Design must reflect the practical and aesthetic in business but above all good design must primarily serve people.”
Thomas J. Watson, Chairman and CEO of IBM.
