Menu

I am Alex Maughan.
A user experience designer trying to understand human experiences.

17 November 2014

Cross-domain thinking

architecture

I enjoy theoretical connections across different knowledge domains. I like finding commonalities and leveraging those commonalities to communicate an idea or, if I’m being honest, to forward a particular agenda.

Similarly, I enjoy reading and listening to others who have the same inclination. Any discussion that breaks across predefined sectors to solve a localised problem is one of my happy places. I’m, therefore, quick to metaphor and a bit too hasty in forcing out an analogy to make my point. Any number of articles on this site would be testament to that.

Although moving across domains can be very helpful in providing fresh impetus or clarification, it should be accompanied by some healthy skepticism, or at least a rational realisation of the limited nature by which certain things can be seen to be similar. Different realities often require different approaches; they unavoidably necessitate a non-universal understanding of the specific problems they present. Not only can different domain thinking be appealing primarily due its novelty (as apposed to being intrinsically better in any way), but not all solutions are necessarily transferable.

Architecture

One of the more obvious cross-domain connections made in my line of work is that between user experience design and architecture (as in, brick ‘n mortar buildings).

Being one of his trademark talents, Rian van der Merwe wrote a great unifying piece a while ago that called on three architecture-related resources.

One main point, the need to have a greater sense of propriety and permanence, resonates loudly with me. Move fast and break things is the realm of the careless; it is a sloppy excuse for bad planning and the consequence of lackadaisical problem solving. Some argue that a culture of on-the-go experimentation and less stringent deployment processes breeds faster learning and insights. I strongly disagree with this, for 2 reasons:

  1. Taking a deployment seriously and being strict about not sending more crap out into the world does in no way prevent those involved from experimenting and moving fast on non-production environments. The freedom to experiment and break things is not removed from the equation. Do this to your heart’s content, but don’t have the arrogant expectation that users should bear the brunt of this blind tinkering.
  2. The many difficult factors around software development do not mean we should be okay with breaking things. The complexity of our industry is no excuse to forget the basics. Too often the thinking is: It broke because we were moving fast. In my experience, this is not actually the case. Rather, It broke because we lacked focus, and we didn’t make sure certain critical foundations were solid and properly tested before moving onto less critical things. Too regularly, move fast and break things is just an excuse not to be systematic.

Beware of irreconcilable differences

Although the core analogy of responsibility in architecture is a great one, we do need to remain vigilant to significant, irreconcilable differences between software and brick ‘n mortar architecture.

If we get too hyped up over our analogies we can venture down a dangerous road of incongruent imitation. Managers could again fall into the trap of seeing software developers as non-creative unit shifters; that code can be produced in the same way bricks are laid; that x amount of time is needed to lay x amount of bricks.

We also risk becoming blind to the massively shifting landscape on which we build things. Japan’s earthquake-proof building codes have nothing on the amount of movement with which we have to contend.

More than this, we also risk misidentifying certain locales of meaning, making the assertion that meaning across these sectors is cleanly transportable, when it is in fact not.

People enjoy inventing slogans which violate basic arithmetic but which illustrate “deeper” truths, such as “1 and 1 make 1” (for lovers), or “1 plus 1 plus 1 equals 1” (the Trinity). You can easily pick holes in those slogans, showing why, for instance, using the plus sign is inappropriate in both cases. But such cases proliferate. Two raindrops running down a window pane merge; does one plus one make one? A cloud breaks up into two clouds – more evidence of the same? It is not at all easy to draw a sharp line between cases where what is happening could be called “addition”, and where some other word is wanted. If you think about the question, you will probably come up with some criterion involving separation of the objects in space, and making sure each one is clearly distinguishable from all the others. But then how could one count ideas? Or the number of gases comprising the atmosphere? Somewhere, if you try to look it up, you can probably find a statement such as, “There are 17 languages in India, and 462 dialects.” There is something strange about precise statements like that, when the concepts “language” and “dialect” are themselves fuzzy.

– Douglas R. Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

Does “1” and “1” equal “2” in our industry, or does “one cloud” when joining another remain as “one cloud”, only bigger? This different way of understanding numbers is just a basic example of how different realities are home to different meanings, which in turn require different ways of understanding those meanings.

I think cross-domain thinking and problem solving is extremely valuable. I also think using analogies to help communicate with one another is also very effective. However, we need to be wary of the irreconcilable differences between the domains we theoretically traverse. These differences can have real consequences on our day-to-day work, and if misaligned, can create more problems than they solve.

Failure waits quietly at the end of a journey of blind imitation.

16 November 2014

The design of Us vs Them

silo

