Anti-Skeu is Still Tail Wagging

Navel GazingI originally was going to put a picture of my own navel here, but I just couldn’t bring myself to do that to ya. This pic is, according to wikipedia, the official representation of the human navel. So there you go. Okay, now look back over here.

Why a navel? Because I just stumbled upon yet another anti-skeuomorphic article by a designer. (Argh!) And if there was ever a fit of navel gazing in the design community, it is this one. The funny sad thing is that even when we try to not gaze (as this fella is), we do it.

This article is so paradoxical. It says it is not anti-skeu, but the bulk of the article is critiquing just that. And in its critique of skeuomorphism, it makes the same mistakes it is critiquing. It dances around and even says some good things, but then falls into the same trap that those who use skeuomorphism as a way to show off do.

Great experiences are the sum of multiple factors. Any one thing being off can ruin the overall effect. Content and context, focus and environment: they’re inseparable and necessary parts of the whole experience.

Software experiences aren’t just software; they’re also about the device. Alan Kay was right: “People who are really serious about software should make their own hardware.” We can’t literally do that, but we can accept that the hardware is part of the user’s context when using our software. The two exist in symbiosis, to create the user’s context.

The first paragraph is spot on. The second one rapidly falls off the cliff. Hardware and software by no means “create the user’s context.” The user’s context is a function of many other things, such as physical environment, mental state, personal history/experiences, current desires, other people they are engaged with, time of day, and so on. But that’s not the real issue.

The real issue is there seems to be an underlying mentality here that is problematic, one that does lip service to the human experience with designed things while fetishizing the designed things themselves–in this case software (and/or hardware together). When the designer’s focus is still the object–the thing we are designing, whether that is software or  something physical–then we still have a case of tail wagging.

When it comes to a question of tail wagging, it is no different to expend your designer expertise and effort to create a thing that is “true” to its medium than it is to expend that expertise and energy to create a thing that mimics something in a different medium. Both are subject to the same navel-gazing dangers because both are fundamentally focused on designing a thing according to some designer-appreciated principle. If in the past designers looked down on each other because a design wasn’t skeuomorphic, today they look down on each other if a design isn’t minimalist. You can just as easily show off how properly minimalist your design is as you can how skeu it is. In both cases, the focus is on things and designers’ pride in having designed those things.

Who bloody cares if a designed thing is “true” to its medium if the people it is designed for don’t like it or have a hard time engaging with it. It’s one thing to say that you want people to be immersed and not think about the thing, but then if you turn around and just talk about making the thing “true,” you’re still missing the point. People don’t want a chromeless photo browser–they want the experience of remembering what the photos call to mind. People don’t want a flat, clean calendar–they want to situate themselves in time and keep track of things in relation to it. People don’t really even want photos or calendars–the things–they are simply a means to an end.

“Content over chrome” is missing the mark. “Being true to your medium” is missing the mark. It’s all designer fetishes and fads. The only reason there is good in them is inasmuch as they, incidentally, cause the designer to better evoke the experiences that people want. You might say that’s the whole point of minimalism, but I say that 1) you can evoke those experiences with or without minimalism, 2) sometimes you can even do it better, and 3) why obscure the real goal with a goal focused on the things? It’s just as simple to ask yourself “does this chrome distract from the experience I intend to evoke for the people I am designing for in such and such a context?” as it is to ask “is this design ‘true’?” And the first question is actually more to the point and doesn’t put the focus on adhering to principles that may or may not incidentally answer the first question, which again, is really the question you should be asking.

If a design that looks like a paper book and imitates turning paper pages evokes an experience that people want–it is a good design. If it surprises and delights people, even better! Who effing cares if it is skeuomorphic or minimalist or whatever other fad, trend, or school of design it is? If that’s what you’re worried about, you’re doing it wrong.

As someone who is something of a freak in the Design community, maybe I find it easier to see it from an outsider’s perspective. One thing that I was surprised by was the tendency to embrace fads and trends. “That’s so 2004” is a valid criticism for many designers. One year big rounded jelly bean buttons are in. The next year straight edges with reflections are all the rage. Now “flat” is in and with that is “anti-skeu.” I get it; the need for novel stimulation is a built into the human psyche, as is group belonging and the desire to feel superior to others (i.e., to feel valuable).

