By Ramya Mahalingam / 6 Nov 2016 / Topics: Customer experience
While creative work generally comes with tints of mystery, this particular term could benefit from a little more clarity. And the first step on the path toward clarity is to recognize that the term actually refers to two different skill sets. The “UX” skill set is more focused on the strategy and high-level aspects of the product, whereas the “UI” skill set is more focused on the execution and tactical aspects of the product.
It’s sort of like building a house. Before beginning construction, you’d probably have a few questions, such as, “How many people are going to live in the house?” “What are they going to be doing in the house?”
As these questions are answered, you might start to get a rough idea of how you’re going to divide the plot of land. You’d start to define what the people would do in each room. Maybe there’s a room where they’ll cook. Let’s call it something like the "kitchen." X number of rooms where they'll sleep — "bedrooms" — perhaps with one that’s a little bigger because two people will be sleeping in the same one. A place where they'll relieve themselves. Let’s call this one the "bathroom" … and let’s not put it right next to the kitchen.
This is predominantly the architect’s territory. The architect takes some time to investigate the dwellers’ needs and translates that into a rough idea of what the overall house might look like.
The UX role is quite similar. The plot of land is like the project’s constraints — time, money, regulations, business plan, etc. Given this metaphorical plot, the first UX task is to figure out what the software users’ needs are and to think about how those needs relate to each other. The UX-er also starts to define taxonomies for the various sections of the system.
In tandem with where the various rooms will go, it’s also important to think about how the dwellers will move between them. Similarly, the UX-er’s next step is to think about how the users of the system will navigate between the sections of the system according to their needs.
The next set of questions that comes up is centered on what goes in each room. For example, in the kitchen, the dwellers will need to wash dishes, so the team will need to build some sort of apparatus they can use for that purpose. (Maybe they decide to call it a sink.) There will also be a sink in the bathroom, but the two sinks will probably look very different, since their modes of use will be very different.
At this point, the architect might bring in an interior designer to talk about the details of what goes into each room, especially if those pieces require some infrastructural planning, such as installing plumbing or electricity.
Similarly, at this point in the software development project, the person responsible for UI might start to become more involved. The team will start to figure out what components need to go into each section of the software and where the corresponding back-end pieces will come in.
Back at the house, once it’s been decided that a sink and goes in a particular spot, the next step is to figure out how the dwellers will use it. Would it suit them better to use one faucet or two? What should the faucets look like to best reflect their identities, cultures and values?
These are questions an interior designer would be better equipped to answer. Similarly, when the software development project reaches a point where the specific details of how a user is going to interact with its various functions need to be defined, it’s time for the UI-er to take the helm.
The roles of UX architect and UI designer have clear distinctions:
More often than not, the process isn’t quite this linear. As more of the house gets defined, you might go back and readjust the size of the kitchen, or move the door a few feet. The same kinds of modifications might be made to a site map or to the navigation structure of a software project.
At the same time, in the same way you wouldn’t start building a house by talking about what the faucets will look like, it’s important to figure out the bigger pieces of the software product before focusing in on the details.
If you’re building a house, it will probably be a better constructed structure if the whole team is involved at every step; if the construction crew understands why the decision to place a door in a particular manner was made, they'll be more likely to build it right. In the same way, involving the entire software development team from the beginning will improve communication and result in a better product.
But while the entire team knows what’s going on, there’s typically someone with a particular skill set driving the process. The distinction between the skill sets of the developers and the designers is quite clear. What sometimes gets missed is that there's an equally important distinction between the UX and UI flavors of designers.
UX Architect
Ramya loves diving into messy problems armed with whiteboards and sticky notes. As a UX architect, one of her favorite activities is to lead product discovery workshops, leveraging her passion for storytelling to drive digital strategy.
