Youre a Designer Whether You Like It or Not

745 views

Published on

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.

Published in: Design
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
745
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
13
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Youre a Designer Whether You Like It or Not

    1. 1. You’re aDESIGNERWhether you like it or
    2. 2. WHO HEREWORKS WITHDESIGNERS?You’re aDESIGNERWhether you like it or not.
    3. 3. WHO CONSIDERSTHEMSELVES ADESIGNER?You’re aDESIGNERWhether you like it or not.
    4. 4. YOU ARE ADESIGNER.You’re aDESIGNERWhether you like it or not.
    5. 5. Buy NOW!
    6. 6. Buy NOW!
    7. 7. WE MAKESTUFF PEOPLE USE.You’re aDESIGNERWhether you like it or not.
    8. 8. SO WHAT? WHYSHOULD I CARE?You’re aDESIGNERWhether you like it or not.
    9. 9. JOB OFTOMORROW:“DEVELOPIGNER?”You’re aDESIGNERWhether you like it or not.
    10. 10. Design is theapplication of intent—the opposite ofhappenstance, and anRobert L. PetersDesigner
    11. 11. 5 THINGS TO COVERYou’re aDESIGNERWhether you like it or not.
    12. 12. 5 THINGS TO COVER1. You’ve got the wrong idea aboutdesign.You’re aDESIGNERWhether you like it or not.
    13. 13. 5 THINGS TO COVER1. You’ve got the wrong idea aboutdesign.2. Everyone has latent design skills.You’re aDESIGNERWhether you like it or not.
    14. 14. 5 THINGS TO COVER1. You’ve got the wrong idea aboutdesign.2. Everyone has latent design skills.3. Communicating with designers.You’re aDESIGNERWhether you like it or not.
    15. 15. 5 THINGS TO COVER1. You’ve got the wrong idea aboutdesign.2. Everyone has latent design skills.3. Communicating with designers.4. Your design nitro boosters.You’re aDESIGNERWhether you like it or not.
    16. 16. 1.YOU’VE GOT THEWRONG IDEAABOUT DESIGNYou’re aDESIGNERWhether you like it or not.
    17. 17. 1.YOU’VE GOT THEWRONG IDEAABOUT DESIGNYou’re aDESIGNERWhether you like it or not.
    18. 18. 2.EVERYONE HASLATENTDESIGN SKILLSYou’re aDESIGNERWhether you like it or not.
    19. 19. Typical developer thinks:
    20. 20. Typical developer thinks:CRUDManager.CreateAdditionalAccount()
    21. 21. Typical developer thinks:CRUDManager.CreateAdditionalAccount() Create Additional
    22. 22. “Developigner” thinks:
    23. 23. “Developigner” thinks:If my interface was a person, it would say...
    24. 24. “Developigner” thinks:If my interface was a person, it would say...Start a savings account
    25. 25. 2.EVERYONE HASLATENTDESIGN SKILLSYou’re aDESIGNERWhether you like it or not.
    26. 26. 3.COMMUNICATINGWITH DESIGNERSYou’re aDESIGNERWhether you like it or not.
    27. 27. I don’tlike how this looks. Said to a Designer By a Developer
    28. 28. I don’t I can’t getlike how this this = thingy to looks. work. Said to a Designer Said to a Developer By a Developer By a Designer
    29. 29. Yeah we’re gonna needthis [crazy thing] likeyesterday...just do itthis way instead, OK?Management“Swoop and Poop Strategy”
    30. 30. PROPOSING IDEAS& CRITIQUINGDESIGNSYou’re aDESIGNERWhether you like it or not.
    31. 31. “Well, I really like it when…”
    32. 32. “Well, I really like it when…”
    33. 33. PUSHING BACK ONUNREALISTICDESIGNSYou’re aDESIGNERWhether you like it or not.
    34. 34. 3.COMMUNICATINGWITH DESIGNERSYou’re aDESIGNERWhether you like it or not.
    35. 35. 4.YOUR DESIGNNITRO BOOSTERSYou’re aDESIGNERWhether you like it or not.
    36. 36. PERFORMANCEYou’re aDESIGNERWhether you like it or not.
    37. 37. PERFORMANCEYou’re aDESIGNERWhether you like it or not.
    38. 38. SPEED MATTERSAmazon 4.3% drop in revenue per100 ms delay caused a user.1% drop in revenue. MozillaYahoo! Download page 2.2400 ms delay caused a seconds faster increase of5-9% decrease in traffic. 15.4% in downloads.Bing Google Maps2 seconds delay caused a Reduced the file volume by 30% and observed a 30% increase in mapYou’re aDESIGNERWhether you like it or not.
    39. 39. “AUTOMAGIC”You’re aDESIGNERWhether you like it or not.
    40. 40. 5.DESIGN PATTERNSFOR INTERACTIONYou’re aDESIGNERWhether you like it or not.
    41. 41. Your
    42. 42. The World Your
    43. 43. The World Your “Forces”
    44. 44. Governments spendThe World $2B annually on radiation safety equipment ** Your “Forces” Most sniffers High radiation requires have 3-terminal HASMAT suit and gloves connector **
    45. 45. 10 USABILITYHEURISTICS Visibility of system status Recognition rather than recallMatch between system Flexibility and efficiencyand the real world of useUser control and Aesthetic and minimalistfreedom designConsistency and Help users recognize,standards diagnose, and recover from errorsError preventionYou’re aDESIGNERWhether you like it or not.
    46. 46. 10 USABILITYHEURISTICSVisibility of systemstatus Recognition rather than recallMatch between system Flexibility and efficiencyand the real world of useUser control and Aesthetic and minimalistfreedom designConsistency and Help users recognize,standards diagnose, and recover from errorsError preventionYou’re aDESIGNERWhether you like it or not.
    47. 47. VISIBILITY OFSYSTEM STATUSYou’re aDESIGNERWhether you like it or not.
    48. 48. VISIBILITY OFSYSTEM STATUSProgress indicatorsYou’re aDESIGNERWhether you like it or not.
    49. 49. VISIBILITY OFSYSTEM STATUSProgress indicatorsLive previewYou’re aDESIGNERWhether you like it or not.
    50. 50. VISIBILITY OFSYSTEM STATUSProgress indicatorsLive previewAutocomplete / live searchYou’re aDESIGNERWhether you like it or not.
    51. 51. VISIBILITY OFSYSTEM STATUSProgress indicatorsLive previewAutocomplete / live searchPeriodic refreshYou’re aDESIGNERWhether you like it or not.
    52. 52. BONUS:TACTIAL NUGGETSYou’re aDESIGNERWhether you like it or not.
    53. 53. WORK AS CLOSEAS PHYSICALLYPOSSIBLEYou’re aDESIGNERWhether you like it or not.
    54. 54. TEACH THEMYou’re aDESIGNERWhether you like it or not.
    55. 55. BE TAUGHT(YOU’RE HERE!)You’re aDESIGNERWhether you like it or not.
    56. 56. CREDIT & SOURCES“Designing with Forces”Ryan Singer http://vimeo.com/10875362Notes on the Synthesis of FormChristopher Alexander“Clean Up Your Mess”Daniel Higginbotham http://visualmess.comYou’re aDESIGNERWhether you like it or not.
    57. 57. CREDIT & SOURCESDesigning Web InterfacesBill Scott & Theresa Neil“Yahoo Design Pattern Library”Yahoo http://developer.yahoo.com/ypatterns/“Design for Developers”Robby Ingebretsen http://bit.ly/hkHghfYou’re aDESIGNERWhether you like it or not.
    58. 58. 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/4CyrwuYou’re aDESIGNERWhether you like it or not.
    59. 59. CREDIT & SOURCESHigh Performance WebsitesSteve SoudersYou’re aDESIGNERWhether you like it or not.
    60. 60. I READINGYou’re aDESIGNERWhether you like it or not.
    61. 61. I READINGYou’re aDESIGNERWhether you like it or not.
    62. 62. THANKS!@noluckmurphyYou’re aDESIGNERWhether you like it or not.

    ×