One of the best books I've read, a structured, extensive and elaborate explanation of why web animations are important, ho**spoiler alert** Review
One of the best books I've read, a structured, extensive and elaborate explanation of why web animations are important, how to get buy-in and easily include them in your development process.
There isn't a single trace of programming code here, what you'll find is a breakdown of the different types of animation, how to test their impact, the effects on the user cognitive flow, how cartoonists influenced UI design and web animation, how to keep pragmatic, design for accessibility and how to combine knowledge of the human vision, perception and reaction time to create animations that add context and delight.
Notes
Intro
- We use "web app" to refer to sites that are more than just plain HTML. * For sites that look, feel, serve and perform as well as an app, animation is an essential tool. - Animation is not just something decorative to be included at the end of the project if there's some budget left over. * It creates experiences that go beyond mere linked documents. * Immerses users in the illusion of life. * Generates user confidence and trust with as much strength as a professional logo.
Human Perception and Animation
- Human vision: * The "where system": detects motion. * The "what system": detects form (morph) and colour. - Avoid cut-based animation, which works on cinematography but not on the web. * Animation should add context to seemingly disconnected elements and events. ^ And offload this context to the visual cortex, reducing cognitive load, increasing perceived speed. - Animation makes elements relationships clear, so users don't spend time thinking what just happened but thinking what to do next. - Tweens: in-between animation states. * Cuts in the UI make the brain do the in-betweening. - Sudden changes could distract users from the task at hand. - Cone of vision: human eye is more sensitive to colour changes in the centre (things users are directly looking at), and to movement in the edges. * Edges pick up almost no colour changes and just trigger an eye move signal. - Change blindness: when you don't notice a change when looking at a familiar thing or returning to a familiar room.
Patterns and Purpose
- 5 types of animation: * Transitions * Supplements: bring stuff on or off the page without changing location or user's task. * Feedback * Demonstrations: show, don't tell, can explain stuff to users, rather than having them read through a manual. * Decorative: purely aesthetics, do not convey new information, separate ordinary from extraordinary. - Don't fall in the trap of only implementing delighters that just reinforce branding and don't improve cognitive flow. - Wordy descriptions can indicate something being told, demonstration could be better.
Anatomy of a Web Animation
- Easing: * Acceleration: good for system initiated animation, to not startle users. * Deceleration: good for user initiated, makes UI feel responsive and snappy. * Speeding up - slowing down: interaction models, when moving an element toward another. * Linear: good for fades or colour change. * Bouncing. - Humans take 200-300ms to react to visual changes like clicking on a just enabled button. - It takes 70-700ms for the human eye to move. * Shorter animations near the centre of the cone of vision are better, 70-200ms. ^ While longer toward the edges, 300-700ms. - Changing colour on hover might be too slow over 100ms and moving something across the page below 300ms might be too fast, test to see what feels right. - When working on an animation for long, it may feel faster than it really is. - Tokenise animation durations and timing functions in style-guides in order to standardise animations across the site.
Communicating Animation
- Storyboards can help quantify element animations, by describing what, how and why things animate. - Animatics: videos of storyboards with audio tracks of actors reading their lines and the soundtracks. * Try Adobe After Effects or PrincipleForMac. - Try Framer for UI prototyping. - Generate buy-in: * Add animations to the style-guide. * Show side-by-side prototypes to stakeholders showing the site with and without them.
Best Practices and other Educated Guesses
- The fact that people notice and praise your animations, might be a red flag, they're spending cognitive power on them, the opposite of what you want. * You want animation to provide context, and only be noticed when you want to attract users attention, like demonstrative animation. - Keep consistency, if an element entrance is animated, the exit should be as well. - Avoid FOULS: flashes of unloaded/ing states. * Use Facebook Shimmer or spinners in place of loading images. - Adding motion blur (smear of motion) can help fast movements register better at low frame rates, makes the retina see smoother motion. * Try fading the object in the middle of its trajectory and back again at the end to give the impression that it moved so fast as to not register. - The Web Animations API would help you provide users with a way of speed up or slow down site-wide animations. - Be aware of time warps: time passing faster or slower for some people. - Animation can cause seizures. * Trigger vestibular disorders: problems regarding human vision and balance....more
Good insight on an interesting topic, a bit redundant but still good content. If you've some experience in the industry, some concepts will Review
Good insight on an interesting topic, a bit redundant but still good content. If you've some experience in the industry, some concepts will be somewhat clear by now like the importance of getting buy-in or the intricacies of coordinating work and communication between product teams within a company.
There are many references to great articles through out the book that I'd like to read next, would've liked to have them as an aggregated list at the end like a bibliography.
Notes
Vignette levels: - 1st * 2nd ^ 3rd
Design Systems
- Functional patterns generally have an HTML basis while perceptual ones a CSS basis. - An effective design language bridges the gap between the system image and the assumed user model. - Design systems are a combination of patterns and practices.
Design Principles
- Vague: "make it clear" * Practical: only one number one priority, what do you want your users to do first? - Vague: "make it simple" * Practical: make it unbreakable, make sure it's designed for exploration and impossible to mis-tap. - Vague: "make it useful" * Practical: start with the needs, do research, analyse data, don't make assumptions.
Functional Patterns
- Can be seen as the nouns and verbs of a sentence. - When creating a component, each part has to have a purpose, i.e.: in a card component, we may want the title to tell what the card is about, the image to have a quick preview and draw attention, the description to allow easy card scanning. - Patterns change/evolve, behaviours stay. - Don't try to design the most impressive header forgetting what the header component is for and how it affects the user journey. * Don't loose the connection between user behaviours and the patterns to encourage those. - UI Inventory by Brad Frost: great way to modularise interfaces, you end you with a collection of parts grouped in categories. * Run inventory every few months. - When defining a pattern, start with it's purpose, not what it is. * To broaden potential its use cases, try calling it with a verb, not a noun. * If you have a promotional module, if you call it Image Header or Course Promoter, you may be restricting its use to a particular context. ^ Better to name it after an action (behaviour) like Promote/Discover a Course, Encourage people to join, etc. - Tweaking a module (like reducing font size) to allow a use case where we want the content to be smaller or not push another element out of view, might be the wrong call. * Maybe we're using the wrong patterns which aren't robust enough for the content behaviours.
Perceptual Patterns
- Use personas to come up with a list of them. * You can use ambience if personas are hard to come up with, i.e., what ambience suits you branding traits more? - Come up with a 5-7 list of branding traits. * Like fun but not childish, informal but not sloppy, powerful but simple, etc. * These traits are brought to life in the UI through tone of voice, visuals, interactions, sounds. - Techniques to assess patterns. * Mood boards: loose way of grouping related style elements together like on Pinterest. * Style tiles and element collage are more high fidelity options. * Don't force consistency every time, it can lead to a generic and rigid branding, there's a difference between consistency and uniformity. - If you introduce a new element or pattern in one place, it may not feel as part of the brand or disconnected until you add it to other parts of the site. - Some patterns should be used sparingly in order to keep the brand focus. * Like using too much of a colour or a triangle shapes when the brand uses squares.
Shared Language
- Patterns should connect through a shared language. - Name things based on purpose not based on what they look. * Or how users call them, which forces engineers to get a user perspective. - Try keeping a glossary as well.
Parameters of your System
- Strict <-> Loose - Modular <-> Integrated - Centralised <-> Distributed - Strict pattern libraries may benefit bigger teams or companies that would like to provide precise, predictable and consistent outputs. * Loose libraries are more flexible by encouraging more exploration, design acumen and sensitivity to context; and may not have the need to thoroughly document every pattern. ^ Even though, clear, comprehensive and compelling documentation is fundamental for this type of systems in order to keep a solid foundation. - Pattern library sketches and naming convention should always be in sync with its code counterpart. - Modular systems can create more overhead while making parts reusable; are suited for designs that need to scale and evolve, repeated elements, teams working concurrently. - Integrated systems are suited for one-offs like ad campaigns and fewer repeating parts. - Don't sacrifice UX or potential impact for the sake of reusability. - Design system organisation can be centralised (owned by a team) or distributed.
Planning and Practicalities
- Time and money is saved on reusing, you're not rebuilding the same button component every time. - Easier site wide changes. - Faster product launch: prototyping a new page out of a pattern library is usually a matter of days, a new design can take weeks. - Brand unity at scale: you don't end up with different parts of the site not looking like part of the brand.
Systemising Functional Patterns
- Look at the main screens of the site, try to break them down into behaviours, group elements by purpose, draw patterns. - Put stuff on a specificity scale, the more specific the less reusable it can be. - Think about potential changes, if I change module A, do I want the change in other places? * Some modules might look similar but we may decide to treat them differently.
Systemising Perceptual Patterns
- Voice and tone. * Direct, positive, encouraging. * Friendly but reserved; "well done!", rather than "wohoo, you're a superstar!" * Elements of humour; "we're hatching something new" - Colour. * Primarily white colour palette with pink accents. * Pink to blue gradient (celebration). - Shapes. * Mostly square and occasionally circular. * 1 px border, square icons. - Typography. * Mostly large type face with focus on readability. * High contrast, large headings in relation to body. - Animations * Small to no movement. * Pink to blue subtly hover, opacity, gradual colour change....more
Great usability book which does live up to the hype. Quick, easy and fun read. I'd say the chapter about mobile doesn't provide as much value as the rGreat usability book which does live up to the hype. Quick, easy and fun read. I'd say the chapter about mobile doesn't provide as much value as the rest but I suppose mobile dev was still on an early stage at the time of writing.
Highlights:
- Follow conventions.
- Try to stay consistent but choose clarity over consistency.
- As users, we're always in a hurry.
- We don't read web pages, we scan them, so format content to support scanning.
- We don't just scan an entire page, consider all the available options and choose the most optimal one, we just click on the first thing that resembles what we're looking for, if we misguess and end up in the wrong page, we're just one or two clicks to the back button away from the starting point. It's even more fun to risk guessing it wrong than to thoroughly think about an optimal choice cause we may as well get a pleasant surprise.
- We don't stop and figure out how things work, we muddle through and often use a site in different ways than what it was intended for.
- Happy talk and instructions must die.
- "It doesn't matter how many times I have to click, as long as each click is a mindless, unambiguous choice."
- Websites are missing some of the cues we rely on to measure space, like they've no sense of scale, that is, we don't really know how big a site is, is it 1k or 10k pages?, it's one of the reasons why visited links display in a different colour, to give us some idea of how much ground we've covered.
- When walking around a store you have a sense of direction and location, you sort of know where you physically are, there's no such physicality on a website, which makes bookmarks (stored personal shortcuts) important. As well as home pages, which act as a North Star, a way to reset and get a fresh start to navigate around the site.
- Navigation reveals content.
- There's no such thing as an average user.
- Don't fall in the trap of thinking most users like what you like.
- Don't ask the question: should we use a pull-down menu or another component?, instead ask if that pull-down with those items, in that context, with that wording, on that page, it's a great experience for most users of the site.
- Focus groups are not usability testing, the former is about a small group of people seating around a table to talk about things like their opinion about products, it helps in determining what the audience wants, needs and likes, in the abstract. Sort of a sampling of user's feelings and opinions. While the latter is about watching a single person at a time use something (an app, prototype, sketch, etc), asking her to perform typical tasks so you can find out if your product works and how to improve it.
- To focus groups you bring questions, to usability testing you bring tasks. The former should be performed as part of the planning phase, before design and development so you can find out if your value proposition is attractive. While usability testing should be used throughout the entire process.
- If doing usability testing yourself, try to keep it simple to 3 users or less and do it like once a month. It sounds like too few users but don't worry about finding every problem in a session anyway since you can find more problems in a single morning than you can fix in a month so just focus on finding the most serious usability problems.
- You could have users test competitors sites to get an idea of what works and what doesn't without having to build anything first.
- To focus on main problems ignore "kayak" problems: sometimes users will think for a moment, kind of like a kayak deviating and getting back on course, as long as it happens quickly, if the user's second guess about where to find things is always right, that's good enough....more
- Good design is based in discoverability and**spoiler alert** -----
Notes
...
Legend:
Vignette levels:
- 1st * 2nd ^ 3rd
1) The Psychology of Everyday Things
- Good design is based in discoverability and understanding. - 5 principles of interaction: * Affordances: relationship between the system/device and the user, system capabilities regarding a specific user. * Signifiers: signals, cues, hints; for when affordances aren't clear. * Constraints. * Mappings: usually between signifiers and affordances. * Feedback. ^ Affordances sometimes are also signifiers. * Conceptual model: the combination of the above principles in action, the user journey that creates the narrative of how the system should be used, e.g.: icons in a computer desktop create the conceptual model of organisation by files and folders, even though it's all stored as 1s and 0s. * Bad design lead users to construct the wrong conceptual model.
2) The Psychology of Everyday Actions
- Once something is mastered, is performed almost in autopilot, only specially difficult or unexpected situations need conscious attention. - Human thought is mostly subconscious, since we're only aware of a small subset, we fool ourselves into thinking most of them are conscious. * Which means we often don't know what we'll say do, say, think, until we've done it. - Thought and emotion cannot be separated. - Cognition provides understanding: emotion value judgments. A human without a working emotional system has difficulty making choices. A human without a cognitive system is dysfunctional. - Positive emotional state: good for creativity, too much and it prevents focus not getting things done due to too many random thoughts. - Negative emotional state: good for focusing on one task, too much and it creates a narrow point of view. - Three levels of processing: * Visceral: fight or flight, startle reflex for novel, unexpected events, fast responses completely subconscious. ^ This is where style matters, by triggering mellow, pleasant sensations, and has noting to do with how usable the system is. * Behavioural: learned skills, triggered by situations matching known patterns. * Reflective: home of conscious cognition. The others are subconscious and fast, this one is not. Develops deep understanding. - Eliminate the term 'human error', instead, talk about communication and interaction. - When people understand what has happened, what state the system is in, what actions are available, they can perform their activities more efficiently. - Systems should provide feedback and feedforward (what can I do next?).
3) Knowledge in the Head and in the World
- Precise behaviour can be derived from imprecise knowledge because: many times great precision is not required and there's natural constraints in objects, as the finite ways a device can be assembled, or lifted. * Hence, behaviour can be guided by a combination of knowledge in the head and in the world. - People can even organise their environment to support behaviour. * Non-readers who can still perform jobs where reading is needed. * Or when we perform well on novel, confusion or unexpected situations. ^ It's one reason why people can function well in their environment but still be unable to describe what they do. - Once we learn to distinguish similar items by certain qualities, it's hard to distinguish new items with similar qualities as the old ones. * It's why people in the US struggled when a $1 coin with similar size as the quarter was introduced * In contrast, they don't struggle to distinguish the same size bills, since they've always been the same size, people have learned to not use size as a differentiator. - The apparent large number of decisions is largely reduced once constraints are applied. - To maximise the efficiency of working memory, it's best to present critical information in different sensory modalities as they seldom interfere with each other when getting distracted: sight, sound, haptic (touch, vibration), hearing, spacial location, gestures. - Procedural memory: how we do things, learned skills. * Hard to explain to others. - Declarative memory: factual information. - Sometimes precise information, even if technically correct, is not better than a good enough approximation, i.e. calculating the exact temperature with the F to C formula might be irrelevant if I just need to know if wearing a jacket or not. - When given a set of instructions about a system, and making mistakes related to, say, misremembering one step, users tend to not report them as system problems, blaming it instead to their own stupidity. Even if in poorly designed systems.
4) Knowing What to Do: Constraints, Discoverability, and Feedback
- Standards should reflect the psychological conceptual models, not the physical mechanics. - One way to overcome the fear of the new is to make it look like the old.
5) Human Error? No, Bad Design
- Physical limitations are well understood by designers, mental limitations are not. - Interruptions are a common reason for errors. * Time stress as well. - Stating 'human error' as the cause of a problem is shallow thinking. * Use the 'Five Whys' to uncover the real cause. - Two types of errors: * Slips: when a person intends to do one action but end up doing another one. ^ e.g. unbuckling your watch instead of the seatbelt when getting out of a car. * Mistakes: when the wrong goal is stablished or the wrong plan is formed. ^ i.e. You appropriately diagnosed the situation but decide upon the erroneous course of action. ^ Or you misdiagnose the situation because of erroneous or incomplete knowledge. - Avoid procedures that have identical opening steps but then diverge. * Users might fall prey of capture slips, specially the experienced ones. * Design sequences different from the start. - Checklists a great for preventing errors in complex multistep situations with many interruptions. * They work better when two people work on them as a team, one reading the items, another executing them. * If instead, one person executes, and later a second one reviews the items, may cause the first one to rush things thinking any errors would be caught, but the same biases affect the reviewer. - One paradox of groups: adding more people to check a task makes it less likely to be done right. - In hindsight, events seem logical and predictable, foresight is difficult. - Multitasking accounts for a severe degradation of performance, increased errors and lack of both quality and efficiency. - Design the system as to precent errors on one level to leak to other levels. - Provide 'undo' to common errors. - Don't allow irreversible changes to be made too easy. - Organisations should implement resilience engineering, and treat safety as a core value.
6) Design Thinking
- Don't start looking for solutions until you determine what's the real problem. * Take the original problem stated to you as a suggestion, not a final statement. - Design research is about what people need and how they'll used the product. - Market research is about what people will buy and how they make purchasing decisions. - Activity centred design can be thought as an enhancement to HCD, like a camera or a car which is designed for a specific activity rather that a specific set of users, requiring everyone to learn a set of skills in order to use it. - People will tolerate complexity and learning something new as long as it feels appropriate. - Complexity is good, it is confusion that is bad.
7) Design in the World of Business
- Avoid adding new features to an already well designed product due to: * Some users asking for more functionality. * Sales dropping. * Competitors adding more features. - It is this attempt to match the competition that causes products to to be the same. - Don't compare features to the competition to determine where you are weak, compare them to see where you are strong and continue to grow that set of features stronger....more
Great book for understanding user behaviours and the reasoning behind user decisions, all based on the basics of human psycology.
The authors explain wGreat book for understanding user behaviours and the reasoning behind user decisions, all based on the basics of human psycology.
The authors explain why some companies succeed while others providing similar products do not. The book main topic is about how to keep users engaged and coming back to your product by implementing what they call the Hook Model....more
Loading...
