Making design process more development-friendly and business-satisfying
When we talk about design, we often look back into the design process that guides us. And as UX designers, this is also a question that is asked by clients, users, programmers, etc., at all times. And there are tons of articles talking about how to be user-centred, without making it clear on how to include clients and developers into this process, to make it more development-friendly, and business-satisfying.
A great product or compelling content without an appealing user experience may affect the ability of an organization to achieve its business goals.
Well, here are my learnings on how to do it.
I come from a background where people from different disciplines are working together on teams for various projects, so it is my observation that sometimes clients cannot articulate what exactly they need, nor can the team quickly pass ideation onto production, simply because there are differences in design/development process. Frankly, there is dependence matter and so much to discover over this topic, however, to make it easy for everyone, we will be only tackling the design process and talking about how UX designers can help with better decision making.
Debrief the undertaking (Understand)
It is essential for UX designs to debrief and try their best effort to understand what the clients are asking for. There are many questions UX designs can ask during a brief session.
Understanding is the core of UX Design. And some designers should take one step further, which is, trying to understand more about two different aspects, from both the users and the clients.
“If I had only one hour to solve a problem, I would spend up to two-third of that hour in attempting to define what the problem is.”
— Matthew Wakeman from the book UX Research — Practical Techniques for Designing Better Products
Clients bring us a design problem and it certainly serves some needs, in terms of achieving business values eventually. Since we are going to do user research anyway, then thinking about the product overall, having a business sense in mind, is always helpful.
For example, I get a task from a game company, asking me to design a different marketing dashboard that can analyze in-game advertising. In this case, I am told to work on a particular task, and it is clear and easy to understand. It is my job to follow up with my assumptions, things that may go sideways, or anything that needs to be further explained. First, who are the users of this dashboard, in other word, what is this for? If there is nothing mentioned about users, it is safe to just ask the client about this, or there are only assumptions otherwise. Second, marketing dashboard is a common tool on the market, so why do they need to design another one? What are these concerns they have or any pain points, as a client, they want to solve? This part is for UX designers to think in the shoes of their clients. I would like to respect that UX designers are looking after users, but having empathy with the clients is as important as with the users later on in the process.
Having that said, there should be more questions in the business aspect, goes like what is the business value coming out of this product.
Debriefing is a process where UX designers get to understand more about the problem at hand, as well as the client’s needs. If there is no problem to solve, then the design is left with look and feel, or even less.
Note: If UX designers are not getting the tasks from real external clients, then whoever approaches with a problem, even within the company that a UX designer works for, is considered as the client.
Envisioning Users (Research)
UX Design Basics are the fundamentals before getting started. Depending on different projects, there are many layers, from user persona, user scenarios, to user flow, wireframes, user tests and then finally deliver to UI design. So here we start from the very beginning, which is envisioning users, creating user personas.
User persona represents users based on their descriptions, goals, needs, and interests. So as I mentioned above, we need to always ask clients about who the users are, the target group will give us a hint of how to make a persona, or personas, in need for different cases.
Design personas focus on user goals, current behavior, and pain points as opposed to their buying or media preferences and behaviors. They are based on field research and real people. They tell a story and describe why people do what they do in attempt to help everyone involved in designing and building a product or service understand, relate to, and remember the end user throughout the entire product development process.
From uxbooth
This is a step we get confirmation from the clients and do our homework, analyze and understand the target group. Remember, the personas we create at this stage, are for the future testings to refer to. If possible, anything happens after, should be able to have a reflection on these personas, as they are the ideal users.
Another part of user research is about mapping the users so that you will have the possibility to understand better what is going on in their daily life. For example, how are their days going to be like? When are they going to use our product/service? What are the pain points/problems we are trying to solve with our product/service? Those questions can be answered by making maps about different scenarios.
This process can also be referred to the user journey, user scenarios, user map, story map, sitemap, a day in the life, so on so forth.
Yet they essentially talk about the same thing, to map out what the personas do and their encounters.
One thing that needs to be highlighted, is that the user journey is a stage where everyone on the team should take part in, because everyone has a different view of how the potential users are going to live their lives, and by looking through different glasses, we can maximize the value of truly understand the complexity of the design process and the problems we are trying to solve, as a team.
As mentioned, this stage should involve the whole team, because every voice counts. But next, we should bring another great part in.
When doing the user stories, UX designers should also facilitate the team to come up with features, ideas, or possibilities to overcome the pain points found in the scenarios. If possible, take clients’ notes into account, if they ask specifically for something.
Note: not every feature will be fit, but brainstorming is always a good way to shed a light on the problem-solving process itself.
Feature Scoping (Align)
Now, it is time to be practical and realistic. As designers, we understand the fact that not everything we design, would be implemented at the end. In most cases, designers deliver their designs to developers when they finish wireframe and interaction prototypes. That’s not wrong, but more common.
However, here I recommend asking developers to join a feature-scoping, where designers present user cases with features matched with pain points. In this way, the design team and development team are much aligned. This is to ensure that developers get to know what kind of project they are going to work on, and what exactly the clients and the team have come up with. More importantly, they get a basic timeline of how much effort they are going to put into making these features work so that they can roughly arrange their workload beforehand. Developers should use their skills to weight how much a feature matters to their development process, and make suggestions to project scope.
The features can be arranged as “must-have”, “nice-to-have”, or “maybe”, depending on the conversations with stakeholders, clients, developers, and of course, designers on the team. So this gives everyone a clear vision of how long it takes to implement one feature, and also a priority of what should be done first, in the production process,
As a team, it is always safe not to over-commit, and asking opinions from developers, is going to make extra chance to lead the project from design to solid, functional product. Designers and developers are meant to support each other, so be respectful to everyone’s work!
Note: This is not always happening, as some of the developers are not inside the design loop, they would get the brief and project at the end of the design process. Yet, it is still okay to ask developers to have a discussion, and this can be another aspect of research.
Wireframing (Sketch)
This is where UX designers literally start envisioning how this product is going to be like. Wireframes are simple drawings indicating how interfaces should be arranged. We can draw on whiteboards, papers, as long as what we draw serve our needs.
This is a process where we draw things to reflect on the research findings. And the wireframes are normally simple, low-fed, and as designers should always be prepared to re-draw.
It is rare to have one idea through the first wireframe, yet trying to focus on features that are scoped by the team and also based on user research. Keep in mind that this design should focus on problem-solving for the personas we create.
Moreover, at the wireframing stage, we can also set design principles, guidelines, to make sure that when we dive into UI design, or anything more visually appealing, the core cannot be ignored or overwritten.
That said, the wireframe is really helping designers to define what the product should work on a logic basis so that we can move to the next step.
Prototyping (Design)
Prototyping is the process where different wireframes are connected together and have transitions in between to reflect on the user flow. Prototyping basically brings your sketches to life. This is a process where we can also incorporate the basic interactions or transitions in designs.
There are many tools we can use in terms of prototyping, from SketchApp, Figma, to Adobe XD, and many more.
But here, I would like to use Figma, because all you ever need, is a link. And you send the link to your team, stakeholders, clients, developers, and they all can see it without downloading anything else.
With my experience working on Sketch, or Adobe XD, or even InVision Studio, they are too focused on what they do, yet they are not necessarily providing the access to outsiders who don’t know more about design.
But if you are aiming for a high-fed prototype, that has cool, smooth transitions, Adobe XD has the probably the most advanced auto-animation that helps with animated canvases, it can even support voice control! So designers, go try different tools out and find the best to fit whatever tasks you are going to do.
Testing and Evaluation
Before delivering, or finishing up designs, there is one most important thing that cannot be left out, which is user testing with evaluation.
Smart designers always test as they go. So whenever they have a basic form of concrete ideas, they can go testing. So in this process, a defined wireframe, with or without interaction, can be used for testing, based on needs. For this part, we are focusing more on structures, logic, affordance, and usability, and many more.
Yet, when UI is put in place, there are more things to test, colour palette, visuals, look and feel, etc.
There are different ways to test a product, and there are tools available to help with carrying user tests out.
And the time frame is set upon tests tasks, so whether it’s a quick test for a colour choice, icon choice, that may only need 5–10mins; or it’s based on logic, onboarding experience, even different use cases, which ideally will take up to 45–60mins, there’re so many tests to be looking into.
After testing, evaluation is always followed, to make sure that the test results are well-handled. And this process is also where designers can work as teams to look back to design specifics then make some meaningful changes. If necessary, new things that are added to previous designs, should also be tested, to make sure they are a good fit.
This loop continues, until the design is fairly solid, then it’s going to be developers’ job to make it work.
Highlight
In short, my design process that includes clients, (or stakeholders, or leadership)and developers. And by doing so, the team is much aligned, and so the team can achieve better outcomes.
We should understand that clients have their agendas, and they do not always take the side of users. At the same time, if designers can make programmers’ work easier, chances are, programmers can deliver a more functional product at the end. So help each other out, from the client’s brief, to design process, then to development loop, every part is uniquely important.
Summary
There are many ways of describing what your UX Design process is, and mine is put in this way:
- Understand, by debriefing the tasks and going after the values both for users and business.
- Research, by looking into users and creating users personas, stories, flows and many more.
- Align, by making sure we as designers have the clients’ need, developers’ voice and our own research ready, then let them be on the same page.
- Sketch, by wireframing basics of design specifications and always being ready to change.
- Design, by adding more layers to design structure from UI, visuals, and many more.
- Evaluate, by testing and refining on designs till the next step.
- Deliver, by respecting our teams, and our works.
Thank you, and happy designing. : )
