BMP 10 banner logo

LinkedIn Buyers Meeting Point procurement Kelly Barner twitter Buyers Meeting Point procurement Kelly Barner scribd Buyers Meeting Point procurement Kelly Barneryoutube Buyers Meeting Point procurement Kelly BarnerAdobeStock podcasticon

Revolution from within: Cutting-edge software is more than a pretty UI

AdobeStock SearchIn our recent whitepaper, Behavioral Patterns at the Heart of Procurement Software Design (click here if you missed out on reading it), we discussed the visual cues that are critical to successful procurement software adoption. The interesting thing about those cues is that while most people would recognize them all, few people outside of the field of ux design would have been able to name them on their own. Part of what makes these design features so important is that they have become so ubiquitous – from enterprise to consumer software – that we’re not supposed to have to think about them. There is an evolution of design constantly taking place around us, and if that evolution matches our own development as users, we don’t even notice it.

The same is true with software architecture. Given that no user interface can mask truly faulty software functionality, the same care and consideration has to be given to the structural elements in a solution. There are design elements working ‘under the hood’ of successful software that you can’t list and may not know about, but definitely can’t live without. More importantly, they are not static. The architecture of adaptive, progressive software is changing all the time in response to user feedback and the advancing capabilities of supportive technologies.

Sometimes the changes in structural capabilities outpace the behaviors of the people using the software. In these cases, designers have to carefully balance the need to support new ways of thinking and interacting without removing the traditional way of doing things until the majority of users are ready to make the shift. Most functionality ends up in the virtual boneyard eventually (remember our example of the legacy disk icon in the whitepaper?). It takes someone with a fresh perspective to continually review the elements of a solution to identify the ones that are on their way out as opposed to making assumptions about how people interact with the solution in the course of their work.

Perhaps these user changes will lead to the next class of extinct functionality?

No one prints anything anymore.

Beyond wanting to be kind to the trees, paper reports and documents become stale so quickly that they often don’t get printed in the first place. Why would you take information offline? Why print when you can pull up data or analytics in real time during a meeting on your phone. There is no need to sever data from its live source when it can be refreshed and manipulated in real time to support better decision making.

From a design standpoint, there is a lot of rendering and formatting required to print or save a view or set of information as a PDF. At some point, there will no longer be demand for this functionality and it will be removed from the design – probably to be replaced by some new sharing and collaboration supporting functionality.

‘Search’ is the New ‘View’

When you’re looking for a piece of information in a large set, how do you go about it? Do you select a portal page that presents you with lists of things to sort and choose from? Maybe at one time you did, but there is a better chance today that you just look for the search box to quickly query for what you need.

To support that change in habit, software has to have the right technical searching capabilities as well as ranking logic that ensures the returns from a search are relevant and match what users expect to see in their results. Search may be search, but it requires quite a bit of domain expertise to ensure that the results of those searches are in line with the job the user is trying to do.

Why load when you can slide?

Not even the software configuration process is immune from shifting user expectations and technical changes. ‘Back in the day’ the configuration and acceptance process had many stages and was a slow (painful) process. Moving from a conference room pilot that may have employed smoke and a mirror or two, to a sandbox, to a user acceptance installation, to the production site took a lot of time and many people because each was a separate instance of the software.

Today, the same software can move from conference room to sandbox to user acceptance to production. And while it’s not exactly a ‘slide’ from one status to the next, there is a lot more continuity and a lot less manual work to be done. In addition, every iteration is equally hands-on for procurement, significantly compressing the time required end to end and reducing the likelihood of mistaken or regressed configuration settings. And because the user team can immediately be far more involved, formal training and instruction are replaced by a more natural discovery process.

For procurement users, most of these changes happen gradually enough that they pass unnoticed. Can you pinpoint the last time you used a standalone calculator rather than reaching for your smartphone? Of course not. Nor should you have to if smartphone app designers are tapped into how people interact with their devices.

The same is true for procurement software architecture. If a design team is aligned with the views and habits of their users, they move functionality forward at the right pace. There are some elements being phased out, some in full use, and others on the leading edge of what people are moving towards. To make that possible, there must always be newer functionality in the software waiting to be discovered and put to use.

From a user perspective, think about your own use of procurement software. What percent of the available functionality do you use on a regular basis? When was the last time you took it upon yourself to try newer functionality? Just as architects and designers need to be open to changes in their user base, users have a responsibility to keep their eyes open for new and better ways of completing their work. A beautiful UI can’t mask flawed functionality, and users that are unwilling to fully engage with their software will never leverage its full potential. 

 

HP SMARTbyGEP

The success of any technology depends on how easy it is to implement and use. A software with powerful, comprehensive functionality but complex and difficult to use can rarely drive the expected efficiency and business results. Smart by GEP is pioneering example of what the user experience in the latest generation of procurement software can be.

SMART by GEP is as powerful and capability rich as it is easy to use. Powerful, complex, fully functional procurement software that is as any consumer product, with an intuitive, attractive interface and a rewarding user experience.

More Articles

BMP 10 banner logo

0
Shares