Archive for February, 2015

Things software development teams should know about design

Friday, February 6th, 2015

I wrote a quick, unpolished list of things that development teams should know about design (and designers). It’s worth sharing with a larger audience, so here it is:

  1. programmers and managers need to fully embrace design — without “buy-in”, designing is futile (as it’ll never get implemented properly — or, often, implemented at all)
  2. design is an iterative process involving everyone — not just “the designer”
  3. in all stages of the project cycle, design must be present: before, during, and after
  4. design isn’t just eye-candy; functionality is even more important (text/content is part of design too)
  5. designers are full team members (and should be treated as such), not some add-on
  6. design issues should have high priority too (if something is unusable or even sometimes looks unusable, then people can’t use the software)
  7. designers are developers too (in fact, anyone who contributes to making software is a developer — not just programmers)
  8. good software requires design, documentation, project management, community engagement, marketing, etc. — in addition to programming
  9. “usability” != “design”; design is about creating something useful (and/or pretty), whereas usability is discovering how well something works — usability tests are useful to see if a design works, but usability test alone usually won’t point a way to fix issues… design helps fix problems after they’re discovered, and helps to prevent problems in the first place
  10. a lot of designers are quite tech-savvy (especially us designers already in the open source world), but many aren’t — regardless, it’s okay to not know everything (especially about programming corner-cases or project-related esoterica)
  11. think about the people using the software as people using the software, not as “users” (using the term “users” is degrading (similar to “drug ‘users'”) and sets up an “us-versus-them” mentality)