UX, as exercise, is a series of discrete individual (yet interconnected) steps - a process - for guiding a team to producing the best UI, Information architecture and features of your website or app.
Each of these steps requires a skill borne of experience, schooling and/or simply jumping in and doing them.
Each could be a single person/team. Often, as in the bulk of my career, these skills reside in one person. A UX team of one can be quite effective with the right energy, drive and environment.
I decided to include what I and the industry believe to be the best practice so that anyone who doesn't understand what we do can have a baseline of understanding when we talk.
At the outset of a project or product kickoff, the User advocates should be at the table along with leadership stakeholders, content creation, marketing and development depending on the structure of your entity. This is the Discovery phase and crucial to finding out the motivations of your team, the initial user /customer groups and the basic business structure you will contend with during the complete cycle of making the experience being envisioned.
We can talk about the nuance of psychology, bias and enthusiastic ideation here but we'll leave that for a podcast or article. Suffice to say, this conception stage can reveal the very challenges your team will be dealing with as they carry forth and being a good listener is crucial.
Understanding your user/customer/audience is crucial at the incept of your project. All decisions that are user-centered will cascade from the qualitative and quantitative data you collect during your research. I've called this section "research" in the abstract because user research is one part of the landscape. We can Ethnographic research, competitor research, historical data research, market research and more depending on the need identified during the brainstorm/problem space discovery.
The work-product of user interviews, a persona is a visual representation of the data you collected on either a user specifically or a user group that falls in to a specific category of users. There are two distinct uses for personas in my experience - the making of the persona itself will reveal all the insights and actionable knowledge during the collation and crafting process which you can use in following steps, after creation the persona has a valuable role to play in informing your broader team and company about WHO your users are so they can act and move forward in their own tasks with a clear picture of their user in mind.
At this juncture, you should have enough information to define and refine what the team thought the problem or solution was in the Discovery phase. Some teams attempt to define before doing research and some interviews but in my experience this is premature without the qualitative research in front of you. If you haven’t done research with actual users, this is the most valuable enterprise you can conduct for your company - the insights alone are invaluable.
A crucial step that can be done parallel to research since you employ similar tactics, IA is the foundation of how you present your product/service to the world in a way that your users understand. Card-sorting is one tactical process for sorting out your IA, where a user (existing customer or prospective customer) takes high-level concepts written on paper/stickies (or virtual via a card-sorting app) and puts them in categories that make sense to them - the result is a series of buckets that inform your site topology, navigation and taxonomy (a great little term stolen from the biology world). The basic way to think about IA is that your user needs a way to get from one ‘room’ to another in your site ‘house’, and they will want to use a methodology they understand already.
This is a less-well-known skill but certainly important in some circumstances. An interaction designer understands, intimately, exactly what users click or tap on, what happens afterwards (or during) and what this means. Animations and feedback can be subtle but important to the journey users take, for one example.
This is where you start to take all the data you’ve collected, along with the functional requirements from product management and technical constraints from development and put it all into visual form. Wireframing, for those who don’t know, is a rudimentary (low-fidelity), layout of the pages and interactions of your potential site. During wireframing, you want to explore all the possibilities within your UI toolbox to present the most usable set of options you have. This is where you must have faith because the next step is where you will start to discover if you’ve been able to propose the most usable UI or not. Check your ego at the door.
When you have your wireframes built, you should put the into a prototype format. There are dozens of programs out there that will take what you’ve drawn and link them to other pages or layers to give the illusion of a fully functioning site. This is typically the job of the researcher, to gather some of the similar users/customers you used for the research/persona stage and bring them in (or digital meet) to test your prototypes. What you should end up with is a long list of things you failed at or didn’t think about when you did your wires. This can be depressing to the designer that has a lot of their ego invested in their work because you will likely be disappointed at how unusable some of your work ends up being. Back to the drawing board because what you’ve learned will be essential to the continual improvement of your design. Complete as many cycles of this Wire-test-learn cycle your budget/team/leadership/deadline can tolerate as it is the most valuable process here.
The graphic designer should be brought in at some point prior to the wireframing step in order to discuss the parameters that they will use to craft the colors, shapes, type and layout style prior to being handed the final wireframes to “make pretty”. A good visual designer is worth their weight in silicon and should be able to turn your data-driven process into a branded and inviting UI to be proud of.
When your team’s product is coded and in production, especially if it is part of a potential suite of products or may have a life that involves revisions or updates over years, you will want to create a Design System. Design Systems have been around for many decades as style guides but in the digital world and the last 5-6 years, a good design system will contain much more than a set of styles to follow going forward. In some instances, you may want to include actual front end code to allow future team members to get up to speed quickly on a new feature.