UX Design of Commercial Software

Technology becomes outdated but improvements to organizational practice last

There seems to be little written on UX design for commercial-off-the-shelf software. This is surprising, as so much of UX design work is associated with a commercial software product; as the number of commercial systems grow exponentially, and their costs are lower relative to building your own software platform, there are few projects for which a commercial software system would not be available.

It’s true that working on an already built product is not as exciting as building something brand new; but for the UX designer, the challenge from both a management and design perspective can be daunting. The UX design requirements can also be just as great for a new product, as companies often seek to use commercial software as a base from which to build a very customized experience that meets their own business context. Given this, these projects are often even more complex than creating new products: the added element of working with a software vendor creates another satellite of relationship. If UX design is mostly about communication, working with vendor supplied software adds a communicative complexity that is worth understanding.

Projects as Learning Experiences

In software development, models like the Capability Maturity Model are used to measure the ability of a software development team to deliver good, usable software.

Levels of Maturity in the Capability Maturity Model

• At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

• At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

• At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

• At the managed level, an organization monitors and controls its own processes through data collection and analysis.

• At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization’s particular needs.

The point of this model is that companies should strive for greater and greater maturity, and understand where they are at within the given spectrum. The best way to move towards greater maturity is through project work.

Projects, of course, have a primary goal of delivering a great product; the underlying result, though, is that the practice of working on a product should help a company learn something new, to become more capable. Perhaps the project requires rethinking how users experience external systems; perhaps the project requires learning a new programming language, or thinking about data in a new way; it’s rare, indeed, for some outcome like this not to emerge. Approaching a project, an organization learns what skills it may be lacking, how processes are not quite a good fit given a new direction for the organization. This learning experience is as essential as the product itself, and they are so connected it could be concluded that the quality of the product relates closely to the learning experience.

Vendor Culture

There is a tendency to divorce the idea of organizational growth from the idea of creating products, and this tendency is perhaps increased when it comes to vendor supplied software. Some organizations believe that choosing vendor software, and relying on vendor contractors, is a shortcut to developing sustainable software practices.

However, many of the design-level decisions that need to be made for vendor software require a strong internal team (including UX designers) who can determine user requirements and user needs. Without that, some key sources of software project failure are likely to happen: “developing the wrong functions, developing the wrong user interface, ‘gold-plating’, a continuing stream of changes in requirements, shortfalls in externally furnished components, shortfalls in externally performed tasks and performance shortfalls” (Sumner, Mary. Risk factors in enterprise-wide/ERP projects, 2000).

This could also derive from how the vendor views its relationship with the client. Some software vendors view the relationship as collaborative; understanding that the organization may be new to the software platform, they are willing to invest time in training and education. This would make organizational sense; a company that understands the software is most likely to benefit the most, and express greater satisfaction.

There is a perceived cost, however, for this for many vendors: an organization that learns the software is likely going to become independent of the software vendor, indeed, will feel inspired to be. If a vendor relies on consulting fees to maximize profit, the vendor may not want to empower clients, or they may want to make them feel like they can’t live without them. The term for this is vendor lock in; not only is the company unable to exist independent of consultants, they are also unable to be nimble enough to change software if the future requires it, at least not without a high cost.

Of course, in an ideal world, most vendors would be collaborative and empowering; however, this is not the typical situation. This puts additional pressure on an in-house UX designer who is required to work with the vendor.

UX Design in the Dark

It is rare for a company to accept vendor supplied software as it is, out of the box. Often, organizational demands and contexts mean that customization is required. Customization has an important UX component; the design of the interface, the interactions, are being uniquely defined, and that often requires UX research, planning user flows, and designing interfaces. It can also be the source of greatest conflict.

“Many companies ‘go-to-war’ with a software package”, Mary Sumner writes, “and try to make it meet their business process requirements, only to lead the way to cost overuns and project failure in some cases.” Aligning business practices can be less risky (and less prone to major time and expense), however there is a natural tendency to want the software to be everything, and to even fix organizational problems that are deeper than software. This tendency is often fueled by the vendors themselves.

During the sales process, some vendors will oversell what the software is capable of doing or what can be customized; this may not be intentional: many in sales are not as aware of what the software can do, or what can be customized, and may have been told very simple language to hide complexity from them (i.e., our software can do anything!). This can create conflict later on, as the technical consultants from the vendor who come in after the sale is complete become more conservative about what can be done (or, what can be done without additional costs).

This mystery extends when a in-house developer or designer begins to prepare to work on the project. When looking for information on what design patterns exist in the standard software, or information on interface options, or underlying technologies, one often finds this information is non-existent. The “missing manual” is the surest sign that a vendor does not have a collaborative culture with clients; they want to keep information about how the software works, the underlying technologies, and design patterns confidential.

This results in a reliance on the software vendor, and this path ultimately does not improve the organization: at the best, the organization can only perform at the level of achievement as long as they continue a (costly) relationship with a software vendor, who may be more interested in using the newest technology available as opposed to designing what is needed (i.e., gold-plating); at the worst, the vendor will (of course) gladly take the organization’s money and deliver something less than optimal.

This is why developing internal capabilities at managing software practices is so important; it assures the organization it can express what it wants, can validate the delivered products, and can be in control of the project. Commercial software is almost always the best option for an organization: internally built systems become legacy systems quickly, are difficult to maintain over time, and are difficult to develop in an environment in which technology is an eco-system, in which third-party applications and internal applications need to interact. The process by which it is implemented matters, particularly if their is a need to fix project management practices or organizational practices; these are things no vendor or software can really fix alone. When the wrapping finally comes off the shiny new software package, an organization wants the promised efficiency or better performance as a result of the expense: wether that happens is less a factor of the vendor, and more a factor of how open to organizational change the organization is.