I originally re-designed this calendar screen with no intention of implementing those changes. This was an exercise to see how my designer and developer brain interacted, and it seems to have worked: free from the burden of having to eat my own dog food, I created a much more appropriate design.

Yesterday, I decided to implement these changes. Here’s what happened:

I’m using two external libraries to create this screen; Devin Ross’ TapKU for the calendar and RCSwitch for the on/off toggle. I needed to customize both to implement the desired result.

I first took a shot at the on/off. The background color and text color components were simple, but adding the bell icon to the switch was a difficult exercise. Why? RCSwitch uses a “stretchable image” to match the toggle component when it’s in an non-touch state. This translates into imperfections in  image placements when resting on either the left or right side. In lay terms, the button looks cruddy:

I had to abandon the bell icon on the toggle button for this reason. It looked “okay” without the bell, despite the icon adding a bit more clarity. Moving on…

My next goal was to modify the TapKU calendar. While I’d ideally extend this class and make my adjustments there, the lower-level nature of calendar drawing forced me to modify the text colors directly. This took several hours of fiddling with the calendar before I got it mostly right. I uncovered a rather big bug in how the app was processing dates, which forced me to find the new version of TapKU, implement it, and re-implement my imagery changes. *whew*!

During this process, I accidentally set my bold Avenir text to regular. The result was surprising - the thinner avenir type on the calendar gave it a more relaxed feel, and I decided to keep it. Happy accident!

Conclusions:

1. Don’t design the same day you have to implement. Your developer-brain is wired to “get it done”, the designerly brain says “get it right”. These two are generally in conflict.
2. Embrace happy accidents. If something comes up on implementation that may improve on a design, consider!
3. Don’t over-design: encourage a general philosophy and be open to modifications. Good designs are generally mutable because they embrace an underlying emotion or desire.

2012 was a big year for me on the iOS-front. I feel I’ve reached a level of expertise with Objective-C, Cocoa and UIKit to develop almost anything I want to at this point. I could continue to go further and seriously explore the nooks and crannies of the iOS/Mac software suite a deeper level, but instead I think I’m going to broaden my horizons to become more designerly. Specifically:

Spend more time researching exemplars

I haven’t been doing enough to explore new design methods, particularly in UI design. I’ve been stuck in a relatively dated UI approach and it’s beginning to show. The way I’ll get out of this rut is by “living in the future” with tech: spend more time exploring new products and trying new apps and services for a test drive. The best people I know do this and it shows in their work.

Iterate more on design, even after the project is completed

I’ve been falling into the trap of becoming too comfortable with early designs, which I always end up changing later to some degree. While this is a fairly common practice, I don’t feel like I’m growing as a designer. I will be dedicating time to creating alternative designs to solutions I’m creating, both on the strategy-side and detailed design. In design theory this is known as “generative” design.

Write more

I will be spending one day a week practicing writing. This includes new portfolio pieces and blog posts of interest. Good design is about communication, and it pains me to read through poorly written work of my own.

When I first started working on SpeechHero, I decided I would work with a graphic designer at the inception of the project. I had a talented friend and colleague who expressed interest in working with me on the project on a freelance basis, so I agreed to an early design. His style was a bit outside of my core audience (kids with autism, their parents and therapists) but I eagerly agreed.

Below is what he produced at the end of our first major iteration.

This design, while good, is a bit too modern for the audience of disabled children and their parents. Realizing that this relationship wouldn’t work out we closed out the contract amicably and are still friends and colleagues.

This is actually a good design; it’s just not the right design for the audience. This particular designer produced fantastic work with darker themes and deeper colors (something that’s quite difficult to do) but had less experience in the lighter subject matter I desired.

After several more iterations on my own, including a number designs much less suiting than the one above, I finally landed on a design we felt was appropriate for the wider disabilities-based audience. The design was more generalist and Apple-like in its quality, but still had a colorfulness about it that testers loved.

When I think back to graphic design hiring opportunities that went well, the designer generally had a combination of these factors:

They demonstrate prior work with a similar aesthetic quality

Graphic designers take on a particular style. If you ask a designer who chiefly crafts darker themes to switch-hit to lighter ones, they may be too distant from their comfort zone to be successful. A good graphic designer will get there eventually, but it may take many iterations if they haven’t done something similar before.

They ask about audience, goals and message

 During the initial design conversations, the designer asks about the goals of the project and audience in question. While its fine to ask about other projects I appreciate, I find that an approach based around “stealing sheep” is playing with fire. The designer should work forward from the audience and goals, then talk about desirable exemplars.

They can reflect on strengths and weaknesses of their work

Designers often complain about clients pushing back on work for seemingly silly reasons. But there’s also something to be said for a designer who can reflect on their own work and discuss what works and what doesn’t in a logical way. If a designer insists on something but can’t explain why, that’s generally a warning sign of more fundamental problems. Good designers can explain their decisions and rationale, identify weaknesses and sharp edges.

Outside of these elements, it’s really up to the customer to pick the right person for the job. While not all working situations be successful 100% of the time, being able to better identify the right graphic designer for the project will save you time and money.

My first year of UX school was rough. It wasn’t because I didn’t like design, or that I wasn’t engaged in the subject matter, but I found the attitudes of some of the professors flippant and dismissive toward developers. Granted, these were researches and not practitioners, but the message from our intro class was this:

“Programmers don’t understand design. They will do whatever is easiest for them. It’s your job to create the great design and then motivate the programmer to complete it. All you need is a programmer.”

If you’re laughing or cringing right now, you immediately recognized this statement as amateur naïveté: “it seems effortless when I use it, so it must be easy”. The same way  this developer assumed a marketer’s job was easy because great marketing appears to be effortless, this design researcher assumed finding a qualified interface programmer was easy because someone made it seem effortless. Moreover, he assumed that a lack of well-programmed interfaces was a problem of motivation on the developer’s behalf, and all they needed was a UX leader to whip them into shape.

