WalkIN is a team of nine that got an OpenTable analyst to talk to us, got restaurants signed up for trials before we left the bus or finished coding, and created a Rails backend with Android, iPhone, and IPad native clients (iPhone and iPad are different apps) in less than a week. You'd think we'd be very full of ourselves, wouldn't you? We were a little bit but almost every dev on the team has told me how they fell humbled to be around such highly skilled people and wanted to make sure they lived up to everyone else's standards and skill level. Apparently this is the Dunning-Kruger effect where highly skilled people underrate their abilities compared to others. It wasn't so much that it was paralyzing but it was reason I scraped and redid some of the Android UIs and also why it pissed me off when I couldn't figure out how to close an errant 5px gap. I felt like I wasn't executing on Alex's Android designs….Yes, devs do care about design…sometimes.

 

We had two designers who shared the design work for the website. They split up the work for the clients with Ken taking responsibilities for iOS devices and Alex taking on Android. It was nice to have Android not be an afterthought. There were some iOS-isms in the design for cohesiveness but it still looks Android-y, if that makes any sense. One of the cool things is that I sat right across from the designer team and they walked us through the flows for the wireframes fairly early. That enabled me to give input and point out iPhone-isms in the design that don't translate to Android. Being able to point that out early saved much needed time for all involved. For example, the badge metaphor doesn't exist in Android. I used the wireframes to do rough prototypes of the UIs that I could refine once I got the finalized versions. 

 

Before I moved to California, my former roommate of 2 years Carl Vervisch, now co-founder of Social Forces and whom I'm really sorry for neglecting at SXSWi, was a graphic designer. Living with someone for that long, you tend to pick up a little bit of design knowledge even if you don't try. Doing Java UI stuff with Griffon doesn't hurt either. As a result, I'm what I'd call functionally literate in pixels. I have the presence of mind to ask things most devs aren't concerned with like padding, hex colors, font faces, sizes, etc.  This is especially key for Android because unlike iOS, we don't have any WYSIWYG designers like Interface Builder. You have to do everything by hand in XML or in code. Having a firm grasp on the designer's vision and asking lots of questions is the difference between a shit layout and a good one. Had he(Alex) just dropped a set of final designs in my lap as many designers do, I might have not taken as much of an interest. The thing that some designers don't realize is that devs see everything as code that can be refactored. Give them a "finalized" design where you didn't involve them or consider what is feasible or possible on that platform and they might change parts of your design. It could be that you designed above their skill level, the design is not feasible for the giving deadline, or it goes against the standards of the platform. Get the developers involved early and they will feel more comfortable pointing those things out to you.

 

Now for a little controversy. Designers should be able to build what they design. There's a lot of responses to a similarly themed question on Quora and there is some differing viewpoints on the matter. Some offer the somewhat facetious example of an architect not needing the skills of a general contractor to be effective. Even if we just consider mobile, there are too many platforms in which for a single person to be proficient or even competent. However, you should be able to layout your designs in one of them. Be it iOS, Android, Windows Phone 7, or just HTML/CSS3. No Flash doesn't count. Knowing how to layout your designs will give you insight into the developers mind and help you realize why your design might need to evolve. Thankfully, both WalkIN designers could layout and design.