Things software development teams should know about design
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:
- 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)
- design is an iterative process involving everyone — not just “the designer”
- in all stages of the project cycle, design must be present: before, during, and after
- design isn’t just eye-candy; functionality is even more important (text/content is part of design too)
- designers are full team members (and should be treated as such), not some add-on
- design issues should have high priority too (if something is unusable or even sometimes looks unusable, then people can’t use the software)
- designers are developers too (in fact, anyone who contributes to making software is a developer — not just programmers)
- good software requires design, documentation, project management, community engagement, marketing, etc. — in addition to programming
- “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
- 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)
- 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)