In parts One and Two of this 3-part series we posed the question of how CPQ design affects people in different business functions in different ways and we took a deeper look at some of the key communities who we must consider. Now let’s take a look at the most valuable people, and then well conclude with some thoughts on how to plan for UX success.
Customers 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.
Mistakes in customer UX can be costly. We recommend stabilising an internal system first so the foundations are well built and then following up with the delivery of the customer portal. Allow some time for draft portal design at the same time as you design the internal system. This will ensure you don’t end up just bolting a portal onto an unsuitable platform.
There may be many other people to consider too partners, product managers, pricing analysts and many others too every organisation is different. To consider all users may seem like a complex approach, but remember even if business processes evolve and change (sometimes within the duration of a large project), human nature is a constant. The broad needs of each community rarely change over time, so design time invested on UX will always hold its value throughout a project.
We always recommend our clients plan for UX design and we prefer that it’s identified clearly and scheduled early and throughout a project. If you expect to tidy things up at the end then that time can easily turn into project contingency to fix other problems. Also, plan for enhancements post go-live because User Acceptance Testing rarely has the chance to cover UX testing. Engage your users early and often; perhaps launch a Beta 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 will differ greatly from yours.
“Design is not making beauty, beauty emerges from selection, affinities, integration, love.” Louis Kahn
Finally, we do understand that budgets and time mean that sometimes sacrifices and compromises must be made. At this point we urge you to think why you’re investing in this system in the first place. The best projects we see normally limit scope before they limit UX which is not always easy to justify to stakeholders. Our belief is that it is far better 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 a project that has overrun, under-delivered and is liked by no-one?
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” Antoine de Saint-Exupery
