- slides
- Collaboration (between designers and developers is VERY IMPORTANT)
- Set expectations right
- choose right process for the right job
- people
- try to push them a bit further, but stay in the comfort zones
- shift design deliverables to code
style tiles
- can be good or bad depending on team
examples of bad design:
- Terms and Conditions: is 'No' even an option? Why present it in the first place?
- HSBC example: 'you clicked too fast!' (LOL)
** Small tweaks can make a HUGE difference ** ** Choose your (copy) WORDS wisely ** ** Margins, paddings, line height (aligning is important) **
-
Thai airlines example: too many small problems add up and create a really bad design
-
Quality of code matters as much
-
Framework/Themes: Out of the box clutter
-
Testing is important (using mobile devices)
PERFORMANCE:
- 'You can only be as fast as design allows' - Ian Feather
- 3-5s is actually already good
- faster than 3s, involves quite some work
- Images (the big evil)
- Imageoptim App (2MB -> 70kb)
- Render blocking CSS/JS
- Loading assets (every request in
<head>delays page load) - optimise critical rendering path
- minify
- tools:
- webpagetest.com
- pingdom
- google pagespeed
- YSlow
- perf tooling today
- perf rocks
- perf school
- packing app: tripit?
- something designed or likely to be discarded after use
- dont fall in love w your ideas
- dont be afraid to start over
- fall in love w your problem (attack it in every way possible)
-
job is not to defend your solutions
-
best practices do not always work out of the box
-
Shipping is not the finish line
-
the product itself can pivot
-
Reshoots arent always a bad sign
-
enter the infinite stage of iteration
- functional -> reliable -> usable -> pleasurable
- redesigning vs. realigning
- redesign: major design changes
- realign: tiny, fast tweaks that theoreticaally vast improve the process
-
Jump cut
- people have a hard time extrapolating after a jump cut
- no animation
-
In-betweening (tweening)
- what just happened?
- by eliminating the sudden visual changes, animation lessents the chance that the user is surprised/confused
- cognitive load often has a cost that rivals page load cost
-
Capturing Attention
- research: animate motion does indeed capture visual attention
- animacy: how "alive" something appears to be
- animation to help reinforce the information in a page
-
animation is a visual representation of a rate of change over time
-
stateful transitions
- change from one state to another
- one page to another
- when a user changes tasks
-
supplemental animations
- animate secondary information
- can be easily abused
- when new information appears
-
causal effects
- hover effects
- something that tells the user that something is going to change or is changing
- when a user interacts with a page or something else
-
decorative animations
- dont add new information
- add embelishment
-
not strict categories (stateful transition can be decorative as well)
-
-
key poses ("keys")
- two important poses that can be in-betweened
-
Does the animation reinforace at least two of these?
- causality
- feedback
- location (reinforce where they are)
- progression (scrollbar shows progression down the page)
- transition
- physics (reinforce natural laws in an unnatural environment)
-
best practices
- short and sweet
- three timeframes for user attention
- 250-300 ms sweet spot for many animations (can still be tweaked)
- but not too fast
- faster != better (50ms - there's no point to animating)
- be invisible
- if people notice it enough, animation might be too visible and can be tedious over time
- install a kill switch
- there are people who don't like animation (vestibular disorder(?))
- use a notice (to disable the animation)
- Ask first (option for full animation, reduce or disable)
- Change settings
- animate deliberately or not at all
- half-done animation often causes more harm than good
- respect the user's cone of vision
- find your project's key frames
- short and sweet
-
canvas is good for games, but not for UI design
- it's like an img tag where you try to change the pixels
-
data = better decisions
-
having a lot of data != having good design
-
3 layers of good design
- great technique (technically good)
- relevance (good for users)
- viable
-
technology is power, power is neutral
-
common misuses of data in research:
- no backbone
- dont know why you're gathering data
- continue to make decisions without using data
- why are we gathering feedback?
- no backbone
-
listening to what users say <-- bad?!
- FIGURE OUT WHAT THEY MEAN, not what they say
- solve the reason behind the suggestion, not the suggestion itself
- PROBE
- why did he say that?
-
creativity is problem solving
-
bias (dont ask if it looks good, ask what you can improve)
-
strategically "be yourself"
-
design isnt just about you. the products you make for other people arent about you
-
all about intent (what you're using the data for)
-
have a backbone
- be sure why you're looking for data
-
listening to what users say <-- bad?!
- FIGURE OUT WHAT THEY MEAN, not what they say
-
sometimes dont be yourself when gathering feedback (no bias)
-
have people challenge you
- dont think what it actually is, but what its function is
- example, he made a player card for an NFL player, but it can be reused as a PBA player card or even a car information card
-
What is an interface made of?
- we're not designing pages anymore, we're designing systems of components
-
framework potential pitfalls
- one size fits all
- lookalike issues
- bloat
- might not do everything you need
- subscribe to someone elses structure, naming conventions
-
benefits of front end styleguides
** PROS **
- promotes consistency
- easier to test
- better workflow
- creates a shared vocabulary
- useful reference
- future-friendly foundation
** CONS **
- time consuming to create
- treated as a separate project
- often too abstract
- seend only as a developer/designer tool
- often created after a project launches
- lacking a clear methodology
-
Components of atomic design
** Atoms ** (abstract)
- not useful by themselves, but a reference
- label
- input
- button
** Molecules **
- search form molecule
- label input button
- product card
** Organism **
- same 'molecule' repeated over and over again
- product grid made up of product cards
** Templates ** ** Pages ** (concrete)
** Pattern lab is NOT these **
-
UI Framework
-
Language, library, style, workflow dependent
-
incredibly rigid
-
Set expectations
-
Gathering
-
interface inventory
- typecast - tool to compare fonts
- style tiles
- element collages
-
collaboration and communication trump process
-
"When you're finished changing, you're finished" - Benjamin Franklin