tap tap tap exists in somewhat of a virtual state… we have no central office and everyone involved is in a different part of the world. So how do we work efficiently on our projects?

Many things like coding and marketing can be done in a vacuum. The person responsible for his or her task can simply work on it and report back to the team when appropriate. There’s really no need for Sophia to go over every Objective-C line or SQL statement she writes with everyone else.

The past

The way that we’ve worked with designers in the past has mainly been a lengthy, iterative process. We’ve all worked with our designer, Wolfgang, on various past and ongoing projects and we used to get things done with a mix of text chat, voice chat (using iChat and Skype), and email. If we’re all in an audio chat, having a group text chat alongside is handy for passing along links, etc.

We’d discuss ideas we’d have for UI, along with some variants to try and then Wolfgang would deliver the goods via email a day or two later… sometimes longer, depending on how busy he was at the time.

During the next meet-up, we’d go over revisions and repeat the cycle until we ended up with the results we were looking for.

Overall, it was generally effective but highly inefficient. Because of the lag time between meetings we’d sometimes settle for somewhat suboptimal end results. Things could’ve continued on for a long time if we kept tweaking designs using this system.

The turning point

A while back, John was chatting with his MacHeist partner, Phill Ryu. During the chat, Phill was occasionally passing images of a project he was working on. John was fairly surprised that he was getting updates so frequently. He knew that Phill was working with Wolfgang on the project those days but he just assumed that they used the same process he was used to when working with Wolfgang.

Phill explained that he’d often hire Wolfgang for a whole workday interactive “session”. John was pretty skeptical about this method, mainly because he felt there’d be too much downtime for him between design iterations. But Phill recommended that he at least try this once with Wolfgang.

UI design & graphic design… it’s not just about pretty pictures

Before going on, it’s worth pointing out that there are several ways to go about turning an app from concept to reality. But two ways are the most common in practice among developers…

One way is to work on most of the UI, code it all up, then try to make it look good afterward.

Another common way is to do somewhat of the opposite… start with a fairly vague idea of the UI, refine both the way the app functions and the way it looks in one big step, then implement it all in code.

Granted, this is an oversimplification of the whole process because it’s rare that anything’s as cut-and-dried as this. Often, an app’s development will be a bit broken-up and it’ll be done in “chunks”. But one of these two workflows often still applies to how each chunk is worked on.

We tend to go with the later method for creating our apps. We usually start with a “programmer mockup” that intentionally looks like crap but simply shows the basic functionality. We do this because we don’t want to steer Wolfgang in any particular direction at this early stage. So, really, the worse it looks, the better it is at this point.

It’s important to note that this isn’t all about just making things look pretty. A good app has a balance of form and function. So it’s vital that at this stage most of the app mechanics and interactivity are worked out in detail, in addition to making it look aesthetically pleasing.

What we’ve found is that it’s much more effective for us to brainstorm UI designs when working alongside with someone who can make quality graphic designs.

When you have a mockup that looks exactly like what the final app potentially will be (the “pixel-perfect” mockup), you’re better able to notice flaws and usability issues much earlier in the whole process.

Also, at least for us, it’s much more motivating to have a sweet design worked out first… then turn that into a real app. Moreover, Apple themselves are known to use a method similar to this for their apps and it’s harder to go wrong if you’re following Apple’s lead.

The recent past

As a result of Phill’s suggestion, John gave the collaborative method a shot in a past project with his partners involved at the time.

It definitely was different. But it was soooo much better!

Design iterations came almost immediately (Wolfgang has the mystical power of often providing a new mockup before one of us is even finished explaining the changes we’d like… yes, we’re dead serious… warlocks rule!).

The lag between meet-ups was mostly gone now so everything just flowed very nicely. And even when there was a little delay between design iterations, the time was usually used effectively.

John suggested that Sophia also try this system because she was also working with Wolfgang on CoverSutra before starting tap tap tap. She did and was immediately hooked, too.

But although the process had now improved significantly, it still wasn’t without its issues… the bulk of them having to do with Wolfgang passing new design revisions to multiple people at once. While it’s easy enough to have a multi-person text chat in iChat, one huge shortcoming is that you can’t send images or files in it the way you’re easily able to in a 1-on-1 chat.

So the obvious workaround is that Wolfgang has, in addition to the group text chat, an additional text chat for each other person in the session. It works, but it’s clunky… for every new mockup, he has to send it once for every person in the session. If we have four people in the session and he’s sending several different iterations to us in one session, it’s easy to see how this becomes a real pain for him.

In addition, it’s not so optimal for us either. An iChat window is not the best place to view images, especially if they’re large… for instance, website mockups. iChat was designed to mainly handle text, with the occasional image. So we have to make the chat window unusually large to view the images because iChat scales them to fit the window. And if anything else comes in the chat, we have to keep scrolling back and forth to keep up with new things and what we’re trying to evaluate.

So, for bigger things it would often make the most sense to have Wolfgang send us the image files, rather than inline them in the chats. But it’s easy to see how this could quickly get out of hand. Here’s a look at Scott’s Downloads folder to give you an idea…

And iChat has its share of reliability problems to compound things. All of the .iChatTransfer files you see above were failed transfers that had to be resent by Wolfgang.