Quite a while ago, I was asked to help with a tight deadline by creating an alternate design comp for a client to consider. I handed the static artwork over to the relevant person, who ended up not even giving it a momentary glance. It was never shown to the client. I asked why, and got told something about there not being enough time to look at it.

I was labelled as a developer in that particular context, you see, and developers, as you know, clearly know nothing about graphic design.

A few months ago I was a bit impatient about a basic feature not being implemented. I wasn’t frustrated with the developers – I knew they were busy on higher priority features. So I went into the application and wrote the necessary code myself. It was an unbelievably simple piece of code, about three or four lines of PHP that needed to be added to the correct controller. It worked, as expected, and I submitted a pull request on GitHub. The pull request was rejected. I asked why, and got given some vague answer about it being inefficient. I was initially apologetic – embarrassed at my inability to recognise that it was bad code.

So I delved into the method I used, trying to see what I had done wrong and how it could be done better. After a while (of my spare time), I gave up. I couldn’t see what was inefficient about it, or rather I couldn’t see a more efficient way of pulling it off. So, instead I decided to watch the Jira task associated with the feature, and see what the developers wrote and then learn from that. Over a month later the task was finally marked as done. The same developer who had rejected my pull request had accepted this one. The method used was identical to the one I had used.

I’m a maker of pretty pictures, you see, so there’s no way I should be allowed to muck around in their code.

Most developers I’ve worked with started off by identifying me as a graphic designer. Most designers I’ve worked with started off by identifying me as a developer. Very few of them, I think, ever truly changed their minds about this initial pigeon-holing.

I design digital products. Sometimes I use a pen and paper, sometimes Balsamiq or Gliffy or Axure or Proto.io. Sometimes I use Photoshop or Illustrator. I regularly use client-side code, like HTML, CSS, and JavaScript. I also use an array of server-side technologies to generate the former. Sometimes I use Jira or Trello or Spreadsheets. A lot of the time I just talk to people. I regularly say, I don’t know, and then read things about which I don’t know.

All of the above is design. All of the time.

The life of an embedded designer isn’t easy. You’re the piggy in the middle. You continuously have to sacrifice your ideals for the sake of the design. You’re the boring kind of designer, a member of that mythical club called, Design Is Something That Actually Works.

Design is not only a sketch or 3D rendering of a chair. It’s not simply the engineering of the materials used to make that chair.

Design is you sitting in that chair.

I just wish we could all get along, and treat ideas and work based purely on their merits. I wish we could just focus on making a chair that people love sitting in. I’m tired of neat labels for the sake of others, and I’m especially tired of my work being pre-judged based on that label. If the work I do is shit, by all means – pretty pretty please with a cherry on top – call me on it.

You may be a way better illustrator and graphic designer than I am, and you may know way more about software development (I don’t claim to be especially good at any of these things), but don’t disregard or impede my work because you have some broken idea about what design is. Point out what is wrong in my work, not that it is wrong that I dared to even do that work in the first place.

15 November 2014

On contradiction point

Do I contradict myself?
Very well then I contradict myself,
(I am large, I contain multitudes.)

– Walt Whitman

Why take the time to write about things so few care about? Why write things even fewer care to read?

It often comes from a genuine pleasure for discussing the merits of things in a detail that most conversations don’t allow. It’s a space that allows me limitless consideration. I genuinely work hard – although, I could work harder, it seems – at limiting this space.

Even though they always get reduced by at least a third, every piece on this site should probably be reduced by more than half their current word count. But I can’t help myself. Give me the space for consideration, and I’ll consider ’til the cows come home.

Ultimately, this online log of my thoughts is mostly a conversation with myself. It’s a gentleman’s debate between the many me’s; between the me I most often see and the me that is you, and you, and you. It is an argument between my multitudes, boringly subdued in industry specificity.

It’s a way of mulling over my many contradictions, trying to see if I can find a centre point around which these contractions can orbit less offensively.

This pleasure of venturing into greater detail is unavoidably accompanied by the need to share an opinion. An opinion too regularly becomes the centre point around which those contradictory considerations orbit, as it is a particular me that is trying to sell my efforts to a particular you. All these particularities sully the real point of all it. Consideration. Conscientiousness.

Consideration is the carrot and my opinions are the ugly whipping sticks.

My opinions are clearly not doing a very good sales job. Their figures are, in fact, hopelessly dismal. As the employer of these opinions, I should consider letting them go; admitting their redundancy. As the employee of these opinions, I should probably seek different employment.

But I’m a gutless fool. So, tomorrow, or the next day, or the day after that, I’ll most likely don my cheap polyester suit again and head off to try sell some more opinions in a saturated marketplace, while consideration sits quietly at home, trying to make ends meet for my many multitudes.