This analogy goes out to all you recruiters charged with hiring a Visual Designer but who end up talking to a UI Developer. Or maybe you’re looking for an IA, but end up talking to a UI Designer. These roles are all related but distinct and contractors such as myself understand that you don’t always have the time to become an expert before you start making phone-calls. Well, most of us understand.
What all these roles share in common is the goal of creating software. Of building it. Building software in many ways is like building a structure. It requires a number of specialized skills and proceeds in a sequence of logical steps. There are still parallels for a scrum/agile development environment, but this analogy works best for the waterfall model of software development. And while we’ll have an analogous role for every step of the process, we’ll be focusing on those that relate to the interface ( see this Blog’s title ).
Let’s say you wanted to build a building. What would you need?
A reason, right? Why would you build a building for no good reason? What’s it for? Who’s going to use it? Who needs it and why? How would it make you money? What’s the impetus for its construction? If it’s a dam and the low-lying country up-river is a flood-plain, the reason is clear. If it’s just another gleaming skyscraper, the reasons could be more nuanced: Who’ll rent your space and why? What makes your gleaming skyscraper better than all the others? In software design, this is the business need: "Our call center people aren’t cross-selling our other products when they get customers on the phone." Or "We want our customers to provide the documentation we need from them online and how can we incentivize them to do that?"
Okay, you’ve identified a need. What next? Money. Someone to pay for it all. All those men and materiel aren’t going to pay for themselves, right? In corporate software design, these are the project’s sponsors. They allocate the funds necessary for your skyscraper of an online spreadsheet app to go up on the information superhighway. Or if you’re building it for someone else, your client is the sponsor.
So now you’ve got a reason and you’ve got the cash. Would you just start building and hope for the best? Unfortunately in software design, many do. But if you’re building a skyscraper, there’s still a lot to do, right? Gathering up all the little reasons that this skyscraper will be better than the rest. Everything it will need to do. You’ve promised your potential tenants that their electric bill will never exceed a certain dollar amount because you’re putting solar panels on the roof. You’ve promised the city a train station in the basement. You’ve promised your investors you’ll be renting at 80% capacity ten weeks after the grand opening. Who handles all this in software design? The Business Analysts (BA) do. They produce what we in the software biz call requirements. What will this app be required to do. What business needs must it address to justify its construction? Let’s settle on a list of these many, many things that we can all agree upon. This final list is the requirements.
And who keeps it all on track? Who keeps things moving according to schedule and ensures the finished product meets the requirements? Two roles come in to play here and coincidentally, they are identically abbreviated.
The Project Manager (PM) oversees construction but moves on after the building is finished. They’re like the foreman of the construction site.
The Product Manager (PM) is like the building’s manager when it’s complete, overseeing all operations and coordinating all parties involved. They do NOT move on when the building is finished, but stay in charge of it indefinitely. The only difference is that in software design, the Product Manager is typically involved from inception and through construction.
Now things get interesting. You’ve got the why and you’ve got the what. Now all you need is the how. How will your skyscraper meet these many requirements? Answering this question takes a plan. A blueprint if you will. You wouldn’t just start building a skyscraper without first knowing what it should look like when it’s finished, would you? Sadly, many software development teams do just this. I have looked on in profound amazement as the construction workers rush in and start pouring concrete for a foundation to a building the size and shape of which hasn’t been decided: developers iterating on code no one’s even sure should or would be used: code that’s written before a blueprint for the application has been settled upon. And who makes blueprints? Architects make blueprints. In software design, these are the Information Architects (IA) and their blueprints are called wireframes. Like blueprints, wireframes are a schematic. They describe components and how they relate to each other. But IA’s don’t operate in a vacuum any more than building architects do. An architect may have a general plan for a building, but may not be an expert in construction material and methods. He or she may not understand the electrician’s job or the plumber’s. An architect may not understand interior architecture, interior space design, lighting, interior design or ergonomics. A stairwell included in the architect’s blueprint might be the most basic kind of stairwell. And others will be consulted as to its specifics or indeed, whether an escalator is more appropriate.
So now you’ve got a building with a number of darkened and empty or generalized interior spaces. Here’s where the User Experience (UX) Designer comes in. Just before construction was about to begin on a new building at Ground Zero in New York just a few years ago, the New York Police Department got a hold of the plans and stopped the whole thing in its tracks. The entranceways, they warned, were way too close to common public areas, making them much too vulnerable to a possible terrorist attack. The entire blueprint was scrapped and it was back to the drawing board for everyone. In its most drastic form, this is the kind of consideration it falls to UX to account for. The human component. Can this software ultimately be used by its target audience? Should this stairwell be a ramp? Should this screen be a dashboard or a wizard? Are these windows so close to the air conditioning units that they’ll produce a sound nuisance if double-paned glass isn’t used? Should these selections be made by radio button or check-box? Etcetera, etcetera. Typically, this just means adjustments to or elaboration upon the wireframe documents already produced by the IA.
What’s the difference between a UX Designer and a User Interface (UI) Designer? In many contexts the distinction is next to meaningless. It all depends on what you’re building. Is it an aircraft hangar or a luxury casino? Airplanes don’t care where they’re parked. People do. The differences between UX and UI designers are subtle, but critical. If you’re building a luxury casino, you’ll need both. The UX designer can tell you what kind and how many slot machines the main floor of your casino was designed to accommodate. How they should be arranged generally to maximize their profitability in relation to foot-traffic patterns. The UI Designer will compare this scheme to the other casinos in town and solve for user expectation in relation to these competitors. The UI Designer will solve for overall polish and curb appeal. How what these screens are trying to accomplish are translating over to what the user actually ends up seeing. This includes especially look-and-feel. In the UX Designer’s mind the gambling floor is a series of simple spatial relationships between types of objects solved for the gambler’s most general reactions to these. To the UI Designer, it looks like rows of fully-realized slot machines each eliciting very specific user reactions. Specific sights, specific sounds. If the UI Designer finds a flaw in the overall design, typically that complaint can be communicated to the UX architect, but not the IA so the wireframes are not impacted. If, on the other hand, the UX Designer finds a flaw in the overall design, that complaint CAN be communicated to the IA and the wireframes MAY BE impacted. You don’t need to redesign a lobby if you’re having trouble arranging the furniture effectively. You do need to redesign it if the exit violates a fire code.
The UI Designer often relies so much upon the Visual Designer to effectively acquit his or her responsibilities, these roles are often combined. Again, it depends on the scope of the software. If your product is competing with Microsoft, you’ll want both disciplines. If it’s competing with the IT Boutique up town, you may not. It’s yet again a very subtle difference that can best be illustrated by staying faithful to our metaphor. An interior space designer can tell you how the tables in your restaurant ought to be arranged for maximum efficiency. A visual designer can tell you what furniture to arrange and whether or not it fits into your restaurant’s overall theme (though they’ll probably have something to say about your arrangement, too). Each could probably do the other’s job to some degree of adequacy, but when your software must be professional on every level, the distinction becomes more important. The visual designer’s focus involves a much higher level of artistic expression. If the UI Designer spends SOME time thinking about look-and-feel, the Visual Designer spends ALL of their time thinking about look-and-feel.
When the UI Designer has decided where the fountain should go in the atrium and the visual designer has decided whether it should be futuristic looking or more baroque, someone has to come in and install that fountain. Someone’s got to hook up the water and the lighting. Someone who may not need to know how to construct a load-bearing wall, but knows where to find the water main and the fuse-box. Someone who might have put a ping-pong table in where the fountain is going, but understands this isn’t their call. This is the User Interface Developer. The UI Developer, in this analogy, is part plumber, part electrician and more. Not only does he or she need to install the fountain so it works, but must coordinate its automated functions with the building’s central computer so it knows not to run on holidays and to shut down in case of a water main break. The UI Developer is responsible for constructing every surface in the building with which a person might interact. They put up the interior walls, wire up the buttons in the elevator and hook up the lights in the drop ceiling. They lay the tile in the lobby and install the touch screens in the executive conference tables. They pick up where the construction workers leave off. In software design, the UI Developer is often handed the wireframe and a series of static images created by either the UI Designer or the Visual Designer that he or she must then “slice up” into HTML. But their job doesn’t end here. Interfaces for online software are frequently dynamic on the client side. This means that the interface is performing actions in response to user activity without calling the server’s database or functions. Analogously, you wouldn’t need the drinking fountains in the main hall to have to check with the building’s central computer whenever they thought someone wanted a drink of water, right? Better to just provide a stream of water when someone hits the button. And the UI Developer knows much better than the IA, the UX Designer, the UI Designer and especially the Visual Designer how to talk to the construction crew in charge of riveting girders and laying brick. The UI Developer knows that there is no way to have 20 more gas grills serving the restaurant on the mezzanine without changing the kind of insulation in the floor and applying for two more licenses from the city. Much as the UX Designer might want them there. Better to sort that out with the construction crew before any concrete has been poured.
And lastly, you have the construction crew. The guys who walk around in hardhats and tool-belts, welding steel beams, pouring concrete and raising exterior walls. These are your Developers (aka programmers or coders). They evince the same no-nonsense approach to their trade as real construction workers. They know building codes as well as they know the laws of physics. While they swing a pre-poured concrete piece of your parking garage into place, developers swing in Visual Basic objects (as in object-oriented programming) and lock them in with all the finesse and certainty construction workers do with spot welds and masonry. They gather in groups to solve problems but also jealously guard their own circle of expertise against pretenders and dilettantes. If the building’s architect came to them in a fluster halfway through its completion and told them it needed a freight elevator that goes all the way to the penthouse, they’d laugh him out of their trailer, tossing doughnuts at him as he ran for cover. And rightfully so. Why wasn’t it in the blueprints? Why are we hearing about this now? The sub-basement was never designed to hold that much added weight. And on and on. “That’s gonna be an awful lotta overtime, pal.” Many developers I’ve known have objected to this analogy as limiting. Certainly there is as much strata of expertise among developers as there likely is in construction workers. Some know so much about the overall process, they could do the IA’s job for less ambitious projects and build-outs. Others are just nine-to-fivers content to rivet all day till the whistle blows. Certainly building architects are in consultation with construction experts from the project’s inception: Can this be done? Can the bedrock next to the river support this kind of weight? Have you ever built anything like this before and what special considerations are there? I’ve seen developers devise solutions to UX, UI and even visual design problems that designers missed. That said, you probably don’t want your developers telling you where to put the restrooms or whether the facade ought to be Art Deco or Neo-Classical.
Understanding the various roles involved in the successful creation of new software is the very first step in ensuring its success. Some roles can be combined, but only those similar to each other in the process. For any such project of significant scope, you wouldn’t have your Product Manager designing the UX any more than you’d have a developer creating original graphics. That would be like the building manager telling you how to design the buttons in the elevator or a construction crew painting the frescos in the lobby. All of the resources inhabiting these roles have something to give and none of them can do it all. The truest predictors of success in any online software effort, I’ve found, are the levels of both collegiality and accountability. If the lines of communication between each role are always open and none are favored above the others, then your only concern need be the talent of your people.
Ensuring this dynamic is the only way to making sure your “building” is the next Bird’s Nest Stadium and not the next OCAD Building.
