UX is often spoken of in terms of the look and feel of visual elements: the layout of a navigation or the arrangement of fields on a form. A UI-layer thing.
It’s comforting to believe this: you’ve a specialist on your team who can deal with the “UX stuff”. This is a delusion. One person isn’t capable of covering all your bases because UX is defined by virtually every facet of your product, from design through implementation. While the UXer on your team can oversee things to an extent, it’s hard for them to retrofit good UX if it’s not baked in from the start.
For example, the main screen of One to Watch is a listing of the films you’ve selected to watch. This is the primary screen of the application in many ways, in particular as the first you see each time you open the application. Visually it’s a simple screen. I’ll be the first to confess I took much of the UI directly from the music app. An incredible amount of work went into making the user experience of this screen perfect, very little directly to do with how it looks.
Most of the effort was into perfecting how it feels in use. And for a screen like this, how it feels is mostly defined by the code behind it.
One aspect of this is pure performance. iOS contains an image widget which is able to resize and crop an film’s poster into the square, as required by the visual layout of the table view used for the listing. Easy then — just drop an image into the table view cell template and be done with it. Apart from you’re not. Asking the iPhone — even the 4S — to resize an image as a users scrolls gives a terrible user experience. Laggy, jumpy and painful.
Even for a free app, this is unacceptable. It’s indicative of a half-assed job. So I spent the time to make it silky. There’s a lot more code than I expected there to be behind that, including a small, incomplete framework to managed cached images along with various named sizes and crops. Was it worth it? For sure.
So we’re all doing UX — throughout the stack. Get used to it, and build like you mean it.