Cowboy Coding, FTW!

This is so so depressing. In the past three years I’ve got convinced in the very same thing. It just doesn’t work with design agencies. Right now, I’m rethinking my companies process and how I can optimize it for working with design agencies. One of the big difficulties is how to persuade them to use a more effective communication channel – to be specific I really prefer wiki instead of emails with attachments and an endless search for differences.

Have you ever used wiki (or systems similar to 37 signals basecamp) when working with design agencies?

That said, I think there are a few important things to point out that I might not have made clear.

The first is, again, making designs that are hard to code has a business impact. I don’t mean to sacrifice the design’s ability to provide an easier to use product, I’m talking about simpler things such as only making 8 states for Buttons vs. making up your own. The Flex SDK Button has 8 states; most only use 4 (up, over, down, disabled). Designers who don’t create those states, or create their own make the developer’s life a lot harder, and in turn this takes up valuable time that could of been easily remedied if the designer just knew a little about the Flex SDK and what native skinning features it supports.

Now, when the need arises to create a Button that differs from the Flex implementation because valid user testing data shows that it’s a valid decision to do so, I’m all for it. However, history has shown me more of the former, the designer making things harder than they have to, is more prevalent than the designer making things harder for the sake of user ease of use.

The easier it is for me to execute, the more assurance you have that functionality will actually work. If functionality actually works, that means more time to play with the design based on user testing data. If it IS hard, then I’ll end up spending a lot more time on getting basic functionality to work, let alone getting the design implemented. There are a ton of compromises that can be made that won’t adversely affect the user’s ability to accomplish tasks in the application (assuming you’ve validated those decisions with actual users). My point is, from my experience in both Flash & Flex, I haven’t seen those discussions happen in a positive light; a lot of times there isn’t a lot of dialogue, or the design isn’t perceived as “fluid” by the team.

Secondly, those 2 points above; does this make it harder, isn’t really discussed nor validated. You bring up selling UX whereas most times during my project it all comes down to user stories with time estimations. I still think it’s valid in Scrum and doesn’t negatively affect design; I did in fact factor in my time estimations the design parts of the components. What I didn’t do effectively was involve the designer enough in my work-in-progress builds. That wasn’t a failing of the process, nor was it a failing of the team to sell the client on UX; it was my fault for not prioritizing correctly, pure and simple. The client already has a great appreciation for good design, and recognizes it’s impact. My execution just needed a little better prioritization, and I feel I’ll do tons better next time (just like every project, hehe).

Also, I TOTALLY recognize the law that users should be first. I married a Usability Engineer. If she were commenting, she’d basically say you and I are both full of shit until we test the design first. Only once users actually use the build in progress do we get validation on what parts of the design and functionality are actually “working” with factual user testing data.

Unfortunately, we did user testing during our first alpha. I was vehemently against this, and since Day 1, I tried and failed multiple times to sell a good user testing strategy. My wife already works for a company, AT&T, that has user testing built into their process. While that’s nice, it proved too challenging for me to create a user testing plan and incorporating into our process amidst doing development.

Also, please keep in mind I abuse the word design a lot. When I say, “Getting the design in”, I’m talking about getting the skins, the colors, and the shapes correct. I may have gotten the tiled list with drag and drop features like the iPhone finished like the designer wanted enough to show the client, but not the correct colors, fonts, spacing, text formatting, and rounded corners. That DOES have an impact, and I recognize that.

However, if I spend 0 time on design, and 100% of it just getting a simple draggable tile-list working, and make very little progress in 3 days, it’s pretty clear we won’t be able to make it work like the designer wants. While we may even have user data to supplement the positive explanations form the designer, the mere fact remains that the execution is beyond the teams abilities. It doesn’t matter if it’s the right thing to do, it’ll never get done. Other times, it may only take 3 additional days, but the team fails to sell the client on how 3 days, with 16 man hours will equate to a positive user experience once completed. While it may have been right, the ability to communicate that correct decision was at fault, not the team’s ability to execute. That, or the client being a startup on a limited budget cannot afford the better design because it takes longer to implement. What do you do then? Compromise.

Regardless, thanks for bringing up those points. Just because we feel like I’ve finally found a process for ensuring our projects go more smoothly doesn’t mean we should lose sight of what we’re really trying to accomplish, and those goals should come first, not following the process.