Being fashionable is certainly a valid consideration to have–all other things being equal in terms of designing for people and their contexts, you might as well be fashionable to boot. But if you’re going to adopt minimalism, at least do it for the right reasons (i.e., not because it is fashionable to be anti-skeu), and don’t get so caught up in it that you lose sight of what really makes a design best–that it fits what the people you are designing for want and/or need.

Advertisements

I’m My Own Worst Enemy

I Can Code

I’m something of a freak, though certainly not unique, in that I started my career in software as a developer and am now far more on the Design/UX side of things. Not only that, but I was one of those untrained/uneducated ones with no CS degree that jumped on the dot-com-bubble wagon to break into the industry. For years, I worked my way up through the ranks, learning on the job mostly with the smattering of self study here, conference/training there.

So it was only natural to me, when given the opportunity, to jump on the UX bandwagon several years ago. Again, I find myself a foreigner with no formal Design or HCI or library science or psychology education (but hey, I did take Psych 101 in college!). But I’ve done a good bit of self study, here and there under the mentorship of “real” UX pros (ya know, the ones with the PhDs and MAs and such). I now have several years of experience under my belt, and I had something of a unique opportunity working on Indigo Studio, an interaction design and prototyping tool, to really research and study the discipline/practice/field of UX and Design. That opportunity has given me a lot of exposure and insights into UX/Design that I know I wouldn’t  otherwise have.

UX for Devs ManifestoAlong the way, I’ve been (and still am) an advocate for developers spending time and effort learning about and practicing, when necessary, UX principles, techniques, and processes. This is because today, still, the vast majority of software being built does not involve UX professionals, or if it does, their role is often minimized and marginalized (they have to fight for their lives, or at least for good UX). In the end, devs, being the ones who build the stuff, have dramatically more influence in most cases over the actual UX of software. This is not going to change anytime soon. Maybe not ever. It’s reality. Deal with it.

And yet! And yet, despite my position advocating for devs “doing UX” and despite my bad example as a dev turned UX guy, I have learned enough in these many years to know that designers are indeed a different sort of animal. They think differently about problems than devs–significantly so. They employ different approaches when tackling issues. Heck, there’s a whole thing called “design thinking” that has sprung up around this notion. And not only that, just like every other professional, professional designers learn and hone their expertise over years as they practice. It really is a profession, a discipline, a field of expertise.

And that brings me to the image at the top of this post. (This is an actual shirt I made at one of the T-shirt sites.) It’s funny on a superficial level, and on the level that people can remember actually writing BASIC programs like that. But the underlying thing is–does being able to write lines of code really mean “I can code!”? Does that put me on the same level as an experienced and (possibly) formally educated developer?

That’s patently and obviously absurd–being able to perform one (or even some) of the basic functional activities involved in a profession does not make one a professional in that discipline. Do people who can give themselves shots claim to be doctors? Do people who represent themselves in court for a traffic citation claim to be lawyers? Does being able to shoot a firearm make me a policeman? Obviously not! I can install GFCI outlets like nobody’s business, but I hardly consider myself an electrician.

And yet this is precisely the attitude taken by those who dabble in Design. Being able to sketch UI ideas on a whiteboard doesn’t make someone a UX professional, but you’d never know that by the way people are eager to second guess and criticize professionally designed UIs or by the way they clearly think that their opinion on a UX design is as weighty as a seasoned UX design veteran.

This is particularly troublesome when dealing with what I’ll call “design smell” (lifting the concept of “code smell” from the dev world). Sometimes–often–an experienced designer can consider a design and immediately tell there is something off about it. Sure, there are heuristics, and principles, and testing, and metrics, and so on that can give definition and language to talk about the bad smell, but not always, certainly not always to everybody’s satisfaction.

Maybe they subconsciously recognize things about it that are just asking to go wrong, based on their distilled knowledge, skills, and experience. Or maybe they had more exposure to what went into a particular design–so what is being considered is something they already explored or something conflicting with their sense of propriety for the problem at hand in the context it is in. The bottom line is, maybe the designer can explain it in a way that resonates convincingly with others and maybe not. But sometimes you just gotta defer to their judgment and rely on their expertise. 