High vs. low-interactivity

A highly-interactive interface is one which gives the user a great deal of freedom to play and explore. At the same time, the underlying system stays responsive to the users’ input while providing smooth transitions between interactions. That is to say, a highly-interactive system is doing a lot of stuff, elegantly, at the right time. Examples of highly-interactive interfaces: modern OS GUIs, web browsers, exploratory sandbox video games (such as GTA, Half Life, Halo, etc.), and mature web applications (Gmail, Facebook). The similarity between all of these systems is that they are engaging, self-contained platforms for interaction. This is because most, if not all, of are building their own UI approaches from the ground-up.

Compare this to low-interactive interfaces. Examples include functional prototypes, Line of Business (LOB) software (aka “Enterprise”), form-based web applications (anywhere you click a button, go to a page, fill something out, wash, rinse, repeat). These applications incorporate locked-in GUI mechanism which force the user into a narrow subset of operations. They are often created to complete a specific task and an engaging experience is not necessarily important to the business goals. Most (and by that I mean 90%) of software efforts go toward low-interactive interfaces, because most businesses don’t feel they require anything but boilerplate UI. They are probably right.

Highly interactive interfaces are often desirable in situations where user engagement is tantamount. An interface that is used every day, for example, would benefit from a more responsive approach. Autodesk needs to have a responsive interface in Maya because animators rely on that responsiveness to express themselves adequately. If an animator is forced to drop into the console to get something specific done, for example, the engaged creative experience is broken. (BTW, many 3d animators know how to use the console)

So why are these things so difficult?

More interactive interfaces are more desirable to businesses focused on quality software experiences. Everyone wants quality software UI, or at least they say they do, but very few companies are willing to put the money forward to make this happen. This usually has less to do with the programmer or designer’s ability and more to do with the time to complete such a task.

That’s Thomas Fuchs. Thomas is well known as the author of script.aculo.us, a high-end javascript UI library with the tagline “it’s about the user interface, baby!”. Thomas married Amy Hoy, another designer/developer and UI expert. You’d think with this level of expertise, this power couple would be writing books on great UI practices, or 100 patterns for UI-ifying your appy app, but no. They wrote a series of books (and host a series of talks) on JavaScript performance.

Yep, the high-order bit for their lickable UI interactions is performance. Great interactions are so difficult to code because of performance bottlenecks; the most limiting of limitations. The person who can balance system-level interactions will inevitably have more responsive UI’s than the next person. The person who wants UI performance, but ignores the fundamentals for the sake of “getting it out there” will likely have an unscalable mess.

Let’s say you code the the app to drag and drop something from one place to another. Perhaps the transition looks goofy when moved over an already-animating element. Fixed that? Well, now when you scroll, the new animation transition begins to thrash. Okay, fixed that. Wait, now the drag and drop is hanging again. Argggh! This is so hard!

Thomas and Amy used to consult companies on creating higher-performing interfaces, charging a princely sum for the task (I believe Amy once said she charged $500/hr as an average). Companies gladly shell out this cash because it is just that difficult to find a person who understands how this stuff really works.

And because most of the technical effort is going toward low-interactive systems (“build it in a month! fail fast! ship crappy!”) fewer and fewer people are capable of making this happen. Developers drool over TapBot interfaces and desire to build similar products, but few 20-year-olds who just learned HTML want to face the fact that Paul from TapBots has been working with Mac platform since those youngin’s were in diapers. For that decade when Apple stock was in the crapper, Paul was quietly fighting his Mac IDE every day, building responsive UI expertise along the way. When you’re too busy learning the web language du jour you miss out on the commitment and craft that make these great systems so great.

All you need is a programmer…?

If you desire to create an impressively interactive system you need to get serious about investing the time to do it. SpeechHero took us nine months to design and develop, seven of those months were full-time. Of those seven months, I spent a full two months developing the UI (drag and dropping across scrollviews, automatic realignment of other elements when something is moved, adding and removing the UI elements gracefully when they disappear from view). And guess what? The interface still isn’t where I want it to be. Not even close. Why did I spend so long on it? Because we found that 100% of our early testers attempted to drag-and-drop elements, and became frustrated when it didn’t work. Since they were going to use the app every day, often all day and by a number of people, the interface needed to be engaging and intuitive. 

To designers who’d like to create these interfaces my advice is to become a better designer. If you’re a great designer, great developers will find you and want to work with you. Great people want to work with other great people; there are no shortcuts. You will not find your Woz huddled in a dorm room waiting for you, the proverbial Steve, to walk in with a brilliant idea and two hits of acid. You need to spend some time at the orchard tilling soil and sleeping on the floor to cultivate your own excellence, only then you can work on excellent products.

There’s a saying in startups that I’ve always questioned: “Ship crappy, fix it later.” The idea is that you can ship the first version of a product in less-than-stellar form, test it with the market, and fix it later.

This works in two different environments:

1) Organizations that have a locked-in customer segment with little risk of losing those customers (Microsoft, Salesforce, Oracle, SAP)

2) Circa-1990’s software startups

One of these things is difficult to achieve. One is nearly impossible. Both have something in common.

It used to be okay to “ship crappy” because it was highly likely that the crappy thing you were shipping was so new that your competitors didn’t exist, or couldn’t keep up. Today this doesn’t work.

The practice of continually shipping is an important one to cultivate. Fully implementing a component, shipping it, and iterating on it is ideal to slaving over it for months. But that’s not an excuse to leave it unpolished or unfinished, especially today, when first impressions can make or break your product.