Youre a Designer Whether You Like It or Not
•Télécharger en tant que KEY, PDF•
1 j'aime•392 vues
What the hell is "design?" Is it gradients and drop shadows on buttons? Is it the font you use in your app? Is it how you organize your living room? There's design in all these things but this is not design. Developers sometimes define "design" as "how it looks." But the features you choose to build and even the specific way in which you actually build it is all a part of design. You're a designer too. Great developers are able to understand the "why" behind designers' decisions. Conversely, great designers are builders themselves who realize what's feasible and impossible with the technology. There's smooth interplay between the two disciplines on the best teams. Design is a process by which you create something to be used by another person. In my talk I'll discuss some ways to tear down the physical and metaphorical wall that gets exists between designers and developers. When you empathize with designers on your team, you'll quickly be amazed how you both start building better products together.
Recommandé
Contenu connexe
En vedette
Dernier
Dernier (20)
Youre a Designer Whether You Like It or Not
- 1. You’re a DESIGNER Whether you like it or
- 6. WHO HERE WORKS WITH DESIGNERS? You’re a DESIGNER Whether you like it or not.
- 7. WHO CONSIDERS THEMSELVES A DESIGNER? You’re a DESIGNER Whether you like it or not.
- 8. YOU ARE A DESIGNER. You’re a DESIGNER Whether you like it or not.
- 10. Buy NOW!
- 11. Buy NOW!
- 12. WE MAKE STUFF PEOPLE USE. You’re a DESIGNER Whether you like it or not.
- 13. SO WHAT? WHY SHOULD I CARE? You’re a DESIGNER Whether you like it or not.
- 14. JOB OF TOMORROW: “DEVELOPIGNER?” You’re a DESIGNER Whether you like it or not.
- 15. Design is the application of intent— the opposite of happenstance, and an Robert L. Peters Designer
- 16. 5 THINGS TO COVER You’re a DESIGNER Whether you like it or not.
- 17. 5 THINGS TO COVER 1. You’ve got the wrong idea about design. You’re a DESIGNER Whether you like it or not.
- 18. 5 THINGS TO COVER 1. You’ve got the wrong idea about design. 2. Everyone has latent design skills. You’re a DESIGNER Whether you like it or not.
- 19. 5 THINGS TO COVER 1. You’ve got the wrong idea about design. 2. Everyone has latent design skills. 3. Communicating with designers. You’re a DESIGNER Whether you like it or not.
- 20. 5 THINGS TO COVER 1. You’ve got the wrong idea about design. 2. Everyone has latent design skills. 3. Communicating with designers. 4. Your design nitro boosters. You’re a DESIGNER Whether you like it or not.
- 21. 1. YOU’VE GOT THE WRONG IDEA ABOUT DESIGN You’re a DESIGNER Whether you like it or not.
- 22. 1. YOU’VE GOT THE WRONG IDEA ABOUT DESIGN You’re a DESIGNER Whether you like it or not.
- 25. 2. EVERYONE HAS LATENT DESIGN SKILLS You’re a DESIGNER Whether you like it or not.
- 30. Typical developer thinks: CRUDManager.CreateAdditionalAccount() Create Additional
- 36. “Developigner” thinks: If my interface was a person, it would say...
- 37. “Developigner” thinks: If my interface was a person, it would say... Start a savings account
- 38. 2. EVERYONE HAS LATENT DESIGN SKILLS You’re a DESIGNER Whether you like it or not.
- 39. 3. COMMUNICATING WITH DESIGNERS You’re a DESIGNER Whether you like it or not.
- 41. I don’t like how this looks. Said to a Designer By a Developer
- 42. I don’t I can’t get like how this this = thingy to looks. work. Said to a Designer Said to a Developer By a Developer By a Designer
- 43. Yeah we’re gonna need this [crazy thing] like yesterday...just do it this way instead, OK? Management “Swoop and Poop Strategy”
- 44. PROPOSING IDEAS & CRITIQUING DESIGNS You’re a DESIGNER Whether you like it or not.
- 45. “Well, I really like it when…”
- 46. “Well, I really like it when…”
- 47. PUSHING BACK ON UNREALISTIC DESIGNS You’re a DESIGNER Whether you like it or not.
- 51. 3. COMMUNICATING WITH DESIGNERS You’re a DESIGNER Whether you like it or not.
- 52. 4. YOUR DESIGN NITRO BOOSTERS You’re a DESIGNER Whether you like it or not.
- 53. PERFORMANCE You’re a DESIGNER Whether you like it or not.
- 54. PERFORMANCE You’re a DESIGNER Whether you like it or not.
- 55. SPEED MATTERS Amazon 4.3% drop in revenue per 100 ms delay caused a user. 1% drop in revenue. Mozilla Yahoo! Download page 2.2 400 ms delay caused a seconds faster increase of 5-9% decrease in traffic. 15.4% in downloads. Bing Google Maps 2 seconds delay caused a Reduced the file volume by 30% and observed a 30% increase in map You’re a DESIGNER Whether you like it or not.
- 56. “AUTOMAGIC” You’re a DESIGNER Whether you like it or not.
- 58. 5. DESIGN PATTERNS FOR INTERACTION You’re a DESIGNER Whether you like it or not.
- 61. Your
- 62. The World Your
- 63. The World Your “Forces”
- 64. Governments spend The World $2B annually on radiation safety equipment ** Your “Forces” Most sniffers High radiation requires have 3-terminal HASMAT suit and gloves connector **
- 71. 10 USABILITY HEURISTICS Visibility of system status Recognition rather than recall Match between system Flexibility and efficiency and the real world of use User control and Aesthetic and minimalist freedom design Consistency and Help users recognize, standards diagnose, and recover from errors Error prevention You’re a DESIGNER Whether you like it or not.
- 72. 10 USABILITY HEURISTICS Visibility of system status Recognition rather than recall Match between system Flexibility and efficiency and the real world of use User control and Aesthetic and minimalist freedom design Consistency and Help users recognize, standards diagnose, and recover from errors Error prevention You’re a DESIGNER Whether you like it or not.
- 73. VISIBILITY OF SYSTEM STATUS You’re a DESIGNER Whether you like it or not.
- 74. VISIBILITY OF SYSTEM STATUS Progress indicators You’re a DESIGNER Whether you like it or not.
- 75. VISIBILITY OF SYSTEM STATUS Progress indicators Live preview You’re a DESIGNER Whether you like it or not.
- 76. VISIBILITY OF SYSTEM STATUS Progress indicators Live preview Autocomplete / live search You’re a DESIGNER Whether you like it or not.
- 77. VISIBILITY OF SYSTEM STATUS Progress indicators Live preview Autocomplete / live search Periodic refresh You’re a DESIGNER Whether you like it or not.
- 82. BONUS: TACTIAL NUGGETS You’re a DESIGNER Whether you like it or not.
- 83. WORK AS CLOSE AS PHYSICALLY POSSIBLE You’re a DESIGNER Whether you like it or not.
- 84. TEACH THEM You’re a DESIGNER Whether you like it or not.
- 85. BE TAUGHT (YOU’RE HERE!) You’re a DESIGNER Whether you like it or not.
- 86. CREDIT & SOURCES “Designing with Forces” Ryan Singer http://vimeo.com/10875362 Notes on the Synthesis of Form Christopher Alexander “Clean Up Your Mess” Daniel Higginbotham http://visualmess.com You’re a DESIGNER Whether you like it or not.
- 87. CREDIT & SOURCES Designing Web Interfaces Bill Scott & Theresa Neil “Yahoo Design Pattern Library” Yahoo http://developer.yahoo.com/ypatterns/ “Design for Developers” Robby Ingebretsen http://bit.ly/hkHghf You’re a DESIGNER Whether you like it or not.
- 88. CREDIT & SOURCES “Anatomy of a Design Decision” Jared Spool http://vimeo.com/20881152 “Ten Usability Heuristics” Jakob Nielsen http://bit.ly/4eOWbN “First Principles of Interaction Design” Bruce Tognazzini http://bit.ly/4Cyrwu You’re a DESIGNER Whether you like it or not.
- 89. CREDIT & SOURCES High Performance Websites Steve Souders You’re a DESIGNER Whether you like it or not.
- 90. I READING You’re a DESIGNER Whether you like it or not.
- 91. I READING You’re a DESIGNER Whether you like it or not.
- 92. THANKS! @noluckmurphy You’re a DESIGNER Whether you like it or not.
Notes de l'éditeur
- Why it’s important dev/design speak language\nOnly non-code talk?\nProve my nerd pedigree.\n\n
- Geiger counter. Studied this in college. \nLoved tinkering and taking things apart growing up.\n
- Geiger counter. Studied this in college. \nLoved tinkering and taking things apart growing up.\n
- Geiger counter. Studied this in college. \nLoved tinkering and taking things apart growing up.\n
- The complexity of that amplifier \nHomework problem.\nFar as I got. Never went on to build circuits.\n
- Love math and algos. Am a builder.\nDidn’t go to design or art school--trained as an engineer.\nI want to know how things are built.\nHighly respect and admire the talents of engineers and devs.\n
- Doesn’t matter what kind\nvisual/graphic, "web designers," interaction/IA\n
- Not trying to get trained as a visual or interaction designer in a day. \n\nResources at end.\n\nBuild empathy for designers. Help you get them to do the same.\n\nMy Goal: Persuade and motivate you to do the deep dive.\n
- Thesis.\nNot semantics argument.\n“Designers” in my opinion share a philosophy that I hope to explore with you today.\nYou’re a creative problem solver who makes software for people to use\n--that’s design by definition.\n\n
- Not about Photoshop or Comic Sans\nHipster glasses, flannel shirts, skinny jeans.\nI’m asking you to recognize that design is more than skin deep.\nDev != prog. langs and IDEs\n\n
- Not about Photoshop or Comic Sans\nHipster glasses, flannel shirts, skinny jeans.\nI’m asking you to recognize that design is more than skin deep.\nDev != prog. langs and IDEs\n\n
- “Whether you like it not”...you can design by accident. \nLot of software companies do. Passive vs. Active.\n\nNo design culture so they just add features at random to keep their engineers busy.\nLack of hard/honest thought given to the actual people who use their stuff.\n\nThat’s the ultimate responsibility of any designer.\n
- If I still haven’t convinced you: 2 TRENDS\n\n1. Invisible technology is a competitive advantage.\n -- results from design thinking applied to the technology\n -- that takes design AND dev talent coming together\n\n2. Best products come from integrated design/development teams.\n -- you need to be able to work smoothly on those teams.\n
- Think of design+engineering grand slam companies. \nApple, BMW, Mint.com\n\nSXSW every company hiring.\n
- IMO, it’s crucial for the next several years in our industry to become design experts.\n\nif you take pleasure in the fact the code you write helps someone do their job better.\n\nYou’re in the right room because you are a designer. And I think you’ll like it.\n
- You can replace “designer” with “developer” here.\nPreaching to the choir when I say: “and designers should do the same for you.” \n
- You can replace “designer” with “developer” here.\nPreaching to the choir when I say: “and designers should do the same for you.” \n
- You can replace “designer” with “developer” here.\nPreaching to the choir when I say: “and designers should do the same for you.” \n
- You can replace “designer” with “developer” here.\nPreaching to the choir when I say: “and designers should do the same for you.” \n
- You can replace “designer” with “developer” here.\nPreaching to the choir when I say: “and designers should do the same for you.” \n
- There are shitty, pretentious designers (just as their are obnoxious socially inept devs) that give others a bad name\nThink it is superficial, but "necessary" -- like sugar coating or lipstick on a pig.\n\nComes down to different models and approaches to building: dev traditionally puts the tech and ‘machine’ first.\nTraditional design puts the end-user above all else.\n\nDifference between “designing” the process and designing for end use.\n\nDesign is holistic. That means everyone on my team needs to be educated about it.\n
- Here’s an example of how design is more important than just looks.\n\nDoes your grandmother know what a session is?\n\nThese things might not even register as a “bug” to a typical developer because “it works.”\nUndervalue the emotional impact a product (your interface) can have.\n\nHow it works and what it does are just as important.\n\n
- Set up visual heirarchy blur test.\n
- Easy trick for non-designers to “test” whether the most important things really stand out.\n\nWRITING NEXT\n
- Writing copy is interface design.\nEdit and refine the words. ROBOT VOICE.\nBeware Russian English.\n\nTF2\n
- Writing copy is interface design.\nEdit and refine the words. ROBOT VOICE.\nBeware Russian English.\n\nTF2\n
- Writing copy is interface design.\nEdit and refine the words. ROBOT VOICE.\nBeware Russian English.\n\nTF2\n
- lots of interfaces sound like the Heavy from Team Fortress 2 when you read the copy.\n[swipe]\nbetter to say: “Help ME capture THE point.”\n\nDevelopers just need to read their interfaces aloud more often to test for Russian English \n[SWIPE]\n\n
- lots of interfaces sound like the Heavy from Team Fortress 2 when you read the copy.\n[swipe]\nbetter to say: “Help ME capture THE point.”\n\nDevelopers just need to read their interfaces aloud more often to test for Russian English \n[SWIPE]\n\n
- Instead of coming at it from the perspective of “what the code does.”\n\nFriendly interfaces act like a helpful companion guiding you along the way.\n\n
- Instead of coming at it from the perspective of “what the code does.”\n\nFriendly interfaces act like a helpful companion guiding you along the way.\n\n
- Instead of coming at it from the perspective of “what the code does.”\n\nFriendly interfaces act like a helpful companion guiding you along the way.\n\n
- One of the last latent skills is noticing friction.\n\nTrain your brain to pinpoint the annoyances. Try and dig around it.\n\nCalled “Finding the pain.”\n\nCommunicating and articulating the pain with designers can be a challenge.\n\n
- Almost all problems communicating between des/dev comes from lack of context.\nUnderstanding WHY something is a problem guides you to the solution.\n\n[compare quotes]\n\n[then swoop and poop]\n\n\n
- Well great that doesn’t help me. My first question is why? What is the look keeping it from accomplishing?\n\nDid he read my instructions? I don’t understand how to solve this problem without more info.\n\nAlways WORK FROM BOTH SIDES to get to the root of the problem.\n
- Well great that doesn’t help me. My first question is why? What is the look keeping it from accomplishing?\n\nDid he read my instructions? I don’t understand how to solve this problem without more info.\n\nAlways WORK FROM BOTH SIDES to get to the root of the problem.\n
- Well great that doesn’t help me. My first question is why? What is the look keeping it from accomplishing?\n\nDid he read my instructions? I don’t understand how to solve this problem without more info.\n\nAlways WORK FROM BOTH SIDES to get to the root of the problem.\n
- Well great that doesn’t help me. My first question is why? What is the look keeping it from accomplishing?\n\nDid he read my instructions? I don’t understand how to solve this problem without more info.\n\nAlways WORK FROM BOTH SIDES to get to the root of the problem.\n
- Well great that doesn’t help me. My first question is why? What is the look keeping it from accomplishing?\n\nDid he read my instructions? I don’t understand how to solve this problem without more info.\n\nAlways WORK FROM BOTH SIDES to get to the root of the problem.\n
- Don't ask to build a bridge. Ask them to devise and build the best way across the river. \n\nSame for dev. *** KEY EMPATHY RALLYING POINT ***\n
- Key idea: devs aren’t users.\n
- Important point: You are not your users. Try to catch yourself saying “If I”\n\nQuestion how well the design meets the goal.\n\n
- Designer’s goal: \nDeliver the best possible experience THAT CAN BE REALIZED.\n
- Designer’s crazy complex cake.\n
- If implemented w/o pushback. Meh.\n\nHave you tried doing 4 chocolate layers in Pascal? It sucks...\n
- Better: determine the optimal thing together from the start.\n\nEssential to speak each others’ language clearly to do this.\n
- Both sides have their quirks but in the end we’re both trying to do the same thing:\n\nBuild a great product.\n\n
- 2 things that greatly enhance and influence a product’s design.\n\nPerformance\nAutomagic\n
- \n
- \n
- \n
- Companies have seen dramatic change in behavior with relatively small performance changes (both good and bad).\n\n
- \n
- Best compliment I can think to give to a dev/design team is to say their work is like magic.\n
- This is something software engineers can really sink their teeth into. There are a number of interface/interaction design pattern libraries.\n\nBefore I can show you and talk about some of the patterns, I want to show you that Geiger Counter again.\n\n[connect step by step back to GoF]\n
- Let’s think a moment about Geiger Counters.\n\nWhat features do they have? Why are they built the way they are?\n
- Your design. Everything about it.\nIt exists within the world at large. It interacts with people, other systems, it’s bought and sold on the market.\nAnd there are distinct FACTS about the world that influence the success of your design.\n\n
- Your design. Everything about it.\nIt exists within the world at large. It interacts with people, other systems, it’s bought and sold on the market.\nAnd there are distinct FACTS about the world that influence the success of your design.\n\n
- Your design. Everything about it.\nIt exists within the world at large. It interacts with people, other systems, it’s bought and sold on the market.\nAnd there are distinct FACTS about the world that influence the success of your design.\n\n
- Your design. Everything about it.\nIt exists within the world at large. It interacts with people, other systems, it’s bought and sold on the market.\nAnd there are distinct FACTS about the world that influence the success of your design.\n\n
- \n
- The best designs are “aware” of the facts it cares about and shows no signs of friction--the design considered and built for the facts it saw most important.\n\nThat’s the design litmus test: \nare there major friction points with the surrounding context??\n
- \n
- Influential book in traditional architecture that also influenced:\n
- Reusable solution templates to common problems.\n\nRead: not copy/paste code. Same for interface design patterns.\n
- \n
- Responsiveness, feedback, react immediately.\nJust spend 2 hours going through your entire app and look for little hiccups and points in time where it wouldn’t be immediately clear to your user what’s going on..\nYour list will be long but you can prioritize and fix. \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- CHECK TIME\n\nstart developing the language fluency and respect for nuance in the others' domain\nDOES NOT MEAN YOU NEED TO START MOCKING UP INTERFACES or 'DOING THE PHOTOSHOPZ'\n
- #1 piece of advice who’ve had success teaming engineers and designers:\nthey work in the same room.\n\nManamagement objects to this idea: "we need them (and you) to focus on 'your stuff'"\n\nNews flash: the only output that matters is the product you build, focus on doing what you're good at but augment it with shared understanding and you will grease the efficiency/productivity sled.\n
- Learning is not a zero-sum game: knowing and understanding design principles doesn't clog your tubes to be able to write a faster hashing algo.\n\nMarkup/code standards, commenting etiquette \nI AM A CODE CHAMELEON, I ADAPT TO USE WHATEVER SYNTAX IS NEAREST MY CHANGE\nGit/SVN etiquette\nBasic OO, inheritance, DRY, separating config from logic\nThings they can do to write faster apps (spriting, minify, limit requests, css3)\n
- If you want to learn a language you have to start hearing it, thinking about it, and speaking it.\n\nStart small. Do an internal off-the-grid project with a designer to improve something at your office--quick way to get people’s attention and more resources.\n\nAsk your designers “why” multiple times when they give feedback.\n
- \n
- \n
- \n
- \n
- \n
- \n
- If you liked this talk or want the hour of your life back, please let me know on Twitter. I’m not an annoying Tweeter and about 90% of my content is related to what I talked about today.\n