Designing the Obvious: The Ongoing Mission of Good Design
- Design Continues After Coding Has Started
- Just-in-Time Design
- Undercover Design
- Iterative Design
- Modifying Your Process
- Online Resources
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Previous articles in this series have talked about how to uncover the truth about what your users need and want; how to create use cases, wireframes, and prototypes to nail down a design before the expensive coding begins; and how to perform usability tests to validate a design. Now we’ve reached the end of the series, where I’ll offer up some last tips you can take back to your office to try to improve things.
Design Continues After Coding Has Started
First, understand that design work cannot stop simply because the design phase is complete. Once coding begins, there will be many occasions when the proposed design doesn’t quite work because of a technical glitch, and developers will be in a position to make snap decisions about an interface—and risk fundamentally changing the user experience you planned so carefully.
To prevent bad changes, you need to stay involved. Don’t let the application you spent all that time designing get away from you once it’s in the hands of developers. If your company practices extreme programming methods, get involved in the daily standup meetings so everyone knows you’re there to address new design issues that come up during development. If there are no standup meetings, just swing by the "programmers’ pit" once a day to see how things are going.
Every designer should have some degree of technical know-how when involved with application design. If you don’t know how things are actually built, you should at least be able to cite examples of other products or sites that contain design patterns similar to those you used in your design. But the more you know about what the developers do, how they think, and what’s important to them, the more you can earn the respect of the development team and increase the odds that they’ll listen to your input. Designers and developers don’t have to clash—they can actually meld and become a functioning unit working to achieve a common goal.
The rest of this article discusses solutions and approaches you can use to keep a product headed in the right direction, even after your design work is done.