Category: User Interface (UI)

The “post-comp” era

A few days ago, I wrote about moving into the “post-comp” era in the web design process. I linked to a post by Brad Frost, and now Dan Mall has written a reply to that article.

As I mentioned in the comments, I think it’s an expectation problem. The typical workflow for web design projects is to send a client a “preview” of the site to approve before beginning development. This “preview” usually comes in the form of a comp that shows how a page might be laid out and often contains specific, pixel-perfect choices with typography, spacing, images, columns, and other very fine details. The problem is that this says to a client, “We’re now at a stage where we’re focusing on details.” It’s only natural that their feedback focuses on details.

A responsive design process is like a scandal. You’ve gotta pre-emptively control the conversation. If your client wants to have conversations like this, it likely means you didn’t do a good job of setting expectations.

As Dan points out, this expectations need to be set in the Sales process—at this point, the designer should be engaging with the potential customer and trying to establish the deliverables.

Rather than promising multiple rounds of page designs as some of the first design deliverables, we’re setting the expectation that the first things they’ll see are unstyled HTML to demonstrate content hierarchy and flexibility across various screen sizes and a few pieces of a visual style—works-in-progress and unrefined broad strokes, not polished visuals that call for critique at a fine detail level. That’s why I’ve grown to love element collages; they’re literal enough that your client can start to see a picture of things coming together but still enough of a work-in-progress that there’s no expecation that the site would actually look like this for everyone.

This is, in this age of multiple devices, simply not sustainable; in short, it creates false expectations for your customers.

To be fair, I don’t think we’re in a post-PSD era, but I do think we’re moving towards a post-“full-comp” era. I can’t envision a project where I don’t use Photoshop. Photoshop isn’t the problem. It’s a great tool. My favorite, actually. It’s the stigma that comes with presenting a full comp (I define “full comp” as an image of a website viewed on a desktop, typically around 960px wide). By default, presenting a full comp says to your client, “This is how everyone will see your site.” In our multi-device world, we’re quickly moving towards, “This is how some people will see your site,” but we’re not doing a great job of communicating that.

As an industry, we sell websites like paintings. Instead, we should be selling beautiful and easy access to content, agnostic of device, screen size, or context. If you can get your client to believe in the sales process that you’ll do that for them, they won’t care what the site looks like.

This is precisely right. Of course, when you are in a company that has a Sales Team—rather than the salesman being, principally, you—then the first people that you have to convince is the Sales Team.

As I mentioned in my previous post on this subject, we have just started moving our first customers towards this process; however, we are feeling our way to a certain extent and not yet nailed down the outputs.

Yes, the projects on which we have deployed this process do seem to be going fairly well: however, we need to firm up the process very swiftly now—and then sell it to our Sales Team.

I am absolutely convinced that we are moving into a post-comp era and that it is going to lead to far more satisfying results for both designers and customers. However, it needs to be presented in the correct way, and both sides need to understand the deliverables. In short, expectations need to be sold, set and delivered.

I will continue to update you all on how it goes…

Solving problems in a framework

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.

Designing within a framework, understanding multiple customers’ needs, taking account of possible future developments and, thus, solving problems in the most elegant way are what give me pleasure in my job.

And deriving that enjoyment from such is what makes me good at what I do.

 

* 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.