User Interface Design - Applying the Principles PDF

User Interfaces How things get done… What is user interface and user experience? User interface (UI) is the name given to the design and implementation of the portion of the software that the user uses to control the program. This could be a set of command line switches, a text interface, a web-...

User Interfaces How things get done… What is user interface and user experience? User interface (UI) is the name given to the design and implementation of the portion of the software that the user uses to control the program. This could be a set of command line switches, a text interface, a web- based interface, etc. User experience (UX) is the term for the users’ total experience using the software. This includes their using the UI, but can include many other aspects, like performance of the system, ability to complete work easily, and their overall impression of the system. This is not about pretty pictures… Making user interfaces attractive is not bad or wrong. But it is not the first consideration. Usefulness is the most important concept in user interfaces. A pretty interface that doesn’t help the user get their tasks completed is bad UI. Making a good UI pretty is easy. Making a pretty UI good is hard.  Utility – can the UI solve the users needs? Usability – can the users learn the UI with little difficulty? Utility Desirability – do users Usability want to use your product? Desirability Aspirational – do users Aspirational feel great about your product? UI is an art form UI/UX is the intersection of humanity and technology. There is, unfortunately, no algorithm for this. But much like other art, there are “rules” – guidelines and principles that should be followed, unless you have a good reason not to.  Obvious is better Did you ever get to a door that you have to puzzle out how to open? Is that good design? The best design is one that fades into the background. Using it is obvious and easy. Principle 1 - Familiarity Leverage terms and concepts that the user is familiar with. This can include business specific terms, common controls that they have seen in other applications and more. Apple and Microsoft both have User Interface Guidelines for this reason – if all applications work the same way, users can learn new applications easily. Principle 2 – Minimal Surprise When the system surprises the user, it is usually a jarring, scary, unpleasant experience. Many people fear computers to begin with. Consider the stresses a user faces – fear for their job, of looking foolish, of losing work, of being yelled at, of being blamed. If the system doesn’t surprise them, it becomes a trustworthy ally. But be careful – over explaining doesn’t negate surprise. People often don’t read large blocks of Principle 3 - Consistency Similar things should work similarly. This logically follows from Familiarity and Minimal Surprise. If a user has become familiar with part of the system, minimal surprise implies that the rest of the system works similarly. MacOS/Windows menu bars are a good example of consistency. Principle 4 - Recoverability If a user makes a mistake, it should be as recoverable as possible. Undo in applications and “trash can/recycle bin” functionality in the operating system are good examples of recoverability. Often, this requires both UI and “backend” functionality – this is a good indicator that it is a UX issue. Principle 5 – User Diversity Many systems will have more than one type of user. Rather than making the system complex and trying to serve many masters, it may make sense to have different user interfaces to support the different users. As systems change, user diversity may increase or decrease; good practice is to re-evaluate user interfaces periodically as requirements change. Principle 6 - Feedback Timely feedback is critical to user experience. When a user clicks a button, the visual feedback of the button pressing and releasing lets the user know that the command was received. Deleted items disappearing, altered items visually changing and added items appearing give the user comfort that the work was completed. Remember that users don’t like to read – visual is better than textual. But remember familiarity – clarity trumps Principle 7 – Prevent Mistakes The system can help the user by preventing mistakes. If possible, don’t present options that are not valid. Disable controls that don’t make sense. If not possible, check the users input before accepting it. Hick’s “Law” The time to decide increases with the number and complexity of the choices. Consider reducing the number of decisions your application requires of the user. Some ideas – intelligent defaults, hiding less commonly used choices in a submenu, filtering and sorting information being shown. Some resources There are many, many resources online with UI ideas and patterns: https://ui-patterns.com/patterns https://web.stanford.edu/~mshanks/MichaelShanks/files/ 509554.pdf https://lawsofux.com/ https://designsystem.digital.gov/ https ://www.usability.gov/what-and-why/user-experience.html User Interface Design Applying the principles Design Process We start with a use scenario. This may come from use cases or user stories. What does the user want to do? What does the system need to do that? What is the logical workflow? Is there more than one? What information is necessary for each workflow? Metaphors and skeuomorphism If you are transitioning from an existing system, it might be more familiar to users if your system mirrors what they know. On the other hand, mirroring what they know might perpetuate the inefficiencies and problems of the existing system. Skeuomorphic – designed to mimic the real world. May or may not make sense for any given design. Example – Pizza Consider a pizza shop. One argument is that there should be 2 interfaces – one for employees who care strictly about fast, efficient “expert” entry and one interface for customers who need more “beginner” hand holding help. That means that we need two distinct workflows. Example: Pizza – Employee View  Example: Pizza – Customer View Notice: Images to show relative sizing Pricing “Feeds” to help customer decide Simpler, more friendly model  Pizza Example – Customer Adds Toppings Drag and drop makes this UI “fun” Images let the customer visualize the pizza Menu at the top means that the customer won’t have to scroll through an endless list Note that this application is partially a sales tool. That impacts our UI design. Credit: https://uxfol.io/project/046f6212/UX-UI-CASE- Think about interaction styles Web based and desktop apps are mouse and keyboard driven. Mobile apps are touch driven. The user will want, naturally, to interact with these differently. Future looking – think about voice interaction… Performance Matters (Sometimes) This is workflow specific. The employee at the pizza place needs to enter orders as fast as possible to clear the phone/in person queue. The customer ordering from their phone cares a lot less about speed. Think about these this when designing. Output Design Systems can have all sorts of output. This is one of the ways that a good system will be significantly better than an older system. For example, consider any receipt you have lying around. Chances are good that item names are abbreviated to save space. It isn’t easy to get a sum of a subset of the items that you bought. You can’t find out if an item is on sale now. You can’t see if an item has a recall. Scale your output Does the user care, at first glance about every detail? Probably not. What is the minimal subset of data that will probably solve the customer’s question? How, then, can we provide information to get more information? What format can we show the data to make it more “human”? Types of output Summary Report – the brief data Detail Report – exhaustive data Turnaround Report – becomes the input to another system Graphs – great for comparing several things to each other  Example: Interactive Receipt Summar y Detail Turn Around Think hard about output It’s very easy for us to dump data. Is that the best way for the end user to absorb and use that data, though? This very much depends on the audience. Accountants, scientists and “numbers people” love the raw data. Others, not so much. Think about data visualizations as a way to show patterns and trends. Be careful of colors – some of us are color blind. Story Boards Just like making a movie. A story board is a low-cost visualization of the finished product Could be hand drawn or on the computer The goal is to show workflow and to ensure that it meets the customers’ needs. Psychology of Story Boards Having something visual to look at goes a very long way toward helping the team and stakeholders think about the project. The closer to the finished product the story boards look, the more people critique things like colors and spacing Rougher story boards are faster, cheaper and keep people focused on workflow. Interface Structure Diagram When the UI has transitions between windows/screens/pages, it is important to build a diagram that shows how you can get from one page to another. We often build these as miniatures of the pages with arrows. More complex workflows might require loops, trees or other graph structures. Evaluation There are several ways to evaluate a story board: Heuristic – does this story board obey the principles of good UI design? Walk through – can I point to the story board and talk through using it? Interactive – with a computer-based story board and minimal code behind it, can I “use” the system? Formal Testing – same as interactive, but with real users Evaluation – who? The UI designer (much like a developer) should evaluate their own design. Similarly, though, they will also have blind spots toward their design. Have people evaluate your design who are not too shy to speak up. An adversarial process will yield better designs. Remember that changing story boards is cheap – that’s Iterate! What did your evaluation show you? Did you forget fields? Does the UI flow? Is it logical to use? Rework your design now, while it is cheap! A/B Testing You may come to a point in iteration when you aren’t sure which of two designs is better. A/B testing is a good way to deal with this, and the concept is very simple – show some people design “A” and some people design “B”. Measure which is more successful. What do you measure? It depends on what your goal is. It could be sales, it could be successful logins, etc. Write on it! Your user interface design is a written version of your thoughts about how the user interface should look. But just like still images from a movie are not sufficient to tell the plot and character development, still images of a user interface are not sufficient to document all of how your user interface is intended to work. You will need to add some annotations. Input Annotations Most any input field should have validations – code that does a preliminary check to see if the inputs are valid. Every input field has a purpose – for example - a destination in data storage, a deciding factor in what comes next, input to a calculation Annotate each input with validations and purpose Process Annotations Any action controls (buttons, links, etc.) should be annotated with their intended effect. Does the control take you to another screen? Does it run a validation? Insert a record into data storage? There can be multiple actions and even different paths (for example – passing validation can go to a different screen, failing validation can remain on the same screen but show a message). Output annotations If your user interface has an output field, annotate where the output came from. Is there an algorithm? Formula? Field from data storage? Constant message? Also adding the purpose of the output is valuable. Why are we writing all of this? You are thinking through the whole problem. You are documenting your thinking at a time. This is like a rehearsal for the actual code. This also give the business, developers and testers a common framework to consider. That seems like a lot… It is. But there are a lot of benefits from it, too… Remember that this is early in the SDLC. Changes are still cheap and easy. The more thoroughly we think and write, the easier the development process will be. This could in theory be done by a good business analyst.  Example – Create an account page What annotations can/should we have for this form? What is each field for? Where do we store it? What are the validations? When do we run them?  Example – Create an account page Name – Required. Stored in user.Name field. In the background, check to see if we can find a match and prompt the user “Found an account registered to {Name} with email {found email} – is this yours? If so, click here to login or here to reset the password.” Email – Required. stored in user.email field. In the background, look for exact matches and prompt the user: “Found an account with email {email}. Click here to  Example – Create an account page Phone Number – required field. Stored in user.Phone. Validate the field has 10 digits. Ignore parenthesis, dashes. Use “ValidatePhone” service call in the background to ensure that it is valid. New Username – stored in user.username field. In the background, look for exact matches and prompt the user: “This username is already in use. Please choose another.”  Example – Create an account page Passwords: Must be ten or more characters. Must have at least one: uppercase, lowercase, number, symbol. Retype field must match “Password” field. Check password against “haveIBeenPwned” list and notify the user if that password is on the list.  Example – Create an account page Create – send all of the fields to the server where all validations are repeated. Server will create the account, send the two- factor authentication code, send the welcome email, then redirect the user to the “Enter your two-factor code and email code” page. Cancel – if the form is empty, go directly to the home page. If not, ask the user if they really want to abandon. If so, go to Completed Result When we are done, we have the user portion of a complete design. Combine this with our ERD and we have about 2/3 of our design. The other portion of the design is the user stories/use cases.