Iterating experience I

I've been doing the lean startup thing for four months now. I've handled web app development before, but the experience I'm having bringing congruence to multiple channels -- all at different stages of the development lifecycle -- is exciting. I am learning a lot, like my peeps, and have respect for the work we're doing. Happy place to be.

The simple ideal for a system bringing together multiple technologies is to create an overarching experience, so the user doesn't see the different pieces. They just want consistency, so they know what to expect. The first challenge is in trying to unify these pieces over time; there's only so many resources allocated, each technology set has unique parameters and can be at different stages of the timeline, and as you learn more about your users and develop the focus of your platform, the needs can change. The second challenge has been learning patience; I can't fix everything at once, and I can't wait for the big reveal to bring the pieces together at the same time. I've had to be okay with things looking shabby on one end of the house while I work on the other end.

I thought I'd throw my thoughts on this process out there as I work through it, a few lessons at a time, and in no particular order. It's always easiest to detail as I'm going through it, then I can go back later and assess and make patterns, figure out what's real, and rail on what turned out to be total crap in hindsight.

Lots of folks use Agile to modularize the development lifecycle, and keep a product lifecycle from becoming entrenched. I'm having good luck (so far) employing this same mentality to UI development. The product is constantly changing and evolving. Instead of architecting a long-term design framework, or creating a fixed experience based on an initial mockup, I've broken everything down to small, interchangeable components. This way, I can reconfigure and reshuffle to meet the changing needs of the interface, without abandoning core principles I defined as important to shape the integrity of a longer-term user experience, all without overhauling the code framework.

This may be a silly example, but take a simple header class. You could style a header very simply with a color, size, maybe a line height, some padding. You get the point. Or, you can style it in pieces, and use three classes to describe the same thing. Initially, this seems like code choke, but when you have these pieces broken apart, you have pieces that can meet the evolving needs of the system. Additionally, by breaking things down this way, I can repurpose applicable pieces from one system (Java-based) to another (Drupal) and begin bringing consistency to two unique products. In the end, this is cutting the code base by 25-30%.

This has been a really critical change for me and how I work with a complex UI. I've got an original, underlying framework that's built rigidly; specific styles for everything, so changing one thing impacts the whole ecosystem that relates to that object. By breaking down the building blocks, I can reuse and repurpose elements as separate components, and make sure that system functions integrating with core technology don't lock me in. Creating a jQuery expand-collapse function and applying styles to that call means you can't separate the function from what it looks like on screen. Creating an object that has a expand-collapse function, then an expand-collapse style means it can respond to the different page needs in your interface. And I can reuse the function and apply a different style to repurpose elsewhere. I can maintain original code base on areas we're not overhauling yet, while making improvements to the UX and design framework, all without losing overall integrity and consistency. Working with good developers who have similar goals has been critical to this process.

I had a really large "oh, shit" moment the first time I saw how quickly I could get locked into an inflexible UX framework.

I know to some folks this seems obvious. To other folks it seems like a waste of time. I've been wireframing for about 11 years to varying degrees, but with web applications, wireframing is now ultra-critical, mostly due to lesson 1. One poorly executed div class can get perpetuated throughout a system, and pretty soon you've got duped styles and workarounds just to maintain the overall integrity of the user experience.

When integrating with technology needs, I do basically two wireframes for the same display. One wire may outline the objects, actions, inputs, etc. required for the developer to understand the page functions and use cases. The other is an overlay outlining the classes, ids, divs and spans associated with the page elements.

This idea came from one of our Java developers ("hey, what the hell do you want to call these things?"), and it has served to keep me honest and ensure the integrity of the underlying structure. It forces me to think about how the code will get put together, not just structurally but functionally. It helps everyone recognize the overall strategy for the UI, develops patterns in how we talk about the UX, and has helped everyone become more familiar with the intricacies and requirements unique to the code base.

There's more to the user experience than just what you see on the surface. If you cover a pile of shit with roses, it may hide it, but it's still gonna smell. Which really, is a terrible analogy, but you get the point.

This sounds like arrogance. It really boils down to time in the trench.

I guarantee that I spend way more time obsessing over the nuances of user experience and mentally griping about what works and what doesn't, and picking over people's analysis of interface and UX design. As a bonus, I build the stuff, so I kind of know how it works. It doesn't make me the best out there (there's always lots of folks who are better, blah, blah). But it does mean I know a lot more about what makes a good user experience than someone who dinks around on Facebook, buys some pants at JCrew and pours through feeds a few hours a day.

Read Gladwell's book "Outliers" and you'll get what I mean. I'm well past the 10,000 hour point.

Okay, maybe that does sound a little like arrogance. But I spend a lot of time thinking about usage patterns and scenarios, and what they mean. I'm pretty sure Mr. CNN does not.

This made me nuts for years. I spent quite a few years keeping myself in check; trying to feel for the user, understand them, and anticipate what they needed. They're the user, after all. And I found myself annoyed a lot at feedback, and occasionally implemented things that really shouldn't have been implemented, cos I didn't want to bulldoze my way. Nine times out of ten it backfired. It's like a crack in the dam. Once it's there, it gets harder to stop the flow the wrong direction, and hard to get back to a dry riverbed.

Now, that doesn't mean you shouldn't give a crap about what your users think. You must have the ability to determine what's critical and what's not; what can be compromised and what can't to preserve integrity. You should identify and understand the root of the issues, figure out if it's a legitimate concern, and make a decision. Don't rely on the users for a solution, but understand and address their concerns if they have impact. You need to have passion and focus, and you need to trust your instincts. Understand you're not always right, but you should have conviction. Your conviction will translate to your user's conviction.

+++

I've been lucky to work with very good people over the years, and it continues now. Even though it feels like I've been doing this a long time, I'm constantly learning from the folks around me. I'm still learning every situation is unique, to evolve how I do things, be open to new ideas, and stand up for my instincts.