Designing a user interface is, you’d might think, just a matter deciding what buttons and controls are on the screen and what happens when you press them.
That’s not incorrect, but there’s usually a little bit more to it than that. To design a product’s user interface effectively, you have to think through and decide on all of the following:
- What tasks and activities can the user perform with the application?
- How does the interaction proceed for each task? What steps and actions does the user perform and what steps and actions does the product perform?
- What is the overall visual style or appearance of the application? (For example, what will the basic page template or screen layouts look like, and what fonts, colors, iconography, and branding will be used?)
- What “places” are there in the application? “Places” could be pages in a web application, screens and dialogs in a desktop or mobile application, or even levels or locations in a game.
- How does the user navigate between the places (if applicable)?
- How will each “place” look? What controls and objects are available, how are they arranged, and how can they be manipulated or activated?
- What happens when the user activates or manipulates the controls and objects? What behavior is performed?
- What events does the application have to deal with that aren’t triggered by the user? (For example, do regularly-scheduled events occur? Does the application react to information arriving from another system?)
- What data or content does the application store, manage, and present? How is it presented or represented on the screen?
- What names or labels do you use to refer to all the things (data elements, objects, controls) in your application? How are the places, controls, and menus labelled?
- When errors occur, how is the user informed of the situation, and what opportunities are there for recovery?
- Are there different roles or classifications of users? What is each role allowed or not allowed to do?
- How will users get assistance when they’re unsure of how to use the application?
- How will you help new users figure out how the application works and how to get their tasks done?
Thinking through these issues isn’t enough, though. Since you’re probably working in a team, you’ll have to communicate your designs and intentions to the team members who will build and test the product. This communication can take the form of formal design documents and specifications, or prototypes and mockups, or perhaps even just face-to-face communication in front of a whiteboard.
And you need to be sure that what you design is feasible within the constraints of your project: It has to be implementable using your technical framework, it must be implementable with the skills of the team members available, the performance must be acceptable, and so on. Can the project team build the product at a reasonable cost and within a reasonable timeframe? And if the product is being marketed (as opposed to being a one-off custom project for a client), will the product sell enough copies to be profitable?
How do you figure out all of this? To start, you need to understand who will be using the product, and what they want and need. You’ll need to do this at the beginning of the project, and you’ll need to continually research and improve your understanding of your users as the project progresses, as these user requirements can often change.
We should note two things:
- Not all of the things in the above list may necessarily be done by one single designer! In most project teams, multiple people in different roles will take responsibility for different tasks. Examples of roles include product managers, business analysts, information architects, user interface or UX designers, usability specialists, developers, and so on. If your product is being developed for a particular niche or industry, such as banking or insurance or air traffic control, specialists with knowledge and experience in that domain will also play a key role in defining the product. Some organizations refer to these domain specialists as Subject Matter Experts, or SMEs.
- The above list, being focused on designing the user-facing part of a product, is not a complete list of all the things that need to be decided and designed for a software product. It excludes all of the technical design work, for instance. As since products are built by project teams, the project and its processes need to be planned and managed, and while this is usually considered a management task, there is no reason why this planning should not be approach with a design mindset as well.
