Published on | Prototyping: From UX to Front End — Medium Evie Cheng

The challenges and learnings

“To be agile in strategic consultancy is to produce quality insights over quantity, and reach the finish line with a tangible result. ”

Making UX workflow agile has been an ongoing challenge for UX researchers and designers in all kinds of organizations. How to generate and communicate insights more efficiently? How to bridging research and design better? And how to bring stakeholders and the customers closer? Working towards the same goals and directions, I found some slightly different situations, however, while adapting agile user research in consultancy. Here are some of my learnings and thoughts.

OEM, DMLS, EDM, LIM???

When working with clients with heavy reliance on industry domain knowledge, for example manufacturing, how can we collect and analyze data in the fields if we can’t even understand what they are talking about during meetings? Unlike in-house teams, picking up the knowledge and experience feels like studying to earn a second degree back in college for us. Definitely not easy. However, it doesn’t have to be time-consuming in this case. (After all, we’re not pursuing to become domain experts!)

Besides secondary research, we can learn through expert interviews and lightning talks. The difficult part, however, is to identify the specific areas that we want to learn about. Just like pointing out you want to learn motion graphic when you literally know nothing about design. Clients usually don’t know what we don’t know. So prepare all the questions you want to ask. Arrange interviews or workshops and ask clients to invite the corresponding stakeholders who are responsible of or know the answers. The more questions being clarified at the beginning, the less effort you will spend finding your way during the project.

“Wait… Did I mention to you we’re adding a new feature on the main page?”

No matter how hard we work and how much we care about our client’s product, there is no doubt that they are the owner of the product. In-house teams are working non-stop on other applications and feature extensions around the product every day. Sometimes the focus of our project needs to be shifted accordingly, or the initial issue might not be that important to them anymore.

To reduce unnecessary waste of time and effort due to lack of alignment or missing pieces of information, what should we do? With lower level of engagement and control over the product, how can we gather relevant information in order to conduct user research more thoroughly and more efficiently? Arrange daily stand-ups and more check-in points with key stakeholders and extended teams. It can be done remotely without being long. The point is to keep everyone in the project informed and updated. If you have sufficient budget and resources, form up a project team with clients and work together physically for a period of time might be a good choice as well.

The roles and responsibilities in execution

Sometimes we provide actionable strategy and ideas, sometimes we deliver tangible executions, and sometimes, we do execution with in-house teams. In the third situation, we need to get a clear picture of the stakeholders that would be responsible for the execution and make sure to include them from the beginning. It might not seem that important at first, yet it will heavily influence the quality of the final work.

I once worked with two in-house designers to execute hi-fi prototypes to be used during user testing sessions. From the previous meetings and information from the PM, both of them are UX designers and will come up with workable prototypes on Framer based on our testing guides and tasks. Problems began to emerge after we emailed testing guides to them. For example, they thought they only have to work on visuals of UI, expecting us to deliver detailed wireframes and flows instead of pictures of sketching and documents. Also, we prepared testing equipments and tools compatible with Framer, only to find out later that they are actually doing it with Principle.

All of these can be avoided, however, if we have communicated more directly and earlier. So make sure to clarify the following questions when starting a project: How many in-house designers will be working with you? How much time and effort can they allocate from their other projects and tasks? What are their expectations for their own roles and responsibilities in this project? Define clearly from the start what they’ll do and what they won’t do can help reduce repetitive time and effort spent on recapping. Also, it’s essentially important to decide the tools for team communication, collaboration, file sharing, prototyping and design at the beginning of each project.

Stakeholders, stakeholders and more stakeholders

When starting a project, most of the time we only talk to the PM who are responsible for the project. Without knowing who the other stakeholders are and what their roles and responsibilities are, however, can get us into trouble. You’ll find meet new faces in every meeting joining the project just now. The problem here is not the time spent recapping what we went through, but the potential risks that the initial project goals might be distracted and shifted with more stakeholders joining in with different expectations. Even worse, very often the key decision makers weren’t involved until the very end of the project. Without awareness of the context during the process, they make decisions based on personal preferences and opinions, which is definitely against human-centered design. (Boss-centered design, to be accurate.)

Discuss with your client to gain as better understanding of every stakeholder as possible. Key potential stakeholders include the decision makers (most of the time, top managers or directors) and the execution teams such as designers and engineers. Involve them earlier in kick-off workshops, or have a one-to-one chat in person with them. Figure out what they care the most, what they find most challenging now and what they expect to get from the project. Also make sure they join key project check points, such as user research findings sharing and work-in-process design review.

My colleagues and I even thought about doing internal stakeholder mapping for every project.

Conclusion

There isn’t one best-practice agile user research process to follow for in-house teams, neither for consultancy. We need to always plan research based on the stage of the product, project goals, research goals and of course the time and resources available. And more importantly, always consider company culture and UX maturity in client’s organizations.

Thanks for reading. Happy researching 🙂

Please leave a comment to share more about your thoughts!

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Getting Agile with User Research in UX Consultancy was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Getting Agile with User Research in UX Consultancy

Cool stuff, every week

More Articles