The present: enter Skitch

Our take on Skitch was that it was pretty much a fun, little app used to add annotations to and draw little doodles on pics. Most of our experiences with it had been with Austin Sarner using it to torture his friends.

In one session a while back, not long after we started, Wolfgang passed us all a URL in the group text chat. It was a skitch.com URL. Nice… he must’ve drawn a mustache on a Sophia pic or something. We all clicked the link.

To our surprise, it was the first mockup of the session. Very nice… he just eliminated the issue of passing us images in iChat. The expense was that we all had to now click a link every time he created a new mockup… no more being spoon-fed for us.

Wait… but was this the actual case??

A couple of minutes after the first mockup came through to us and we critiqued it, much to our surprise and delight, another one came through. Not a link in the group text chat but right on the original Skitch page, right under the first one!? Automatically.

We were all wowed.

This was a huge improvement to our design session workflow. In one fell swoop, Wolfgang managed to chop out all the shortcomings of image handling in iChat by using Skitch now.

So from a designer’s point of view, how’s this all work? Well, Wolfgang created a nice screencast to step you through the process…

view large screencast

Pretty simple, eh?

If you’ve been doing this the old-fashioned way, you really need to give this method a shot. We can just about guarantee that you’ll never go back once you try out this method.

Here’s the link to the Skitch page of the second design session for the tap tap tap logo where we finalized it:

http://skitch.com/bartelme/xyik/tap-tap-tap-logo

Although it’s one of the last things we expected it to be used for, Skitch has proven to be an invaluable tool for ultra-rapid design prototyping for us.

The process

So what’s the whole design process like? It definitely varies.

For Sophia, when she’s working on CoverSutra, she usually has a clear vision of what she wants before jumping into a design session. She usually begins by designing interfaces and workflows using pen and paper.

She’ll draw the various buttons, boxes, etc. which help her to visualize the whole UI better than she can if it’s just in her head. For her, pen and paper, rather than firing up Photoshop, makes everything go much faster in the beginning.

After she feels comfortable with her rudimentary designs, she’ll schedule a session with Wolfgang where he’ll work with her by fleshing it all out in Photoshop. Because she usually has a pretty clear idea of what she’s looking for, Wolfgang typically works on his own without much intervention between mockups. She then reviews revisions and repeats until she gets the desired results.

With tap tap tap it’s definitely different because we need to find a balance of what we all like. So bouncing ideas among all of us and getting almost immediate feedback in the form of a design mockup is invaluable.

While brainstorming UIs without having a graphic designer around often works for vague, initial ideas, nothing beats actually having real, pixel-perfect mockups when fleshing things out. A big benefit of having the mockups is that it makes it much easier to maintain focus and helps us to imagine how the apps will actually function once implemented.

And as for the ultra-rapid prototyping, we’re able to try out many ideas and variations, even if some initially sound half-baked. What would’ve been impractical with the old method became completely with the new one. Since it’s so fast to try new things out we often test ideas that seem hair-brained to some at first. But after a bit of “discussion” and a few adjustments, some ideas turn out to be very effective UI and graphic designs.

We’re considering showing many of our Skitch sessions for our various designs (all of our apps, website, etc.) over time if you’re interested in more posts along these lines. We’d detail some of the significant points where the designs evolved. And we’d detail our reasons for making the design choices we did.

The pros & cons

Without a doubt, our design sessions are one of the most enjoyable parts of our business (if not the most enjoyable). It’s always exciting to see how our ideas come to life, right before our eyes. When things turn out well, there’s that “BOOM!” feeling and not much compares to it. You can almost compare the anticipation of receiving a new mockup to the anticipation of Christmas coming when we were kids.

But it’s not all rosy…

We all have strong feelings about our ideas so we often have a lot of conflict. It’s really easy to get attached to an idea that you have. So we sometimes have a hard time letting go of a concept that’s suboptimal. It can be hard to do, but it’s important to at least try to keep an open mind, especially in the early stages of design evolution. Getting too attached too a bad idea can potentially kill an app. We know this from experience, unfortunately.

We also have conflicts regarding what we’re able to accomplish in a reasonable amount of time. We’re not the quickest iPhone development shop by any stretch of the imagination. We try hard to make things as good as we can and it’s easy to bite off more than we can chew. Design sessions can make this even worse because when you see a really beautiful design, you quickly get attached to it no matter what the cost. But sometimes you just have to reject some ideas because they’re impractical to do in a realistic timeframe.

It’s also very important for everyone to communicate their ideas effectively. It’s easy for others in the team to misunderstand an idea you’re trying to convey to them. A really good idea has the potential to get rejected if others don’t “get” it. Often, even a quick sketch can help immensely in situations like this.

And one gripe we have with the Skitch workflow is that even though the web pages auto-update, there’s often a lag between when Wolfgang uploads until the time we all see it. A refresh button, or better yet, an “adaptive” refresh rate that adjusted itself depending on how “live” the page currently is would help make the whole experience much better.

But the pros definitely outweigh the cons. It’s taken us a while to fine-tune our design workflow and we’re very satisfied with it at this point. Design is just one piece in the big puzzle of our business but it’s undoubtably one of the most essential pieces.

If you enjoyed this post and would like to see more like it in the future, leave a comment below.