November 13th, 2024, posted in for_founders
by Adelina
This article is part of the Stress Testing series of our UFOs UI/UX Framework. The framework is a tool we created based on our 10+ years of experience in building complex software and thousands of hours of design meetings and feedback. Developers, designers and entrepreneurs can use this framework to gain a better grasp of the UI/UX process and build awesome apps as a result. To learn more about the UOFs UI/UX Framework and each framework component, please go here.
This article is part of the “s” from UFOs, the framework component that talks about how to ask for and get useful feedback on your designs from stakeholders, including your end users.
If you`ve ever presented a UI design project to a client, this scenario might sound familiar. You go into the meeting prepared with a nice speech and mock-ups for the core features of the app. The meeting goes well, even better than expected. The client seems engaged and they appear to like your ideas. At the end of the meeting, they promise they'll send feedback after they review the screens in detail.
A few days pass and you receive the feedback email, only to realize there is actually very little useful feedback. Rather than commenting on how your designs align with their business goals or on unaddressed requirements, the client seems to have missed the point entirely. The feedback revolves around colour choices, the size of the logo or even the copy when in fact you are still in the product discovery stage. This is the stage where you should be mapping out the core features and flows of the app. What went wrong?
Rather than using the presentation meeting just as an opportunity to show off your work, you can turn it into a feedback guide for the app`s stakeholders. This means not only explicitly telling them what kind of feedback you need, but also providing them with enough context to understand what they should focus on.
The following formula will guarantee you receive useful feedback, regardless of the stage your project is in.
Feedback formula: (what/who + context/problem + stage + feedback instructions) x tools
Each element of the formula is detailed below.
WHAT type of app? WHO are you asking feedback from?
The first thing you should consider is whether this is an internal application or a commercial app. Will the stakeholders be using the app themselves? The second thing is who are you presenting your work to. Are they business owners, marketing people, engineering people or even UX designers themselves?
Keeping these two aspects in mind will help you ask for feedback appropriate to their expertise. Of course, the end goal stays the same (e.g. building an inventory management app), but you will be surprised to discover various business angles depending on who you are asking feedback from.
Particularly if you are building an internal app, make sure to ask your stakeholders questions about their workflow as you are presenting, even if it's just an educated guess. This might make them aware of things which would otherwise go unnoticed. It can also serve as a good starting point when it's their turn to comment on your work. It's important to encourage clients to approach the designs with a critical eye from the get-go, so issues don't surface later in the project.
What is the CONTEXT? What PROBLEM are you solving?
If it's one of the first few meetings, remind the client of the overall context. For example, you might be working on a redesign project. The redesign project might consist in small touch-ups or in a restructuring of the entire app. Remind the client of either of these cases. This will help manage expectations and prevent scenarios where the feedback demands major changes when you previously agreed upon only on small, incremental improvements. Providing context for your work might also mean specifying the type of users who will be using the screens you are presenting. Or when in the user journey will the user be seeing these screens.
After offering some context, move on to the actual problem your screens are addressing. What are you trying to achieve with these designs? What task should the user be able to accomplish using these screens? Make it clear that the feedback should refer only to that/those tasks.
What STAGE is the design in?
Emphasize during the presentation the stage the project is in and how this reflects on the design and the type of feedback you are expecting. This will prevent comments like “put an icon on that button and move it to the left” when you are debating whether the entire section is actually needed or if it's in the right place (a common thing in redesign projects). If you are looking to solve structural issues, make that clear from the start. If the designs are in a more advanced stage and you want to dig deeper into the look & feel, CTAs or even headlines, make that clear as well.
What kind of FEEDBACK are you looking for explicitly?
Now it's time to put everything together and explicitly ask for feedback. At the end of the meeting, summarize the points mentioned above and encourage your client to give you feedback (you can also point out what they should ignore; e.g. “please ignore the colors, because we haven`t settled on a color palette yet”). Include some example questions to serve as a starting point for your client.
As an Operations Manager, could you please give us feedback on the e-commerce app we are redesigning? We agreed to keep the overall UI pretty much the same and focus on enhancing some key flows. So, please ignore colors, fonts or other aspects related to look & feel and focus exclusively on the new functionalities. Today we talked about Fulfilment and we introduced the possibility to track packaging tasks, particularly to see who packaged a specific order and how long it took. We also added the possibility of generating reports for managers to track employee productivity. We would appreciate feedback on these new Fulfilment features. Do you find the flow intuitive both for workers who need to log in their hours and for managers who need to track them? Are there any additional metrics you would like to track?
You can also specify a deadline for the feedback or the format in which you would like to receive it. Which brings us to our last point.
What TOOLS should the client use to give you feedback?
If you would like to receive feedback in a specific way, make sure to let your clients know. This can range from a bulleted email to comments provided directly in the design file (Figma has an in-built comments feature) or even dedicated apps for gathering user insight.
Stakeholders are your design and development partners, so getting useful feedback from them is essential. Plus, they can bring a unique perspective since they know the ins and outs of their business. Use the formula to get good feedback, understand the design problem space and develop solutions aligned with the business objectives.
Interested in kicking off your development project? Tell us more about your product and let's work together to make it happen.
