Designing how it works, not how it looks

It's normal to approach iOS development first from the perspective of the UI. It's easy, we can see it and touch it. It's also the way specifications normally get communicated in a way management and product owners can comprehend, a set of pictures that can be assessed and signed of. Unfortuantly pictures do a lousy job of conveying how something works.

"Design is not just what it looks like and feels like. Design is how it works." - Steve Jobs

Given this is almost certainly true from someone who knew a bit about design, why do we put so much emphasis initially on how it looks? Doesn't it make more sense to begin with "how it works". How would you do that though? With out being able to see it, how do you get feedback about how it works?

To bridge this impasse you need an alternative way to get feedback and to be able to "see" without a UI. This is where acceptance testing is useful. A set of Acceptance Tests written first force you to think about the "how it works" and to answer those questions before seeing it.

With a set of executable acceptance tests you use red tests to drive the work (sound familiar, it's the same as TDD but at a functional level). Only once all the Acceptance tests have passed e.g. you've built the feature, do you then begin working on your real UI. I say real because you've actually now with your acceptance tests already built the first UI using simple text and that is now great for things such as regression testing and describing future changes to functionality

This is all part of an approach that avoids going for the gold. The gold in this case (along with any happy path scenerios) is the UI. Defer it as you would other implementation details for as long as absolutely possible.

Deal with errors, deal with missing data, deal with all the edge cases you can think of before dealing with the UI. The benefit of this approach is it allows for ongoing visual and UX re-designs by your design team based on your learning more about how it works before anytime has invested time in coding it.

Users care first and foremost about how something works and then how it looks, we can approach our work with the same priority and at the same time improve our app designs.

Check out the previous article on Acceptance Testing with Fitnesse to find out more about how to write Acceptance Tests first for iOS.

Join me for a 2 day workshop 'Mastering TDD & BDD for iOS' at CodeNode 22-23rd Sep - Early Bird Pricing ends 26th Aug