The UX Design Must Fit the Customer

A positive user experience is the goal of every software design project, but what it means depends on the customer. There isn’t a one-size-fits-all positive UX. An approach which is ideal for one user base can be insulting or bewildering to a different group. The right UX for a product depends on the customer’s business needs, the way the software will be used, and the user base.

The Varieties of User Experience

The first question is “What’s it for?” What business purpose will the software serve? Is the aim to build brand awareness? To make immediate sales? To improve understanding and awareness of what the business does? The developer needs to know in order to come up with the right appearance, workflows, and features.

The next question is “Who is it for?” If employees will use it day in and day out, that calls for one approach. If casual visitors just use it now and then, it’s a different matter. Even “casual visitors” can vary a lot. They might be shoppers with no unusual skills or specialists with definite ideas of what they want.

One more question: “Where will it be used?” Will most of the usage come from desktop or mobile devices? Will it be used for field operations or in the calmer atmosphere of a home or office? Responsive design lets the same software cover different types of devices, but it’s not an answer to everything. The difference is more than just screen size.

Understanding the Customer

No product ever starts with all the requirements being crystal clear. Even the customer doesn’t necessarily know the best approach. It’s a matter of trying things, making mistakes, and fixing them. The developer needs to listen to the customer and be flexible.

Drawing up a full design, diving into the implementation, and surfacing months later with a product doesn’t work. It takes interaction. Prototypes of minimum viable products help the customer to see what works and what doesn’t. Changes from the original design are inevitable, and they make the product better. An approach that looked good on paper may be a disaster when people try to use it.

The First Impression

The user’s first view of an application needs to give a positive impression, or it will be an uphill battle. Should it look serious or exciting? Should the colors be muted or gaudy? Is the first impression going to say “easy to use” or “full of features”? It’s all a matter of the business purpose and the audience.

A sense of excitement is often the key, but not always. For a gaming site, it’s essential. A travel site promoting serene getaways needs a calmer approach. An “exciting” Web application for a funeral parlor? Not a good idea.

The choice of first impression will affect the amount of material presented on the first page, the tone of the introductory message, the color scheme, the use of animation, and the controls used. Sometimes the best starting point is a splash page that does nothing but reassure the user this is the right place. In other cases, the initial page should get right down to business, highlighting products and offering options.

The Choice of Features

A lot of software suffers from feature overload. Adding capabilities sounds like a good thing, so why not do it? But every added feature complicates the user experience. What’s more important, having a powerful application or one that isn’t frightening? The answer isn’t the same for every case.

Features that don’t expand the application’s capabilities but just provide more ways to do the same thing aren’t always a great idea. Multiple ways to reach a goal can be a good thing, so the users can work the way they like. However, piling on options can bewilder the user. There needs to be a justification that outweighs the risk of confusion.

Pushing features out of the main workflow can help. Users who want a straightforward path can ignore them, and power users can take advantage of them. The users who want the bells and whistles need a way to discover them that doesn’t clutter the workflow too much. A discreet “Options” button or menu can accomplish that. For complex applications, preference settings that enable or disable features may be a more effective approach.

Designing the UX for the User

Who’s the typical user of an application going to be? Rocket scientists want a different UX from generalists. Employees using an application in their jobs have different needs from visitors browsing out of curiosity. People who use an app every day can deal with the learning curve. One-time visitors don’t want to.

An application which takes hours to learn isn’t necessarily bad, if it will let a professional do a better job. However, it could drive casual users away. This may not be a problem if casual users aren’t a significant part of the market. However, making the app usable only after intent study could drive a lot of people away.

What seems to be a single market isn’t strictly uniform. If the product is for a niche group, the UX needs to be right for it. Again, the business purpose drives the design. For example, streaming sites that optimize their UX for hearing popular songs strike dissonant chords with classical music fans, who have a different set of expectations.

The Creation of the UX

Both the customer and the developer have to enter the software creation process with an open mind. What worked in a previous situation may be all wrong for a new project. What looks good in a mockup could be frustrating for actual users. Experimentation and feedback are vital to achieving a positive user experience.

Smart developers don’t start a project assuming they already know what the UX should be like. They look at the needs of the customer, and that ultimately means the needs of the user. They ask what the effort is aiming for. If they do everything right, they deliver a product which is just right for the customer, the user, and the purpose.

Who We Are

At Restless Labs we have spent a significant part of the past decades offering digital consulting services to companies in a variety of industries - with a specialization in custom software solutions and Salesforce implementations.

For more information about how we can help you, contact us today and discover what awesome things we can build together.

Brad Bisinger Principal Consultant