But, despite all that, that project was a failure from a UCD and “business” perspective. Firstly, the interface felt too much like Flickr. Then, our team was fairly novice so our interview data wasn’t very promising. This caused the personas to feel sort of half put together. The end result was somewhat lacklustre – in some ways, we could’ve delivered the same thing by getting inspiration from other websites and not having to use Cooper’s Goal-Directed Design.

However, to stop there would be to completely miss the point.

Introducing UCD – the first round might not count

I insisted on using a UCD process not because I wanted to deliver something spectacular, but because I wanted the team members to see the value of a UCD process. Or, perhaps more accurately, it was mainly just me who was keen on seeing the value of a UCD process (and to see if I could do it).

This is where I think a lot of projects tend to reject UCD – when they can’t see any results.

It’s easy to run a company with an “efficiency” mindset – it’s sort of built into the status quo. Everyone is reluctant to change – not just management. So, I didn’t just have problems with my line manager – I had problems with my team members. (thankfully, my interviewees were really helpful). No one except for myself was really looking to see this succeed.

So, of course – how could I expect it to succeed?

The process reveals not so much results, but opportunities

The effort of building applications is often a team effort – not just one UX person calling the shots. But valuable lessons can still be gleaned from UX failures, much more than they can from plain old technical failures – mainly because that additional perspective from the user is so raw and tangible that it almost creates some kind of “why haven’t we done this earlier” response?

When team members get thrown into a UCD process – they don’t realize the potential “failure” of the outcome, they look at the process and the value of that access to users they finally get – something they never used to have in the past. Suddenly, they realize it is possible to build applications based on user research, user feedback, and purposeful design.

Developers and designers all need to realize that there are many ways to build an application, and sometimes it makes sense to learn a new tool so that the right one can be used for the right job. Introducing UCD to a conventional software team can sometimes help them gain ideas to make things better.

I took those lessons I learnt from the failure with me, because you never unlearn an experience like this. You just get better. And now I realize just how much more UCD is like craft than science.

For one, I am currently working with rey who’s coding up the front-end for a site we’re building. And bad habit of hacking up layouts with inline styles has driven him up the wall. I’ve recently made the effort to migrate my styles into our stylesheets, but only when I was styling up a panel quite seriously (as opposed to just using HTML markup and existing styles).

Reusable CSS isn’t quite like reusable code

The gap that I had crossed was this idea that it’s okay to create a style that’s never going to get re-used.

For the longest time, I was using inline styles because it was quick and dirty, and for the most part, many styles were bespoke. I felt that only reusable styles  should be put in a stylesheet. It’s one of those coder things where we like to build reusable components and keep them organized and use them in what we call an architecture. But I had to put that coder thinking aside for awhile, when it came to CSS.

The reason is because styling up a div one way doesn’t mean it looks right when it gets placed in another section of the page. The effect of one small change in one component can and will affect the feel of the other components. This is not just true in terms of the visual layout, but also in CSS – because there are cascading styles that will enforce itself upon any child components.

In an object-oriented programming paradigm, extending a class or object is often an act of empowering (decorating) that object based on elements inherited from its parents (a very bottom-up approach). But in CSS, it almost seems like the reverse when you don’t necessarily want to inherit from a parent element, unless you had a very intimate understanding of the way it was styled from the top-down.

Approaching a user model

Rey uses the term “semantic” a lot when he’s talking about CSS, referencing the act of naming a class based on the purpose of the component that was being styled. Again, this is partly contrary to the way system-thinking works, where you often name it based on a process (e.g. Data Access Object, FileFactory). This other gap I had crossed was about having a user model vs. a system model (which Norman talks about).

The issue here isn’t so much about whether I was naming a CSS class inappropriately, but about the way I viewed my styles with respect to the design of the site. In short, I would be thinking of the site the way a viewer would think about it – an about page, a contact list, a article side-quote, and so on.

Interestingly, CSS would ‘encourage’ me to think in terms of how different components looked and ‘felt’, nested in other components or on a different markup tag. For example, an article side-quote within a blog post vs. outside a blog post. Or a quote within a div or a span, or as a link. Or as a link within a span? Or as a list?

To a programmer, there’s a point where all these elements look like plain-old boxes. But to a designer, they’re like specialised tools that are meant to be used one way and not another. And I believe it’s because designers have a greater empathy for human beings – how we view, organize interact with and consume information.

What the books don’t tell you

I’ve been frustrated by many books on the subject of technical languages like PHP, CSS, and so on. Simply because many of these books completely ignore the fact that there’s an art of programming that can’t be communicated by instruction. It is this art that sets apart good designers and expert designers, good programmers and expert programmers. And this makes the difference between Ruby and Kohana and Django – not that one is particularly better than one another (trying to avoid flame bait here), but that the frameworks have been designed to appeal to a specific type of programming “art”.

Although there’s only “one” CSS (albeit with multiple revisions), there’s still many books on how to write CSS, and different authors will present their formulas based on their own design habits. Some are comfortable using CSS hacks, while some are strong advocates of reusable patterns, but this quote from Alan Cooper keeps coming back to me – that programming is craft and all software is bespoke.

So, there’s never going to be a one-size-fits-all solution. Ultimately, all programmers and designers have to lean on their craftsmanship in order to determine the right solution.

And I still haven’t found a book that helps me do that.

The reason why I feel this is frustrating is because many other crafts like painting or architecture or photography actually have books like that. About the art of the craft. Even some business books are dedicated to just that – the art of business. But almost 99% of the books out there on CSS, HTML, etc. are instructional, not inspirational.

Community as our last hope

Alas, one thing developers and designers do have is the technology itself, not as a solution itself, but as an enabler. I think that if we are going to reach a level of maturity in designing applications the “right” way, it will most likely be facilitated by community interaction, rather than plugins, frameworks or cut-and-paste code snippets.

The reason I say this is because every few months or so, a new browser version is released, a new styling standard has been established, or Microsoft continues to fail in delivering standards-based compliance and even makes it inconsistent with its previous browsers. And the only way we can survive this madness is if we work as a community.

But I am finding it difficult to meet (or fearful of meeting) people who might be willing to mentor me in CSS, of all things. And I assume experts think most web designers out there want cut-and-paste code. In fact, most articles I come across, with a few exceptions, are like that – catering for the cut-throat, deadline driven, plugin-frenzied, shock-effect designers and developers who want all of life’s problems handed on a silver platter.

There’s a lot to be said in the world of CSS, but as long as it’s not catering towards proper craftsmanship, I’ll be doing it the hard way with my bare hands and peering through the grapevines.