Comprehensive description of my design process
I don’t know if it ever happened to you, but for me, it’s very common to take some things for granted. And I’m not talking about the importance of being grateful. I’m talking about a syndrome I like to call the “obviousness paradox”. This syndrome consists in being so caught up in our own life/ environment/ work that we start to think that what we do, or think, is obvious for everyone else, so… there’s no need to explain! Right? Well, not really. It turns out that every person, or team, has their own particular flavor to add even to the most cookie-cutter like processes. So, by thinking something is obvious and therefore not explaining it to “outsiders” you are actually creating a knowledge gap.
Recently, I became aware that I suffered this syndrome. By talking to past clients/partners in crime, other designers and colleagues I noticed that I was taking for granted my design process. That is why I decided to write a post about it. It’s important to stress that I’m not saying you should adopt this process, nor that it is the best process in the world. I only want to share my two cents, in case someone finds it useful.
If I had to summarize my process in a single phrase I think it would be “I care about the user”. That might sound like a big cliché coming from a UX/UI Designer, but I mean it. That is what drives my process, because my personal opinion, my client’s opinion or even my boss’ opinion don’t mean much if it goes against a validated user need. We’ll get back to the “validation” thing in a moment. For now, I just want to say that this is the glue that holds the process (and my sanity) together.
What my process includes
Let’s begin! 🎉
Discovery
I consider this to be one of the most important phases in the process because during this brief (ish) period of time you go from not knowing anything about your client, his business or his audience (to be referred to from now on as your users) to being well-versed in all of the above. And I don’t mean “having some idea”, I mean that you need to get to understand most of it, if not all of it. Otherwise, it will be very difficult for you to achieve quality results.
Activities
In this, and in all the following phases of the process I will list and describe the activities that I personally like to do during that phase. The activities, in practice, will vary depending on the project’s needs.
For this particular phase I like to conduct some (or all) of the following:
Immersion
In that very dull period of time when the managers are prepping all the legal paperwork, I like to ask my client for data and get very much drunk on it. The data you might need (or be able to get) will depend on a number of factors, and it can include (but of course it’s not limited to):
- Analytics and other quantitative metrics
- Audience reports
- Documentation about the platform you are about to redesign
- Sales reports
- Market data
- User stories
- Feedback gathered from a number of sources
- Notes about the possible problem
- Access to an intranet or otherwise private (or in-progress) environment
What you do with the information you receive will be key for the development of the project. If you don’t get acquainted with the requirements, limitations and other data, you won’t get a complete picture to work on and to ask questions around.
What I like to do at this moment
Get one person on the client’s side that can be your main point of contact and ask a ton of questions. That person might refer you to others (or to written documents), but use that main point of contact to get a high-res depiction of the project’s environment and status.
My advice: don’t be shy. Again, you might think something is obvious, but chances are it’s not, so ask away. Only remember to use your criteria, I mean it’s probably not wise to ask “so, what do you guys do again?”. Inform yourself and then ask strategic questions.
Kick-off meeting
So! The contract and whatnot are finally done! You get to start working. To do it I like to set up a kickoff meeting. This meeting will mostly serve as an ice-breaker, but it will have a lot of other cool features too. For example:
- Present the teams that will be working on the project, and the project’s stakeholders.
- Review the project plan and timeline.
- Define the success metrics for the project.
What I like to do at this moment
I like to have the entire team present at this meeting. Even if they won’t do any talking, I think it’s great for everyone to have the chance to introduce themselves and to hear what the expectations are for the upcoming project. This promotes project ownership, in my opinion.
Workshops
If I have the chance, I like to organize and facilitate a series of workshops to deepen the knowledge I might have about the client and the overall goals of the project. This is particularly important if there were some knowledge gaps during the immersion phase.
Some of the workshops that I like to do include:
- Audience definition: This is great when the client already has tons of information about the audience. With this workshop, you can summarize and streamline the data to guide your design efforts. I like to use a priorities pyramid, along with a table where we turn facts into screening questions, and a keyword brainstorming session.
- Understanding business goals: Sometimes a client will bring you a project but you might not clearly see the business objectives behind it. This workshop can aid in getting the information you need. Again, I use a priorities pyramid.
- Competitor analysis: So, your client has some strong competitors. It might be a good idea to analyze those competitors to use their strengths and weaknesses to your client’s favor. Some people like to do this without the client’s involvement, but I choose to include them in the process because I’m sure that they know more than anyone where they want their company/project to stand in terms of its competition.
- Content strategy: We’ve all been there. A client wants to build or redesign something but they don’t have the faintest idea of what content they want to include, and as you know, the design should serve the content and not the other way around. In these cases, I like to tailor a workshop to the particular needs of the project at hand and optimize it in order to achieve different goals. These goals might include defining the core message of the project, appointing the responsible to produce the content on the client’s side, and starting to structure the Information Architecture.
- Feature listing: It’s very easy for the client to get carried away when planning what features they want to include in their project. It’s useful to conduct a workshop using the MoSCoW method (Must have, Should have, Could have, and Won’t have). It’s also useful to assign values to each feature depending on its complexity to help the client understand what they “are buying” and the costs associated with each strategic decision.
What I like to do at this moment
I’ve worked remotely for many countries during my career, so I like to pick online tools that will help close the distance gap between me, my team and my client. For workshops, I like to use a good VoIP-based (Voice over IP) communications service like Zoom, and a white-boarding tool like Realtime Board.
Experience Strategy
Also known as Design Brief. Basically, with all the information gathered during the immersion, the kickoff meeting and the workshops, I like to create this document that serves as a contract of some sort between the design team and the client, and as a blueprint to guide any future efforts. In the design brief, I like to include things like:
- Definition and use of a Design Brief (again to avoid the “obviousness paradox”)
- Depiction of the client’s business
- Problem statement
- Audience definitions
- Collaboration framework
- Metrics to evaluate success
What I like to do at this moment
I like to make sure that I have all the information I need to build a coherent and mostly useful design brief. It might happen that you won’t, in fact, have all the data. For example, you might not have a clear problem statement or an audience definition. In that case, you’ll need to pause this document and resume building it after the User Research phase, coming up next!
Research
This phase is super important because it will help fill in all the informational gaps by asking the questions for which you still have no answer. You probably noticed that I keep going on and on about getting informed, and this is for a reason. Without specific information to guide the design, you will end up creating something that doesn’t solve a problem, or attempts to solve it but for the wrong audience, or that altogether has no connection to any business goals whatsoever. And that doesn’t sound so good, right? It sounds more like a waste of time and money. So, save yourself time, and save your client’s hard-earned cash, and do your homework! (read in a friendly tone, please 😃 ).
Activities
Below are the activities I like do you when in this phase:
Identify the gap
By now you should have quite a defined idea of what is the information that is missing from your project. Most times your client will have identified that for you beforehand, and actually hired you to fill that missing piece. That means that you will know what to research since you probably estimated the work before starting. Some other times, the project starts and through the process (the meeting, workshops, and design brief) and you notice that there is some important data missing that you need in order to orient your work and deliver a quality solution.
I know there are other things in play when this happens. I mean, it’s never easy to say “we need to add work to the original estimate”. It’s even harder when it comes as a complete surprise to the client, like, they thought they had everything thought out, and here you come to challenge certain assumptions (for example, “are you sure that your audience needs this?”). It can be a tough conversation, but it helps to stress out that you can help answer these questions and the impact that this knowledge will have on the final product.
What I like to do at this moment
I really support the idea of inviting the client to the kitchen. Actually, when a project starts they are not my clients anymore, they become my team, my partners. You’d be surprised at how much this can boost creativity, collaboration, and above all trust. I’ve had some great partners in the past, and having them onboard had an incredible impact on the project. So, get in a meeting room (an online meeting room, in my case) with them and talk about the missing information, the need to challenge assumptions, and plan the research roadmap together.
Also, please remember to keep in mind the etiquette for meetings (having a meeting agenda, respecting the assigned time slot, and giving people back their time if possible).
Choose a methodology
Once you’ve defined what is that you need to find out, the next step is to define how you will obtain the necessary data. There are so many methodologies out there, and each one has its depth and quirks, so we’re not going to cover what each methodology entails in this post. You can find plenty material out there, like books, podcasts, webinars, and whatnot. One book I really like is Validating Product Ideas by Tomer Sharon.
Some of the methodologies that I like to use are:
- Personas: Great to help define the audience and test assumptions about it.
- Interviews: Very versatile, can be used to accomplish a number of goals.
- Contextual Inquiries: Awesome to understand how someone does something in particular.
- Experience Sampling: Useful to validate (or invalidate) product/business ideas before investing.
- Diary Study: Used to closely follow an entire interaction/ process/ workflow from beginning to end.
- Journey Mapping: Can help identify users’ pain points during their journey using a product or service.
- Heuristic Analysis: Very valuable technique to assess the usability of a platform or design by comparing it against a list of conventions, and finding areas of improvement to guide any future efforts.
What I like to do at this moment
Honestly, I like to enjoy it. This is one of the stages that delight me the most. Once you start talking to your users and making contributions to answer questions, you can’t go back. It really is a process of growth, both for the project and for yourself (in my opinion, of course).
Also, be serious; respect your users’ time; practice and prepare everything beforehand. Basically, again, do your homework. Be ready.
Build a plan
Very well, you have your question to answer, and you’ve defined how you will go about in answering it. Before getting into the play-field, you’ll need to build a plan. This is very important because it will be the blueprint to guide you through the process, and because in this plan you will construct the structure of the research.
In the plan I like to include:
- Context: Why are you doing this? What are you trying to find out? Why?
- Hypothesis: There can’t be a research without a hypothesis, that will be later validated or invalidated. You frame your question, and then you list your assumptions regarding that question in the form of a hypothesis.
- Objectives: What are you trying to gain with this research?
- Questions: What questions do you need to answer in order to validate/invalidate your hypothesis and reach your objectives?
- Methodology: Map out your chosen methodology and include things like how long each interview will take, where you will conduct them, which technique you will use (e.g. the think-aloud protocol), and so on.
- Team: Who is going to participate? Who will be the facilitator? Who will take notes? Who will record? Are there going to be silent observers?
- Participants: Include information about the people you will be taking to (if you have it, if not, keep reading!).
- Timeline: When are you going to conduct the research? When will you present the findings?
What I like to do at this moment
I like to be very thorough. Especially regarding the hypothesis. I believe that is the cornerstone of any research, so take your time and really think it through. Don’t just “check this item off the to-do list”. Really commit to organizing and mapping out the process. It will make a difference in the outcome.
Find representative users
Sometimes your client will have a database filled with actual customers you can screen. But some other times, you’ll need to render the service of recruiting users. In any case, the important thing to highlight is that the users you select to participate in the study need to be representative of your target audience (or your assumption of the target audience, AKA your proto-personas).
To find some users you could:
- Do it yourself, manually, using social networks. Again, check out Validating Product Ideas by Tomer Sharon for more on this topic.
- Use a service like User Interviews, which really streamlines the process. They take care of finding a pool of users to send your screener to; they send out the compensations; and even help schedule your interviews. You only need to worry about asking the right questions in your screener survey. Disclaimer: this is not a sponsored post, I just really like what they offer. They have a great customer service too.
What I like to do at this moment
I like to go back to my plan, re-study my research questions, and from those questions, the hypothesis, and the audience definitions, I carefully craft my screener questions. The success of your research kinda depends on having a quality screener. Here’s an interesting blog post on that topic.
Go ahead and find some answers!
After all the hard work it took to get here, you’re finally ready to go on and get your coveted answers. I’m not going to dig very deep here, because the process for each methodology is very unique. So I’m just going to say: be prepared, learn to listen, embrace uncomfortable silences (they can be very fruitful), and RECORD EVERYTHING. Have fun! And remember to craft a comprehensive report afterward. Like they say “if it’s not documented, it doesn’t exist”.
What I like to do at this moment
I like to create two reports. One with the raw data including notes about found issues, data charts, figures, and another one that will only feature key and digested information that the client could put into a presentation and show it to his team/stakeholders.
Structure
If we’re on this stage it means that we got all the information that we needed to clearly define the problem statement, the audience and the needs and pain points of the target users, among other things. Now it’s time to start building.
Activities
The activities in this phase include:
Information Taxonomy
Also known as Information Architecture. What we need to do here is take all the content we defined previously during the Discovery phase, and organize it in a clear and intuitive way. That content may already have a certain structure, for example, if you’re redesigning an existing website or app; or it might be completely up to you and your team to give it a proper hierarchy if you are designing a platform from scratch.
In any case, there are some techniques that come in handy for both situations:
- Card Sorting: Really useful to understand how your target users would make sense of the content and organize it. You can also use this technique to improve the labeling on your website or app.
- Tree Testing: Once you’ve created an assumptive IA (Information Architecture), you can validate/polish it with this technique.
- First-click Testing: You can use this technique on both production-ready websites/apps and low-res prototypes. Understanding where your users click first when trying to accomplish a given task can be eye-opening and useful to fix your IA.
What I like to do at this moment
As always, I like to put all my findings on paper and present them to my team (or “my client” for some). It’s always great to have data to support your claims. Once you have everyone on board, you can go ahead and build your final Information Taxonomy map, which will later be used as a reference point to build the components and screens for your website or app.
Wireframing
Or low-resolution prototypes. These very simple sketches rely solely on grayscale colors, placeholders, and lines to construct the structure of your product (whatever it is). Their simplicity is truly handy since it forces people to focus on what you want and need them to, at this point. There are no distractions, and opinions about color preferences or styles.
Following the guidelines set in your IA, you start organizing the content but this time within the boundaries of a “physical” space. You get to study how to maximize the chances of your users reaching their goals, and therefore of reaching your client’s business goals.
I usually like to start this part of the process by creating a mood-board in which I collect structural inspiration. I then create at least two concepts for the most important screen/page in the project. It is very useful to force yourself not to stick to your first idea, many good things can come from that exercise. The final word regarding which solution gets to move forward comes from the client.
What I like to do at this moment
Here the “obviousness paradox” syndrome comes into play yet again. We might think it’s quite clear how the screens relate to one another, and what would happen if a user clicks, or swipes, or whatever on the screen. But I’ve come to find that this can be quite challenging for someone not used to seeing ideas portrayed in this manner. Something you can do to make things easier is to build wireflows, that is, to create a document showing how the screens connect to one another. You can also go one step further and create a clickable prototype, using a tool like InVision, for instance.
Validation
I use this word a lot, right? Sorry about that. Nevertheless, it’s paramount to test whatever assumptions you may have. And right now you have a whole bunch of assumptions in your hands, in the form of wireframes, wireflows or a clickable wireframe prototype. Now it’s time to test.
Prepare
The process here is quite similar to what I described in the Research phase. You already know what gap you’re trying to fill (does this design help my users achieve their goals?); you know the methodology as well (Usability Testing); you, therefore, need to draft a plan to guide you and find representative users to test your designs with.
What I like to do at this moment
Remember to pay attention to all the necessary details like tools you’ll be using, recording, confirming scheduled interviews, preparing to send out compensations at the end, and so forth.
Test!
You can run an unmoderated usability testing study using a tool like TryMyUI (btw, I was a guest author on their blog a while back, in case you’re interested), or, my personal fav, you can go all in and be the facilitator on some moderated testing sessions.
I personally believe being there and seeing what users do when they’re trying to do it is priceless. You can ask follow up questions, dig deeper into their frustrations and pain points, you can analyze their facial expressions and body language (yes, even doing it remotely like I do). The thing is, being a facilitator can be quite challenging. Thankfully, there are a ton of resources that can help you get started. I recommend Steve Krug’s “Rocket Surgery Made Easy”.
What I like to do at this moment
I like to give a good impression to my users. It’s important to create a safe space for them to feel comfortable in, so that they can share their candid and honest feedback. How you present yourself is a big part of that. If I’m testing with adults I like to look professional. I try to wear a suit or a simple shirt and coat, fix my hair, and make sure the place I will be in looks organized and clean. Keep in mind that I do this while testing remotely. Of course, it is even more important (and evident) when testing onsite.
Present the findings
The same as before, once you’ve collected the data you needed, you need to digest it and lay it down in the form of a comprehensive report. I like to include the following items on a moderated Usability Testing report:
- Observations of the issues found, possible solutions and relevant notes and quotes.
- Lostness metrics that will help identify the current findability status of the website/app.
- Success rates, time spans and satisfaction scores while completing a given task.
- System Usability Scale (SUS) results.
- Information about the participants with links to the recordings from the testing sessions.
- A summary of the research questions, answers to those questions, action items and primary findings.
I also craft a second and briefer report, which I like to call the “Report Summary”. The purpose of this report is to make it truly easy for the client to build a presentation and get buy-in from his teammates/stakeholders. It includes:
- An executive summary with general findings.
- An overview of the metrics found.
- A conclusion with recommendations and action items.
What I like to do at this moment
I like to make very sure that I have no spelling and grammar errors, which can be fairly easy when using a spreadsheet. I also like to double and triple check all of the data points to avoid biased decisions. Remember that what you put into the reports will very much define the rest of the process.
Correct what needs to be corrected
If you performed the testing sessions correctly, then you now have crystal clear understanding of what needs to be polished in order for the UI to make sense to your users. You know where they got lost, so you can rework the IA; you know what UI elements confused them or dragged them away from their ultimate goal, so you need to correct your wireframes/wireflows/prototypes to reflect this knowledge; you know what their overall experience was, so you know what strategic changes you need to make on the user flows. Go ahead and do it.
What I like to do at this moment
I like to be very agile. Since it’s, even today, quite hard to get buy-in for doing Usability Testing, especially from small businesses or startups, since they sometimes have a limited budget to work with. I generally try to do all five testing sessions, create and present the report, and correct all the wireframes within one week. Therefore, the client only pays for one more week of work, and he gets so much goodness in return (and so do your users).
If you are testing with more users (because you need to test with more than one user type, or with more than one device), then you might need a bit more time.
Design
This is, for many designers, the fun part. You get here once you’ve done all the “paperwork”, collected information, tested assumptions and so on. It’s time to give life to your project.
Get inspired
Once, during college, a great teacher told me that the only way to become a good visual designer is to soak in quality design. By constantly watching and admiring good design you actually build a visual criteria and learn how to best combine shapes, colors, and fonts to create an interesting piece. This does not in any way mean that you should copy another designer’s work because as you of course know, that’s unethical. Also, I think you wouldn’t enjoy it if done to you.
What I like to do at this moment
Anyways, what I’m trying to say is that I like to start out by creating a visual mood-board, where I collect inspiration that is relevant to the current problem that I’m trying to solve, and to the audience that I’m trying to solve it for. That way I can get acquainted with the standard visual languages used in a set field, for a set audience.
Look and feel
This is basically the moment when you start playing around with your defined UI structures. You start building typography hierarchies, a color palette, an icon style and so on to move your design from wireframes to high-res mockups. Of course, you won’t always have full control over these design elements. Sometimes you’ll need to respect a set brand guideline.
What I like to do at this moment
I like to work on only the most important screen of the lot, and create more than one look and feel to show to the client. The minimum, for me, is three options. I present those options to the client, I explain the criteria used to build them, I collect feedback, and make the proper adjustments.
Mock it up
When your client has chosen the look and feel he wants to move forward with, it’s time to apply that style to the rest of the components and screens of your project. In order to make that job easier, I like to make a checklist of the most recurring visual elements, and create a Sketch document containing all of them. In other words, I create my most used symbols before I start to mockup the rest of the screens. This small action can streamline your design process and save you a lot of time.
What I like to do at this moment
I like to pay attention to all of the details. For example:
- Making sure all the layers, groups, pages and symbols are named and ordered (from top to bottom) properly.
- Using vertical rhythm to align and space my components vertically. You can check out this, this and this resource to learn more about it.
- Designing every single component state, every interaction and even every icon that will be used.
- Checking that the mocks are pixel perfect.
- Controlling that you didn’t use any extra colors or gradients (you might end up with 20 very similar shades of grey).
- Renaming all the art-boards so that they reflect the exact nomenclature used on the IA.
- Getting explicit consent from the client/stakeholders on all the designs.
- And more. ✨
Delivery
If everything went on as planned, you should be ready by now to hand over your work to the development team.
Prepare the deliverables
We all know the drill, so I’m going to make it short. It’s time to prepare all the exportable assets (which I like to share using InVision Inspect), the style guide and the editable files (which is optional if you’re using Inspect, because it already gives the dev team all the info they need).
What I like to do at this moment
I like to:
- Make sure I included every single asset in the project. It’s very easy to miss a few, especially when it’s a large project.
- Create a clickable/navigable and comprehensive style guide, which includes everything from the horizontal and vertical grids to the (very complete) icon palette. I use InVision Prototypes to do this.
- Check that the editable files are in shape! Organized and pixel perfect like I mentioned before.
- Provide desktop, tablet and mobile mockups, specifications and assets if necessary.
Stay focused!
It really depends on your work environment. In some agencies, or with some clients who outsource design services only, when you get to this part you get basically cut off from the rest of the process. In some other cases, you get the chance to be present and see your project through until its birth, and even further.
If that’s your case, be involved. Help out the dev team in any way you can, be ready and available to prepare extra assets, to explain how things work, to do Quality Assurance, and so on. Ideally, the dev team should be soaked in the project’s status and requirements, since they were involved from the beginning.
Once the project is launched, try to do some further testing, and watch over the analytics and other data (like direct feedback). Follow up with your team and see, with the data in hand, how you can further improve the design. And yes! Prepare for round two of the process. This beautiful and never-ending process to create quality user experiences.
Anything else?
Just two more things:
- I wanted to briefly mention that a workflow that has been giving me good results is working in sprints. Since that is a whole new story, I will leave it for another post. If you’d like to read it you can follow me on Medium.
- If you have the resources (time and budget), try to do as much testing and research as you can. The more data you collect, the more certain you can be about your design decisions.
That’s a wrap!
If you read this far, thank you. I know you probably have a busy schedule, and there are tons of content to choose from online. Thank you for dedicating some time to read this post.
I wrote it in the hopes that it might be useful for someone out there. If it was for you, I’m glad!
If you liked this post please go ahead and give it some 👏 so that other people can find it on Medium too. Thanks and see you soon!
