Wednesday, January 9, 2013

Designing software

Ian "Hixie" Hickson, editor of the HTML "Living Standard"* at WHATWG, is one of the most influential people on the web today. HTML5 Doctor has a very interesting interview with him, but I wanted to highlight one passage in particular.

In my day job, I usually describe myself as a web software designer. Trying to describe what that means is usually a little tricky: there are, of course, aspects of User Interface (UI) and User Experience (UX)** design in there; I also bring in some Information Architecture, a degree of HTML and CSS mastery (though, alas, my Javascript is pretty basic) and a great deal of market knowledge.

However, there is one passage from Hixie's interview—in a context not entirely unrelated—which pretty much sums up the nitty-gritty of what I do.
Often when people send feedback (not just authors, pretty much anyone who hasn’t been in the process for a long time starts this way) they send feedback along the lines of “I want to add feature X” or “I want feature X to be extended in manner Y”. But when we drill down, ask them “what problem are you trying to solve”, or “what’s your use case” (same question but phrased differently), we often find that either (a) they actually don’t have a real problem, they just thought that it would be a good idea, or (b) their solution wouldn’t actually solve their problem. Often we’re able to come up with much simpler solutions (or point to already-existing solutions), which is quite satisfying.

Like Hixie, I am working within an existing framework—our Enterprise Content Management Framework—and, when a customer requires some new piece of functionality, I need to take into account what others have fed back and how to best solve their problem within our existing framework.

Luckily, we designed and developed the framework fairly recently—and in response to existing customer requirements—so often we can point the customer to an existing function that solves their issue.

However, when that isn't the case, I never rely on our salesmen or, indeed, the customer's own specification. Whenever faced with a development request, my first question is "what is the driver", i.e. what is the problem that they are trying to solve.

Being able to solve those problems in the most elegant way is what gives me the most pleasure in my job.

* Otherwise known as HTML5.

** There's a school of thought that maintains that there is no difference between the two; indeed, many hold the opinion that any way in which customers interact with your company or its products is, in fact, UX.


Barnacle Bill said...

Job satisfaction, it's something I don't think the piggies at Westminster understand.

Kevin Monk said...

I've always referred to this as "popping the Why stack".

If you're interested there's a good book called "User Stories Applied" by Mike Cohn. Probably one of the most thumbed books on my shelf.

The same thing applied In a UI/Graphics context is this video about "Designing with forces" by Ryan Singer that covers the book - 'Notes on the Synthesis of Form' by Christopher Alexander.

The book -

I'm sure you've seen this stuff before but you hit one of my favourite subjects so thought I would share some of my favourite stuff.

Rich Tee said...

I've just started a job with a company that supplies software to doctors.

At the moment I just fix bugs in it but I hope to be a developer soon.

I do work on the code that stores medical records so I am getting an interesting perspective on the issue...

Anonymous said...

As a systems designer from decades ago, my starting point with business users was "The answer's Yes, now what's the problem ?"

It was a good way to get them to expose the real issue they were trying to solve, rather than presenting their own half-baked view of the solution.

MessageSpace Adverts