We’re making significant strides over here to improve our design process. And by design, we mean a lot of things: building a startup vision, creating the user interfaces, and presenting a beautiful look and feel for our clients.
My current work is primarily on a client project called TPG Marine Harbor Management System. Yes, long name, but the project boils down to helping barge servicers track their fleets and automate billing. Crazy stuff. I joined the project as the second developer, but I’ve since taken responsibility as the designer.
The way we’re doing design on TPG is this way: we figure out what problems we want to solve in the next several weeks, and we start designing solutions today. The challenge I’ve faced is knowing when I’ve completed a design task. Finishing design isn’t as clear-cut as completing implementation of a feature. Should I mock up every detail for the developer? Should I code all of the html/css and hand that over to the developer? And most importantly, am I done yet!?
Because we live in a world of scarce resources, we need to figure out what get’s us to completion the most efficiently. Here are some ways in which I’ve tackled finding confidence:
Wireframing seems to work well when an app is being built from scratch. It helps answer questions like, what content needs to exist? What actions can be taken? Who are the users? I haven’t used wireframing much since my project is far beyond the initial design phase.
Sketching helps get design insights tangible quickly. Skteching can help you visualize a solution without committing much time. I’ve found that the ease of finding confidence or the lack thereof from a sketch depends on my level of experience with the project I’m on. The more experience I have, the better my intuition and thus the more easily I can vet ideas in the sketching phase.
Since my project has an existing codebase, I spend most of my design time working with these three tools. Using git, I checkout a design branch for each design task and start messing around, searching for what interface and interactions (clicking, entering data, etc.) give me confidence. For my last design task, I abruptly stopped working on my design and concluded I had confidence, long before the interface was polished and the interactions complete. But that was OK, because I knew I could perfect everything after design is finished.
(For all Rails/Git folks out there, an extra tip: I will clone a second copy of my repository so that I can run two versions of my app, one for development and one for design. That way, I can see my design work in action in a browser window while implementing the design.)
The goal here of this design process is to think critically about designing solutions before implementing a solution. But it’s also to be lightweight as possible. Good developers on small teams don’t need to know every pixel of an interface. They need to know what the solution is. The deliverable from these design tasks is often nothing more than a series of implementation tasks for developers, a half-baked demo, and maybe some code to reference.
I would love to hear your thoughts on approaches to design. I’m sure the approaches will vary, given the needs of different clients, projects, and teams.