My Ivory TowerNow don’t mistake me. I’m not suggesting the all powerful designer dictating from on high, but judging from a very common theme amongst designers–complaining how everybody thinks they’re designers–I think it is safe to say we are squarely on the other end of that particular spectrum, especially in software. People–particularly those who consider themselves smart and talented (and maybe are)–naturally assume that if something doesn’t make sense/resonate with them, then it must be wrong.

And yet, when those same people think about it in terms of their own expertise (or maybe other expertises they have less of a clue about), they obviously can see that people should respect their expertise and defer to them. Something is broken here. What I’m suggesting is that those who work with designers need to keep this in mind and move the needle further to the respecting designer expertise side of the spectrum.

The fact that I have made this transition from dev to UX pro makes me my own worst enemy in this argument, though. What folks may not think about is that this multiyear, full-time professional journey has really warped my thinking. I may not yet (or ever) be in the same mindset as a formally educated, “untainted” designer, but I have had a lot of time and opportunities that have changed my thinking and given me a lot more Design knowledge and experience to draw on than I had before I started this journey.

And despite that, I maintain what I consider to be a healthy seed of doubt as to my own tendencies when it comes to tackling problems and designing solutions using, shall we say, a pure/disciplined Design approach. And if I still do that after years of practice, self-study, and mentoring, maybe folks who lack pretty much any background in UX should doubt their own design skills and defer to experienced designers?

LOL. Who am I kidding?!? Everyone’s a designer, right?

My Job is Bigger Than Your Job

Superhero Me!I’ve been in software for a while now. I started out on the dev side of things, and within that are the folks who like to use the term “architect” to connote how they have the “big” view of things. There were those who advocated for the “architect” role to be more and more involved in business, move up the chain, etc. Because of course, they are uniquely suited to help the business achieve their goals.

Now I’ve been in “UX” for a while. And there are those who like to use the title “architect” there as well. And yes, there are those who advocate for UX/Design to move up the business chain. Because of course, designers are uniquely suited to help the business achieve their goals. UX is everything of course. (That is a truism as far as I’m concerned.)

I’ve also interacted with folks on the branding side. They may not use the term “architect,” but they do have this sort of “brand is everything” kind of mentality, and of course, they also are uniquely suited to help businesses achieve their goals.

So I had to chuckle today when I read in this article about the “website architect” role that “goes beyond — or rather encompasses — the user interface, user experience, and information architecture of the site” and “needs to have a solid understanding of usability, in-depth knowledge of web development tools, online marketing technologies, and everything else involved in the construction and maintenance of a website.” Okay, so now “website architecture” is everything, and doubtless this role is also uniquely suited to help businesses achieve their goals.

Anybody see a trend?

The funny thing is, to an extent, they’re all right. Considered from certain vantage points, they all are uniquely suited. Any good CEO would want to leverage that unique special sauce from each one.

On the other hand, they can’t all be “everything.” They can’t all “encompass” each other. That aspect of it seems to be simply power grabbing–my discipline, my job, my title is “bigger” than yours. It encompasses yours. It is more important than yours.  (And thus I should have more say in/control over what gets done.)

There was a time in my life when I was enchanted with the term “software architect.” I admit. I used it. But I have become increasingly disenchanted with it, as I see more and more people grabbing at the “architect” title and crafting a role with it, more or less as a way to say, “my job is bigger than yours, more important, more encompassing, and thus what I think/say is more valuable to the business.”  Now if someone tells me they’re an architect, I sorta cringe.

Everybody needs to just slow down and take a breather. How about we each acknowledge each others’ distinct special sauces and work together to make better stuff? We need mutual respect. We don’t need to imagine that our expertise supersedes and encompasses others’ expertise in order to be valuable and meaningfully contribute. Of course, the saving grace here is that in the end, it is the business itself that is in charge, and a good leader of business will do just that–get surrounded by folks with expertise in all these areas, encourage cross-discipline teamwork, and help ensure that everybody is moving along towards the same shared vision to achieve their goals.