Designgeneering Diaries - Part 1Monday, 5 March 2012
What is "designgeneering"?
I went to a Seattle Creative Morning a couple months ago to hear Jenny Lam give a talk about the role of designers in startups. You can watch a video of the talk here. As a developer, my big takeaway was the engineering world can and should be growing in inviting designers into the product creation process.
On a similar tack, a few of us at Beer && Code have been wondering how we get more designers to participate in our community.
After hearing the talk and getting to meet more excited and influential designers, I decided pursuing this idea would be a good goal for me in 2012 and I called it "designgeneering."
In case it isn't obvious, "designgeneering" is "design + engineering" and I pronounce it "design-geneering".
Designgeneering should be about building great products people love to use. It is fairly common to think of product development in a series of phases: build something, and then make it look pretty. The problem with this is users care about experiences first, not data.
As a developer, I tend to think about data first. I tend to think about structures and architecture and getting things from a persistence layer to an interface. I want to make interfaces that are clear and effective so users can get data in and out. I think about how code should be organized so that implementation concerns are grouped and isolated from each other. I think this is great fun and it is an essential part to building a product. Think of it this way: a pretty product that doesn't work still doesn't work.
However, I recognize a couple things. First, users don't care about the things I care about when they use applications I build. Second, users that aren't attracted and drawn in to my applications won't use them. Moreover, I think users that are looking for an experience won't be as impressed as I am by how the data flows. I think this is where design comes in because building an experience involves more than slapping some CSS and images on a page.
So what is in the middle? How do I hear about a problem or product idea without thinking about data and implementation first? How do I build something people want to use?
I don't think learning how to do it on my own is the answer. Consider the words of Ron Swanson from the TV show Parks and Recreation: "Don't half-ass two things. Whole-ass one thing". I'm growing in my design skills, but I want development to be the thing I do well.
Instead, I want to promote the idea of inviting designers into the process when I'm mapping out data models and sketching architecture and interfaces in my notebook. I want designers to be around when I'm defining specs and tests. I would like to have somebody there that cares about what the user is experiencing.
Ultimately, I think it is engineering and design together that will help define a great application--both technically and experientially.
How I Will Start
My good friend Brad and I have worked on small-time applications together for a while. We built a site for my wedding in 2011. He helped me make this site look and work better. I respect and trust his skills in design, and I really enjoy working on projects with him.
So our plan is to build stuff together and record how it goes. We'll point out things that work and things that don't make sense.
My hope is that people catch on to this idea and partner to continue building great software in the years to come.
My next post will be a little more specific to a new project we are working on and how the first day went.