Short answer: not really.
I’ve always disliked the word “should“. It takes out all the joy of reasoning, understanding and deciding on a subject.
You see, I’d prefer to expose the advantages and shortcomings of the issue and let each one choose their paths. After all, I’ve had the privilege of working with great UX designers that could and couldn’t code.
First, coding is not a binary issue. There’s much more nuance to it than “can code” or “can’t code”. There are hundreds of programming languages, and not all apply to all platforms and fields of production. There are many levels of expertise for those languages. There are complexity levels for each programming language, and even amongst languages.
So suppose you design for iOS. Then the level of coding required could take one a decent 6 months to a year to learn (3-6 months in the case of Swift?). Or suppose you design for medical devices, then you might even have to take longer to learn a very obscure and unique platform. Or you’re designing for lo-tech services for emerging technologies that piggyback on existing (and obsolescent, diverse) infrastructure. Or imagine you’re designing for IoT or physical computing, and you’d need to learn at least 3-5 different programming languages and platforms, on a stack that’s getting higher, wider and more complex, and also depends on the existing platform with which you might be trying to integrate. So in light of all these examples, why is it that there are many saying designers should code?
I’d say those might be web designers, and they’re talking about front-end coding.
Many UX designers work on the web, as it is the platform with the most needs, the widest range, reach and access, the most lenient one, one that is fit for communication, etc. And those designers work and design for what’s known as front-ends (the technical name of what we designers call “interface”). So front-ends are designed by designers and then coded by front-end developers. And the front-end markup languages are not that complicated to learn: it’s mostly made of html and css (thought many more complex frameworks such as Lass/Sass, jQuery, AngularJS are being used more and more on top of the html/css base).
So what most people might be trying to say is:
(Anyone that’s saying something else, like UX designers should learn to code Objective-C or Java is completely out of their mind and better be left alone, immediately, forever).
That sounds more specific, and more believable to us who know coding is not a binary issue. So, let’s answer this simpler, more specific, less restrictive question: Would I be a better web designer if I knew how to code for front-end?
Short answer: most probably yes.
The reason is simple: you’d then know how front-ends work and behave, so you’d also know how to design for better coded front-ends. Also, you won’t have to argue with developers on the feasibility of your designs, because you’d know it yourself, first hand.
However, the real advantage would be a powerful one: you’d be able to build “models” of your designs (like the cardboard ones architects do). You’d be able to refine your designs in code, possibly looking very much like the end product (the coded interface), and explore many nuances of the interaction, the behaviour and the levels of responsiveness of your designs you won’t be able, or it would take much effort to do, on visual apps. You’d be able to show test subjects, stakeholders, executives and clients a deliverable that might resemble much more the final product, bridging the gap that comps and wires create and therefore being able to harvest much better, more specific, faster feedback.
There are many other benefits:
Less work: On the current process, the designer does all the screen comps on a visual tool (e.g. Illustrator, Sketch), then adds a truckload of specs to assure the product is built according to predefined standards, and then exports to JPGs, PNGs or any other graphic deliverable format. This all takes a lot of effort and time, much repetitive work: adding every bit of information, duplicating and moving around, amending previous changes and adding content, not to talk about having to change all other related comps when a minor change affects one of the items in them. Then the front-end engineer grabs those comps and specs, and tecnically builds it all *again* on code, having to read all the specs and translate them to code.
Instead, coding your own prototype, all the specs are alredy there in code, and can be navigated with a browser inspector. And once you get to be pretty good at it, front-end developers can even start from your code. Which takes me to the next advantage:
Speed: Once the prototyping process is well oiled, it might be that some parts of the prototype can be reused or at least the final product can be started from the prototype, so imagine the gains in production time. Another speed gain is on the communication cycle: since your prototype is built to design specs, there’s less back-and-forth on understanding exactly what its needed from the interface and how it should look, feel and behave.
Flows: By protoyping an interface as a click-through, you’d get a much easier way to explore real user journeys and customer flows, as you can really navigate and see what the user will be going through, assess their experience, and decide what can be improved and what needs to be changed from the point of view of the user/customer.
Transitions: On a coded prototype it’s also easier to explore the use of specific transitions and animations that are part of the experience, and see how they play, tweak them and improve them all while continuing design of the product/service.
Content: In my experience (and with a bit of preparation), on a coded prototype you can better explore the relationship and impact of real content, by means of a full-fledged CMS, a simpler JSON file with content, or even hooking it up to a CSV file (or better, to a Google Spreadsheet online) that can be modified by stakeholders and content managers/strategists, and then read back by the prototype. That way 1) the content cycle will accelerate and have a more meaningful impact on the design process, 2) real content will make its way faster to the final design and 3) stakeholders will have a better, more real approach to the final product, and will feel more connected to its design and process.
The best news is that you don’t have to do the coding from scratch. Currently there are plenty of free, robust and excellent frameworks and libraries for front-end development that will help you do more in less time. Some of the best known frameworks are
(this list is not a comprehensive one, just some examples to start with).
After discussing all the great advantages of learning to code for web, I’d like to say one thing: You don’t need to code in order to design for the web (or for any other platform). What you need then is to be in close contact with how your product/service is built. Most of these advantages still exist even for designers that don’t code. It just takes for designers to work very close, elbow to elbow, with front-end developers. I’d envision a designer/front-end developer relationship like that of an Art Director and a Copywriter: none of them need to learn to do the other’s job, they just need to work together very very closely. I’d even argue that the division of roles might even benefit the process, as designers and developers might then come to the solution from their unique point of view and complement each other, and in that way both can really explore the problem at hand from their own standpoint, interest and expertise, thus giving the product/service a wider, bolder vision as the complement of both approaches.
Becoming a father has changed the way I see the learning process.
Now that I have a son, I realise he might one day learn things as I did, by sheer curiosity and an avid exposure to the world of knowledge. And as I’ve seen around, he might run into popular, catchy and groupthink-based approaches that everyone else are following.
So in order to help him (and others like him), I’ve decided to be part of the conversation and share what I think are the ten basic tenets of UX design. Here they are:
User experience design is about understanding how users think and see the world, what they want to accomplish and how they would succeed on accomplishing their goals and tasks, and giving them the best tools to do so.
It is first and foremost, about understanding others: their ideas and assumptions, their mental models and prejudices and their biases, and not about ourselves (designers and engineers and project managers), our ideas and assumptions, our mental models and prejudices or our biases.
Sometimes it feels to me UX Design is more about applied psychology and scientific research than about wireframes and visuals and patterns.
Always remember to see things through the user’s/customer’s eyes, and check with them if your designs work for them.
User experience design is not about designing screens, or pages, or wireframes, or beautiful comps. It is about the process of achieving a goal, fulfilling a task or completing a process. It is all forward movement for users from the current state to a better state, where they’re better informed about the news, or have a better way to present their ideas, or just easily buy all the products they need without losing time, or just get to know more about how are their loved ones that live abroad.
It is about a process with a start and an end, although not the same start and end for everyone. A process with common traits and trails but different outcomes. It is about starting where you need something and end where you achieved it. It is about process and progress, not pages and buttons.
Always take into account where the user starts, what they would like to accomplish and how they’ll go about to fulfill that need.
When we try to achieve something, we always do it within a context. That’s probably obvious. What’s not so obvious is that the context will most probably affect the process.
Whereas it is because the trigger of the process is the context itself, as when we need to find the meeting’s room while walking towards it, or we’re watching tv and want to check on the candidate’s assertions on wikipedia, or when the context has an effect on the process, as when we decide to text someone because there’s too much noise to talk where we are, or when we have to reload our starbuck’s loyalty card from our phones while queuing to get the loyalty points, the context will affect not only our attention and faculties, but the access we might have (or the lack thereof) to external information, to gestural affordances or even to our own other helping hand.
Contexts can be the makers or the breakers of a process, and taking them into account can make the difference between a process we use because we need to and a process we love to use.
Always take into account the possible contexts the user might be in or even better, the uncertainty of the context, even one you might not have though of.
When customers and users engage with a service/product, they’re looking to engage with interesting content, in the case of informational processes, and in their own content to be easily and effectively manipulated to achieve their goals while being guided by very succinct, effective and compelling copywriting and labeling, in the case of procedural processes and services.
What they’re most probably not interested in is checking how cool is your interface. So although a sleek, cool interface can communicate a message of quality and excellence, it should never get in the way to the content they’re looking for or working on. This concept also applies to your patterns and processes, widgets and interaction models.
Always make so that every part of your product/service is there to help the user to better interact with their own content or the one provided by your product/service.
Once I was presented with a very simple (and rather prosaic) metaphor for the process of creating interactive products/services: “it’s a scratch to an itch”. It indeed holds a simple way to see why people use our products/services: they need to do something and they need one way for it to get done (with the least effort possible, oftentimes).
So the most important part of giving people useful tools is knowing what they’re trying to achieve: which thirst they’re trying to quench, which desire they’re trying to fulfill, which pain they’re trying to relieve. This metaphorical “itch” is almost never what it seems, (as doctors know) but most often a symptom of a deeper issue. After all, nobody’s job is to create presentations, or send emails, or make todo lists, or organise workflows. Instead, people’s jobs are to better communicate their message to a larger audience, or to make sure a project gets completed within its deadline, for example.
Always make sure you understand what people’s needs and goals are so you can better satisfy them with your designed tools.
There is one factor that distinguishes design for great experiences: the attention to detail on micro-interactions. The reason is that customers act and react to every micro-interaction several times while using a product/service, and it is the sum of all those micro-interactions that make for the customer experience.
When a customer opens an app, they won’t “search for a specific product” as we designers write it down in many flows and descriptions. Instead they will: 1) scan the landing screen, 2) find the search icon, 3) recognise the search field, 4) click on the search field, 5) expect the field to be on focus (selected), 6) look down expecting the mobile keyboard to show… and here’s where if the keyboard does not appear, they’ll startle, befuddled. It might be that they missed the hotspot for the search field, but they probably won’t know that. So it is our work to make sure the search field’s hotspot has enough room to make sure even close-enough taps would succeed on getting focus on the search field.
This is just an example, but one that if repeated many times by many customers, it will start impacting their experience and then the perception of the product/service, disrupt their process and make it more difficult for them to accomplish what they wanted to.
Always be very mindful of every step in the process of every interaction that customers would face.
An interface for a new product/service won’t be right at the first try, or sometimes even at the tenth time. It takes time to refine an idea into a great product, same goes to the interaction and the interface. Everyone has to start somewhere, and your design experience, design tools, knowledge and know-how and design wits will help you get to the best start possible.
However, it is after the launch that all the real work starts happening: observing real customers use your interfaces and go thorough your flows, do their tasks on your platform and achieve, or not, their goals; and more extravagantly but still extremely interesting, some times you’ll see customers use your product/service in ways you’d never imagine they will (or even could).
It is all that knowledge and learning that will serve you to know where to go next, how to solve impasses users are experiencing, and how to make your product/service a better tool for your customers to achieve their goals and fulfill their needs.
Always remember that the real design work happens when it is being used, and measured.
You know what you measure, so you’ll only know if the design and experience of a product/service is good if you measure it constantly. More importantly, you’ll only know where to improve and how much impact those improvements will have if you measure them.
There are plenty of methods to measure, including usability testing, contextual inquiries, surveys, moderated/unmoderated remote/local research, multivariant tests, metrics and analytics and more.
By measuring your work you won’t only be able to know your product/service better and thus the way to improve it, but more importantly, you’ll be able to communicate those results and thus positively influence the perception of your product/service, and of your design process in general.
Always find a dimension to measure against for all you design and deploy.
Culture is a large part of that context we mentioned before. We live in a world that seems more globalised than it is. We have ~190 countries in our planet, and over 6900 spoken languages in our world.
Almost every country has invariably its own idiosyncrasies, and most cultures come with their own mental models shaped by different processes, from their previous experiences to their linguistic conformation and semantic structure. Even more, at different ages we see the world in different ways, and depending on our job role and rank we might even have positions about how to approach different subjects and issues. So what is common in the United States or in India might be quite edgy in France or in Japan, what is usual in China or Argentina might pass as exuberant or just nonsense in Australia or Senegal.
Our interpretation is usually affected by our language and culture, and since interfaces are but sensorial code to be interpreted by our brains, cultural nuances can make a big difference.
Always keep in mind that different cultures have different mental models, and never assume what’s right for you is right for everyone like you.
Design is a very misunderstood field. Through your life you’ll find people that won’t believe in the effort that good design requires, won’t understand it, or simply would prefer the easy way.
Passion is the one thing that will push you forward, by discussing with a larger audience, sowing ideas and concepts in your work and then harvesting results that you can share with others. Explaining to others the advantages of deeply caring about the audience of a product, and even before that, the uncovering of the needs that audience might have. To change the world one design at a time, one person at a time, one interaction at a time.
Always remember that the details are the design, and that design is also the work of explaining to others how design can change the world.
Those are my tenets, the ones I’d like to share with my son. They’re very high in level of detail, perhaps more guidelines than rules.
You might have noticed I’ve not talked about wireframes, visual mock-ups or prototypes, and there is a reason for that: those are artifacts of the syntax of the design process, the tools to communicate design. Just as good syntax and orthography is needed for good writing, good use of design processes and tools are needed to create good design. But just as much as great syntax is neither guarantee nor the main attribute of good writing, those design tools are not what makes design great.
In my experience, good design evolves from attention to these ten tenets, and it is expressed by attention to best practices for tools and processes. So put in a simple way:
Although tools, best practices and methodologies will make you a good practitioner, adherence and attention to these tenets would make your design great, and will make a great designer out of you and your effort.
Designing for any interactive medium is like writing a story. You choose your characters (target audience), try to describe them the best you can (personas), then imagine them doing many things around your product/service (user journeys), in many different orders and flows, living the product one task at a time.
That’s most probably why it is called “User Experience Design”. I agree with the “user experience” part as there are users to whom experiences happen, but the “design” bit might show as pretentious. If “designing” is taken as “defining”, some might argue one cannot design (ergo “define”) an experience, as each and every visitor will surely have a different one; their perceptions, mental models and inputs being different and therefore results, outputs and recollections equally so, in fact creating a unique, highly personal “experience” for each individual, and surely not necessarily the one the designers envisioned.
Still, you can “design an experience”. You just won’t priorly know which one you’re designing, or if people will get to live the experience you envisioned. But certainly you can design an experience as a coherent process that concatenates different steps/screens into discernible flows, so that users can find them, follow them, traverse them and hopefully end up achieving their tasks and goals.
Yes, you can design an experience as much as a writer can write a story. It will never be the same story for each reader, so true. But they all can share the starting, the episodes, the characters, the ending, and somehow then bits of that experience. Every single reader will have a story of their own. They will also have some thread that will unite their individual stories into one main path.
The biggest challenge for User Experience Designers is to go beyond a series of screens concatenated by a series of well-placed buttons, and make sure our products and services propose a trail, a path for the user/customer to achieve their goals and fulfill their tasks.
You could call it “Task Achievement Design”, or “Goal Fulfilling Design”, or “Journey Design”. I guess many call it “User Experience Design”. It is beyond the name and part of the role to do good design for those users to have their own great experiences, every one of them.
Most of my work as UX designer happens within a team with lots of access to the processes, the research and even the users and their feedback. Most of the time I depend on and value feedback from my team regarding UI and process, as they help me see the pieces and parts I miss, and bring about perspectives I’m less familiar with.
However, I’ve noticed moments when I’m rather defensive of the interaction/interface design, criticising every suggestion teammates might come up with. Those moments come when I’m in a situation where the value of design is questioned a priori or I’m not given space to do my job.
I’m inclined to think this happens to others as well.
If it might seem as if someone in our team is being more defensive than required, it would be good to consider if they have enough room where to contribute and enough support from the team. That might be all it takes to get from defensive to impressive.
A mode of response to In defence of the hamburger menu
The problem with (the discussions about) the hamburger menu is that most people start talking about the menu but end up talking about the icon. They start talking about the pattern to later dwell on justifying their use since they themselves find it useful.
It is not about the icon, It is about the pattern of hiding important (and sometimes very unimportant) stuff under a generic icon. It is about all the apps that started using it and then relegated it, bringing out many of their best functionality so that people could discover them. It is about discoverability, one of the founding principles of good interaction design. It is about how complicated it is to find stuff that does not belong to the same categorization in our mental models on a single list.
In sum, it is about how easy it is to put there all and hide it all in order to get a prettier page, in lieu of a better page. It’s about how easy it becomes an anti pattern, how easy it is to hide it all under the magical, invisible menu.
I could add some links to research and articles here, but then it might look like spam, so I’ll add this one, as it has plenty of examples: The Hamburger Menu Doesn’t Work
Finally, it is not about opinion. We all have opinions. It is about cases and examples and studies and research and solutions where it works or not. Where designers make it work or not. Those should be the arguments. Those should be the examples.
And the icon itself? Who cares. We still use a dumb floppy for saving documents.
You might also want to read: It’s not the hamburger, it’s the menu (part 1)