#30dayUXchallenge [Day 1] Intro: the UX cycle
UX Cycle. UX Process. UX Loop. UX practices.
You name it.
But somehow, at the end of the day, we are all talking about the same thing. What is the ideal UX Process? And, even further, what makes it ideal?
So, as part of the #30dayUXchallenge, I want to kick off this conversation based on my most recent work experiences, the giant IBM & Envato (a 10-year-old start up), with the topic that will drive our next 30 days. The UX Process.
At IBM, we used to start the conversation by talking about the “loop”:
At Envato, in a nutshell, the conversation looks more like this:
And what these two companies (even though, completely different to each other in structure, values and users) have in common?
At IBM, the loop represents how organic the UX process is and why we need to be constantly observing, reflecting and making.
What does that mean?
It means we need to “observe” where we are, how our users are using our products (or why they are not using our products) and what their real needs are. The product team then “reflects”, together, on which of these identified problems can be solved through design (that being a product or a service, for instance) and, last but not least, a prototype is “made” so these ideas can be tested. And then the whole cycle starts again.
Overall, the process involves understanding the real needs of the user before designing for them, so we can make sure we are “building the right thing”. And as soon as the designs start, testing if they actually make any sense, so we can make sure “we are building it right”. And the loop is what I love the most within this process, as it means this cycle keeps repeating itself until the product is launched. And it then starts again on new releases.
Have you noticed the similarities already?
At Envato, we want to make sure we understand if we are building the right thing first, and then we concentrate on building it right — which is, somehow, the same as the “observing, reflecting & making” approach from IBM, just communicated differently and executed with different tools.
The point I want to make with this comparison is: no matter how we communicate what is our process and what needs to be done to make sure our goals are achieved as UX Designers, at the end of the day, what makes the UX Process ideal is making sure you are not alone in this fight.
So here are two of my personal rules for making sure we are not alone in this fight:
- #1: design with your users in mind (and in heart).
User Centred Design is all about designing for your users, right? We all know that, we understand we are not our users and we don’t let our own opinions get on our way. Our goal, as UXers, is to find out what brings value to our user, and not which feature can be developed faster neither how to make something pretty. That requires a lot of research (and empathy), but it’s the only way we can make sure our user’s needs will be addressed. And talking about user’s value… - #2: Good teams work together
That also means the entire team needs to be on the same page. If my Product Manager and my Dev Lead don’t understand the importance of research & test, I am still alone in this fight. If the product road map is not driven by value to the user, we will be very likely to design products that our bosses love. But will our users love? That’s hard to say. It’s essential to keep the business goals in mind, but as the UX designer for the project, we are entitled to support the team finding the ideal balance between user needs, business goals and technical constraints. Finding the middle ground is always a challenge, and that’s why there is nothing more important than keeping the team in the loop and playing the devils advocate between these three pillars (user needs, technical constraints and business).
By putting these three pieces together, the UX Process basically ensures that the product team is aligned with the direction of the product, and, most importantly, the direction of the product is aligned with the user’s needs.
So, when the question comes:
Here it goes my humble response in a visual manner:
What the representation above means is that having a solid UX process in place is essential to ensure your team will have dedicated milestones:
I’ve learned through the hard way that starting a new project without a proper kick-off with the team usually ends up with a project without a clear goal. Dedicating enough time to explore the problem space (or opportunity) and determine what is the direction your project is aiming for is essential for a successful outcome (If one does not know to which port one is sailing, no wind is favorable…).
Potential outcomes: Problem statement/Project goal, Persona/Empathy Map, Risks & Assumptions
Avoid: jumping into solution mode just yet.
The problem space will also support the team to understand what the research should focus on. The research will then validate the assumptions identified previously and will support the team to get a better understanding of how the solution can address the user’s needs. So yeap, you read that right: at this stage, we interview users, analyze competitors, dive deep into any data available and use the findings to support our decisions in the next steps.
It’s also important to remember that research can play a vital role influencing the Problem space exploration as well, if the timeline permits.
Potential outcomes: Research plan & research findings (refined personas, user journey, competitors & industry practices, validated assumptions, etc)
At this point, we have a clear picture of our personas and the gaps the solution should be filling. It’s time to solidify ideas: from sketches to wireframes, we start the repeated cycle of designing and testing, testing and testing again, until designs are solid enough.
Potential outcomes: Sketches & Wireframes, User Test Plan / Findings, IA/sitemaps, etc.
Avoid: working in silo. It’s essential to validate the concepts with the team, no matter the level of fidelity and the maturity of the concept.
When designs are mature enough, we start to pair with the development team to build it. Our vital role in this step is to ensure nothing gets lost on the way and the product reproduces exactly what was designed.
Desired outcomes: Wireframes & High-fidelity visuals, Interaction Notes, States, Breakpoints, Screens specs or styleguide.
Avoid: This should never be the first time the development team sees the designs. Keeping them in the loop as designs evolve is essential to ensure that no technical constraints will surprise us down the road.
After designs are implemented, we need to dedicate some time to observe if the solution is meeting the expectations and addressing the user’s needs as expected. It’s time to observe users actually using it, to reflect upon and design the next steps. We will then start the whole cycle again.
Desired outcomes: A/B testing, User tests, Metrics (Google Analytics, heat maps, etc)
Team alignment
You probably noticed that “team alignment” is right in the heart of the diagram above. I can’t stress how important this is in the process: having constant check-ins with your product team will ensure that the decisions made are based on the 3 pillars mentioned above: design, development and business. Involving the entire team on the project since early stages will ensure different perspectives will be added to your concept, as well as guarantying you alignment and buy-in.
I usually take as a rule sharing my designs “early and often”, as nobody should be surprised — at any point.
As it is probably not even realistic to try to consolidate the UX Process in a diagram, here is a more realistic version of how it looks like in practice:
At this point, you might be thinking “I wish I had time to cover all of this on my projects”. But fear not! These steps can be covered in 6 days or 6 months. It always depends on how much time you can invest and what are the resources available. Covering it in 6 days doesn’t mean you need to skip any steps, just probably means you need to be creative on how you approach each phase!
So maybe you want to stick around to see how UX Strategy can help your team building a user-centred product? That’s the topic we will be covering tomorrow, on Day 2 of the #30dayUXchallenge!
From your perspective, what is the ideal UX process and how would your UX Process diagram look like?
If you feel like jumping in and giving it a go, what about trying to outline a project plan communicating how your project would approach the topics above? Don’t forget to share and tag #30dayUXchallenge so we can take a look too :)
This post is part of the #30dayUXchallenge: you can read more about why we started it here, and don’t forget to follow us on Twitter and Instagram!
Originally published at medium.com on November 1, 2017.
