What better way to kick off my field notes here on ChristineEsoldo.Design than with a post about my design philosophy? This philosophy permeates everything I do - how I work, the companies I work for, where I work (physical location), the tools I use, how I communicate, and most of all, how I get things done. If you get it, you get me and we'll probably be the best of friends.
Design is iterative
From brainstorming and workshopping to prototyping and testing - nothing about design is a once and done thing. Rarely is our first idea our best idea, and even if it is, we have no way of knowing that until we talk to our users. So either way, if you're designing, you're going to be iterating.
The iterative process helps teams test ideas, fail fast, learn from it, and keep moving. It makes changes easier and much less painful if you test a low fidelity mockup in the early stages than if you test a fully coded application for the first time and discover you've gone down the wrong path. Iterative design saves money, resources and headaches.
And you can iterate on lots of things - your initial idea (does it even resonate with users?), words, labels, information architecture, visual designs, interaction patterns, and task flows to name a few. And after you launch, you should continue to iterate. Design is never finished, and there's always more than one way to get things done and it's your job as a designer to figure out the best way for your users. Using an iterative process helps you do just that.
Design is collaborative
Once upon a time, although I have no idea why, we thought it was a good idea to send a designer up the mountaintop and expect her to work her design wizardry and come back with a design miracle. This is not design and it is not UX. It's assumptions, opinions, and maybe art, but it's definitely not design.
Design happens between lots of different people with diverse viewpoints and backgrounds (I'll save the "diverse teams create better products" post for later) and it involves talking to your users at every step of the way. You need to interview business stakeholders like marketing or the product team, understand the technology constraints by working closely with engineers, get the content right with content strategists and copywriters (ideally before you start any kind of visual design), and of course, work with other designers throughout the process.
What if you're a UX team of one, you say? To that I say, bless you, and then pull in all of the help you can get from outside of your little team. There are still users to talk to and there are still business stakeholders involved. Get them into your process (there's a full post brewing about that, too).
Common ways to collaborate are sketch sessions and design workshops - and it's great to include everyone in these sessions from users to business stakeholders and everyone on the UX team (engineers, content, design, etc). It helps to get a range of ideas and thoughts out and then look them over for analysis later to find the ones worth moving forward on (the ones worth iterating on). But throwing things over the proverbial wall and hoping it all comes together is a mistake. When's the last time you threw a pile of legos into the air and they all magically landed in a connected formation? Right.
Another way to get everyone involved? Have a usability testing viewing party. If not during the live sessions, then in the days immediately following. It's one thing to tell people what happened during research. It's another for them to see it firsthand.
When design isn't collaborative, bad things happen. Things like designers making assumptions about technology and designing things that aren't possible within the current constraints. Or engineers taking Sketch or Photoshop files from designers without discussing things, and making assumptions about the interactions or microinteractions the designer intended. Or not talking to your users and designing the wrong thing entirely. Design is collaborative, so collaborate.
Design doesn't happen in a vacuum, but it doesn't have to happen in the same room or even in the same time zone
We've already established that design is a shared effort and expecting a designer to be Moses won't get (effective) results. But just because design is collaborative, doesn't mean that everyone has to be crouched under fluorescent lights in an open office floor plan with a ping pong table and kegerator. Sure, ping pong tables and beer are nice, but so is technology. And when design and product teams use it well, it makes for some pretty successful projects and it doesn't matter if they're distributed across cities or countries.
In our ever-connected digital world, it's easy to have morning "standups" via a Slack chat where everyone just drops by and says what they worked on yesterday, what they're working on today, and what concerns they may have. Whiteboarding sessions via Realtime Board help when brainstorming ideas or analyzing research, and documenting designs via tools like InVision or UXPin helps keep everyone on the same pixel. Video tools like Skype, Zoom, or Google Hangouts help when "face-to-face" meetings are necessary. And there are a host project management tools out there to keep everything in line including Basecamp, Trello, and Atlassian, to name a few.
The point here though, isn't the specific tools you're using. It's how you're using them. It's that you're using them. Working across cities and time zones can be challenging, especially for people who have never done it before and assume that a traditional office setting is the only way to go, but remote work is often more productive than work in a office setting. The key is to remember that remote work doesn't mean you're working alone and to keep communication going at whatever intervals are right for you and your team.
Design needs research
Research isn't just about tactical iterative testing, although that's extremely important. It's also about ongoing strategic studies that continually feed into understanding the user and the problem. If you aren't continually researching and testing, but you're plowing through features and sending them out into the wild without the research safety net, you're building your house on quicksand and it's going to sink. And it's going to be messy.
Research does a lot of things, but here are a few of its key functions:
It validates assumptions
No matter how much you think you know or how much you think your cousin who may sort of be one of your target users knows, you need to actually get out and talk to more real users to validate what you think you know, fill in the knowledge gaps, and find out what you don't know that you don't know.
Simply relying on a designer's expertise or a single user's opinion creates a very narrow scope of anecdotal evidence. It's fine to start out with some anecdotes (and assumptions) because you have to start somewhere, but after that you've got to get out and collect real data to validate (or disprove) those. And you should do this before you start designing things.
Data comes from conducting real research in a variety of methods. Sometimes those methods are more strict than others based your timeframe and budget, but it's still research and it's necessary. Do not skip this.
Types of research include field studies, diary studies, interviews, surveys, card sorts, competitive analysis, usability testing, and once you're in the content, information architecture, and interaction design phase(s), iterative design tests on all of those areas. The best data comes from combining both qualitative (field studies, diary studies) with quantitative (surveys, web stats, experiments), and it's up to you as a UX professional to understand the various types of research, know when to apply them to your situation, and guide your team in the right direction.
It builds empathy
You are not your user. And in the rare case where you are your user, you aren't the only user and your mindset isn't the only one out there. In order to understand your users, you need to spend time with them. And you do this by...research. I once wrote in a research report that "in order to walk in someone else's shoes, you have to stop running and take off your own shoes first." And it's true. Often as designers and product professionals we're so caught up in features and releases and cycles that we think we just don't have time to stop for a second and figure out if what we're doing even works for the people we're doing it for. But the reality is, you don't have time not to.
By really sitting down and understanding your users - how they go about their day, what they do at their job, how they feel about things both outside and inside your product - you can begin a journey toward empathy and toward understanding the commonalities and differences among you main user groups (i.e., personas). And empathy is what stops you from making the cool, trendy design choice that you as a designer love but that you also realize isn't the right one for your users. When you stop thinking about design in terms of what you like and you start thinking about it in terms of what works for users, you're on your way to building empathy.
It creates clarity
Think of it this way: it's way easier to bake a cake following a recipe with a few tweaks here and there based on your experience as a baker than it is to guess your way through it and end up with a burned, inedible brick.
Yes, you should use design conventions and patterns, and you should know when to break them, and which ones to use when. But unless you've designed the exact same application or website for the exact same users at the exact same point in time over the course of your career (which by the way, is impossible), you still need research.
Don't stand in a dark cave with wet matches. Shed some light on things and do some research. It will make all of that iterating a lot easier if you understand what you should be iterating on.
Design solves a problem
The first thing I ask on any project is "What is the problem we're trying to solve for the business and for the user?" because design needs to balance both of those things. The second question is "What research do we have that validates this?" If we don't have the answers to either of those questions, we have some work ahead of us.
If you aren't solving a problem, what exactly are you doing? Launching new features just because someone thought it would be a cool thing to do is not solving problems. Listening to one client and designing things specifically for them is not solving problems (well, maybe it sort of solves it for that client, but it could actually create problems for your other clients - oh, the joys of enterprise).
By approaching design as something that is meant to solve problems, you'll be able to start clearly identifying and prioritizing those problems, which helps in creating an overall approach and strategy (i.e., the roadmap!). The key is here not to get caught up in solutions on the front end. You need to define the problems first. Worry about solutions later, after you've done some more research.
Design solves problems. And you figure out what these problems are by understanding your users, the market, and the needs of your business.
Design isn't a step in the process, it is the process
This is a bold one. But it's true. Design isn't something that gets tacked on at the end of the whatever it is you're doing and makes things look pretty. It's not visuals. And for the love of Photoshop, it's not "making things pop!"
Design begins long before a single pixel is moved. It's making sure that before you've wrapped the birthday present, you've taken into account who the present is for, shopped for an appropriate present for that person based on their needs and wants, put it in a box that is the right size, and included the proper additions like tissue paper or packing peanuts to hold the present in place. Ultimately, the person may think the box is nicely wrapped, but if you forget about the actual present in the box, you may have one disappointed present recipient. And your birthday present shopping process wasn't just about wrapping the birthday present. It was about doing all of the other things first so you could, at last, wrap the present.
Similarly, the visuals are the package, but the design process involves research, testing, and understanding business and user needs. It includes creating personas, empathy maps, mind maps, user journeys, sketches, and other artifacts. It requires choosing the right technology stack and implementing it. It means making sure that the copy and content are user-appropriate and well thought-out. That's the design process. And it's how successful products are launched and how they grow.
And that, my friends is my story, my guiding principles. My Design Philosophy. So how about you? What's yours?