But, how is it supposed to work?

UI/UX developer. Its kind of an interesting title, isn't it. My experience has been that it often seems that people make the assumption that because our work is on the user interface, we're really only concerned with delivering stuff that looks a certain way.

Well that seems like a pretty broad, sweeping generalization...why would he assume that?

Why? I say that because more often than not, the only requirements artifact that I get for a job is either a design composition or a wireframe of some sort. "Here, this is what we had in mind..." It typically ends up being something like a Photoshop comp, maybe a PDF document...sometimes even just a PowerPoint file with some slides that give a generalized idea. Whatever the case may be, the vast majority of the time, the only thing I get to work from is something that tells me what the user interface should look like.

OK, yeah...sssoooo...what's wrong with that? You're a UI/UX developer right, what more do you need?

Let's look at an example...

This is a great example of a wireframe you might commonly see as part of the requirements artifacts for a UI/UX project. The problem with it is what's missing. All too often, something like this is all a UI/UX developer gets as a requirements artifact. So lets talk about whats missing here...

Look and feel

We'll start with the obvious, and less common example. When I say less common, I mean that its less common for this to be excluded or left out. Most often, a wireframe such as this would be accompanied by some kind of style-guide documentation that would describe the look and feel of the UI elements as well. That doesn't always happen, unfortunately, but generally the client has at least some kind of idea of how they would like it to look and feel. Most unfortunately, however, is that this is typically where the requirements for a UI/UX project stop. More often than not, the most important and time-consuming stuff is forgotten and not delivered.

Functional specs

I honestly don't understand why this is the case, but very commonly, this requirements artifact is overlooked or forgotten. For me, its one of the first things I notice when I look at the wireframe above. Functional specs answer the question: what is it supposed to do? Consider some of the elements of it...

Note that there are a number of hyperlinks on the page, for example...what's supposed to happen when each of them is clicked? The problem here is that too often this behavior is assumed. However, especially important in this day of modern web and single-page applications, it has never been less clear about what should happen when a hyperlink is clicked. Hyperlinks can no longer be assumed to simply synchronously link to another resource on the domain, or elsewhere. Often, they now represent the initiation of some asynchronous operation or interaction with the page that involves never leaving the current page at all.

The same can be said of any/every other control displayed on the wireframe. Controls represent elements of the application that allow a user to interact with it. Because of that, requirements for UI/UX projects need to include details about what those interactions are and how they should work. What should happen when the user clicks the "Go" button in the "Search" block? Should anything happen when the value of the "music" dropdown in the "Search" block changes? These kinds of questions need to be asked and answered for all user interaction elements in the UI.


This one, strangely, in my experience, seems to be the most commonly overlooked of UI/UX requirements artifacts. This answers the questions: where does the data to support this application come from and how do I get to it? This stuff is actually really important. Consider the values of the "music" dropdown list in the "Search" block...what are the possible values for it? Where do they come from? Are they dynamic, or are they static, hard-coded values? What about the items in the "Choose an album" list? For most developers it will be fairly obvious that much of the information displayed on this wireframe will ultimately be dynamic in nature. The data will need to come from somewhere, right? We need to know...where is it going to come from?

In the case of most modern web and single-page applications, that data will need to come from some kind of server API. Does one already exist? Is/will one be/ing created? What kind of interface will the data come from, and in what format will the data responses be in? What parameters and data should requests to the API include, and what format should they be in? What do the API URLs look like? Is it an HTTP or REST based API, or is it SOAP? Will the responses be JSON or XML? As you can see, there are a lot of variables here, and this needs to be thought through very thoroughly.

Saving time and money

Ultimately, the goal here, is to help people understand what we as UI/UX developers need to know in order to be able to deliver what you need. We will eventually need to know all of the above at some point. Identifying the answer to these questions as early in the process as possible will help save everyone both time and money, and will help clients get what they need faster, and with less process and code churn. This is really what we all want, isn't it?