‍Hello!. Some may negatively evaluate our product, waste our time, or use it in a way that may harm themselves or others.: Hello, in today's episode we continue the topic of patient experience. So if this is something that interests you, I invite you to listen to this episode. And our hospitality will be , which has been working for many years . I invite you.

‍

Ilona: Dear listener, today's episode is for you. This episode is dedicated to those who would like to start a collaboration, undertake a project, and are wondering what the process looks like when they contact us…

‍

Radek: And submit their inquiry.

‍

Ilona: Yes, you just click ask an expert and send us a message. What actually happens? What does client-versus-us collaboration look like?

‍

‍

What's your situation?

‍

Radek: First, it's worth noting that we recognize two situations you might find yourself in.

You might be someone who is starting from scratch. You have a project or product that needs to be built and designed. You're a blank slate.

Or you're in a situation where the product already exists. It could be a startup or a scaleup that's really thriving. Or a mature digital product that has been on the market for over a decade and needs some improvements.

If you find yourself in any of these situations, you can certainly write to us. You can contact us.

If you're in such a situation and you know that a UX agency is the right one to start cooperation with. You want to ask us something and see if we're a good partner… You go to the website, click "ask an expert," and wait for our call.

‍

‍

First conversation: What to ask?

‍

Ilona: Yes. Usually, we pick up the phone then, and one of us calls you to hear about the context of your product, your problem, and your goal.

‍

Radek: And tell me, Ilona, what questions can one ask us then, for example… because I imagine it's not always easy to reach out from the other side. What can I ask about? What questions can we answer during such a first conversation?

‍

Ilona: Considering the first scenario, which is if you want to build a new digital product, the typical question we get, which you might ask us, is:

• Are you able to build an applicationwork?
• I have a business idea, can you help me validate it? How does that even verify it from a UX perspective?
• I have an idea, but I'd like to reach users.
• I want to conduct research, can you help me with that?
• How much would it cost?

However, for those mature digital products that have been on the market for some time:

• Do you see any problems in our product?
• Do you see anything that could be improved?
• You share your concerns, you say about business goals, about user journeys that might not be working from your perspective, and that you'd like to improve
• Is such a thing even needed in my case a redesign is needed?

Radek: You can also ask about the costs of specific actions. We can give you a general range for certain rates or processes. This way, you can quickly assess whether it's a good time to start working with us, or if it might be better to wait a little longer...

We will certainly be able to answer such questions, or at least we'll do our best.

‍

‍

First conversation: What might Zima ask you about?

‍

Radek: We'll certainly ask some questions too. These will be various questions that will help us clarify or deepen what you've brought to us. Or they might be questions you haven't asked yourself yet, and are crucial from the perspective of your situation.

‍

Ilona: I think a fundamental question we'll always ask you is about the project's goal. What do you actually want to achieve with this project?

This is something that doesn't change. I don't think you need to prepare for this. That's the most important thing.

Then we'll definitely ask you what stage you're at. What has already been done? Do you have any materials that would help us delve into the topic?

‍

Radek: Are you collaborating with anyone?

‍

Ilona: Yes. Who is this service aimed at? What do you know about your users? What do you know about their pain points? What are the alternatives? Do you have any competitors? Do users solve this problem in an alternative way?

‍

Radek: And have you worked with a UX agency before? Do you have any expectations?

‍

Ilona: Yes, exactly. Are there any expectations for the collaboration? This ties in nicely with the goal...

These are the basic questions we always ask. Of course, these can be deepened with contextual questions that arise from our discussion. But these questions form the framework of our initial phone conversation.

This conversation allows both parties to get an initial sense of whether there's any room for collaboration at all and if we can help. Sometimes, we're unable to provide a specific solution.

For example, if someone comes to us for development services... We are not developers, but designers, and we won't do such an implementation. We will create the design.

So, during such a conversation, by asking about the goal and what needs to be delivered, we can determine if there's common ground for discussion.

‍

‍

Second Call: Video Conference

‍

Ilona: This leads us to schedule a video conference, which will be a bit longer than the initial five-to-ten-minute phone call. During this more extensive discussion, we'll dive into the specifics and ask about all the surrounding aspects of the project.

‍

Radek: Yes, in the meantime, we'll be doing our homework. We can visit your website and review the materials you provide.

So, there will be more questions during the second meeting. In addition to discussing aspects directly related to your project, we'll certainly inquire about things like:

• Project deadline.
• Who will be involved in the project?
• Who is the sponsor or decision-maker on your end?
• Do we have any technological limitations?

We also inquire about the budget, as it's a crucial factor throughout the process that helps us define the project scope. Simply put, understanding your constraints allows us to determine how to best allocate resources and structure the process to achieve your desired outcome with the available resources.

‍

Ilona: Exactly. And depending on your current stage, this meeting might conclude with us receiving additional materials from you. This could be a pitch deck if it's a new product, or platform access, or an analysis presentation. Perhaps an audit has already been completed...

So, we take the time to consolidate our initial questions and insights from this in-depth meeting, analyze the materials you've provided, and determine which of our designers has the best expertise to lead this project.

‍

‍

How do we assemble the team?

‍

What should this process look like? What exactly should we propose? What's the best way to achieve the goal we previously discussed?

‍

Radek: During this conversation, we also try to discuss, in general terms, which model we could work with. We present the general outlines.

This helps us get an initial idea of what might be suitable for you and what definitely isn't. Because at Zima, we work with several cooperation models, and they are designed to be diverse and effective in various situations, ensuring a good fit.

We'll definitely talk about this for a bit too. So we can see your reaction and you can give your initial thoughts on the matter.

‍

‍

Zero Workshop

‍

Radek: And what happens next? We've had this meeting... I understand that now we should schedule a zero workshop, if needed.

‍

Ilona: Yes, in this case, when the project scope isn't fully defined, or you have many ideas and possibilities, and the path to achieving the goal isn't yet fully specified... but we know what the goal is... then we try to work it out together and propose a zero workshop, which allows us to develop that strategy.

‍

Radek: Yes. There are situations where you might know what you want, but during such a conversation, it could turn out that it's not the best way to achieve your goals.

For example, purely hypothetically: you want to conduct qualitative research, interviewing 6 people. During our conversation, it might turn out that this process is unnecessary because, for instance, we can find enough information through desk research.

For example, it might be more important for you to confirm this at scale, meaning creating a survey and conducting quantitative research. So, the initial idea of doing qualitative research with interviews might not actually be a good one.

And now, to uncover this... and certain assumptions will emerge during this conversation... the zero workshop, among other things, is a moment to rediscover what needs to be done to reach the goal you want to achieve faster.

It often happens that with large products, where the collaboration is expected to be on a much larger scale, the moment we enter the zero workshop is crucial. This helps us understand where the real pitfalls are that need to be addressed, and where we need to build up what we call "hills" on the customer journey.

‍

‍

Pricing and Cooperation Models

‍

Ilona: Yes, and here we have this one branch where we have the zero workshop.

For projects where we have a defined scope… for example, building a marketplace, and from our experience, we know how long such a project might take… then we analyze your materials and, together with the team, try to provide a time and cost estimation based on the scope.

How much such a project could cost, broken down, of course, into specific stages. For example, the first stage of familiarizing ourselves with the business to understand how it operates, to understand the environment... that's one price.

Then, design, testing, or research are broken down, and you see exactly what our idea is for solving your problem.

For other projects where we commit to a longer-term collaboration… And we have projects, for example, where an entire application needs to be developed, and it's impossible to define everything upfront. Because, for instance, your roadmap (action plan) is set month-to-month, quarter-to-quarter… and a certain pool of hours for an experience or interface designer is needed…

Then we work in the time and material model. And here we focus more on selecting the most competent person to be able to address all the requirements or goals you have. Or two people...

‍

Radek: Or three…

‍

Ilona: That depends on the need.

‍

Radek: Yes, we call this model a design team by subscription.

‍

‍

Design Team – how does it work?

‍

So you simply get a dedicated team from us for a specified number of hours. And again, it's flexible, as this could be the equivalent of one full-time person, within which you receive several competencies.

Thanks to having just completed the zero workshop, we'll have a rough idea of the scope and competencies needed. So we can move forward and start our collaboration.

We can opt for time and material, also known as hourly billing. And depending on whether we managed to define a specific number of hours during the zero workshop, for example, 40-80 per month, we are also able to offer a lower hourly rate.

Do you run an IT business and notice a market slowdown? Do you want to streamline your roadmaps or pivot? Or perhaps chaos has crept into your organization?

Business realities demand readiness for rapid change, which is often hard to predict. Download the Business Hero Cards tool — How to Grow Your Business in a Crisis, which will help you quickly assess your business's health, identify directions for growth, and inspire action.

In the PDF, you'll find:

• key questions to ask yourself during challenging times
• crisis case studies of famous brands
• soft skills and canvas-type solutions to apply during a crisis
• tips from our experts such as Dr. Aga Szóstek, Szymon Negacz from SellWise, or Damian Strzelczyk from Tutlo

By entrepreneurs, for entrepreneurs.

To download the PDF with hero cards, go to designzima.com and click the link in the menu at the very top of the page.

‍

‍

Who will be working on the project?

‍

Ilona: What's important to me in this process, and I think to you, the listener, as well, is knowing who will be working on the project.

We pay great attention to selecting a team that not only possesses the right competencies but also fits your project personality-wise. Another value we provide is working with experienced designers — in every project, there's someone with at least 6 years of experience.

‍

Radek: And she designs, meaning she's responsible for the project and actually executes it herself. She's not just a leader who tells juniors or less experienced individuals what to do. Because that's important.

‍

Ilona: Yes, having worked in the market for several years, we've come to realize that such a model simply doesn't work. We want you to feel confident that the people working on your project truly know what they're doing.

‍

Radek: Yes, and thanks to a meeting like the zero workshop, you'll be able to get to know them and see how they work. If anything doesn't suit you, you can report it, and we can remodel it in some way.

‍

Ilona: The next step is meeting the team. This can happen during a zero workshop. It can also happen during a meeting we organize when discussing pricing and introducing the team. Or when we discuss a design team subscription, where the first step is also selecting the team and having joint meetings.

Okay, so... then we start the project?

‍

‍

To wrap up

‍

Radek: Yes, the project starts and we keep working together!

That's all regarding the first steps in collaborating with Zima. What can you expect? How to prepare for such a process? What can you expect from us?

Feel free to be direct and verbal. Because that's our standard. That's how we want to onboard our clients into collaborations and wonderful projects. I hope to do the same with you soon!

‍

Ilona: Great, thank you very much for listening to this episode. If you're considering working with us, the best way to start is to visit our website. Click ask an expert in the top right corner and send us your question.

‍

Radek: Thank you very much.

‍

Ilona: Thanks, bye!

‍

Did you enjoy this episode?

‍

We are designers. We run our own agency and share our experience and practical knowledge, which comes from the projects we implement.

‍

‍

Too many ideas at once

‍

Ilona: And today we're tackling another problem that we encounter daily in our projects and that our clients come to us with.

Namely, they have a lot of ideas for functionalities to include in the product. And they don't quite know which ones genuinely bring value and which ones customers will be willing to pay for.

‍

Radek: Yes, and this uncertainty stems from the fact that we have different people on the team who might view our product and its development a little differently.

A person who is a product owner will think about it differently. A designer will think about functionalities differently. And someone who is the originator of the entire venture will think about it differently still.

When you gather all these ideas into one basket, it turns out to be a really large collection. And it's very difficult to choose the key functionalities for which... as she said earlier

‍

Ilona... for which the client will pay.

‍

‍

What will the client pay for?

‍

Ilona: And this situation will apply to products that are just starting out (meaning they're not yet on the market and are currently being developed), as well as those that are already on the market and looking to grow.

The problem remains the same — what to put on the roadmap? What to include in the plan as the next functionality so that the product brings greater value to users?

‍

Radek: And there are two levels to this problem.

The first level is when we internally within the team need to create a shortlist of functionalities, which is still a hypothesis, but a concrete one.

The next level concerns the user. This is a list of functionalities that the user will identify as interesting to them and potentially worth paying for.

‍

Ilona: And at this point, we come in — the user experience designers.

‍

Radek: We won't come ourselves, you have to come to us…

‍

‍

The buy a feature exercise

‍

Ilona: OK… so when you come to us and ask for our help, we'll pull out an exercise from our bag of tools called buy a feature, which loosely translates to "buy yourself a feature."

‍

Radek: First and foremost, this is an exercise that works perfectly in these two cases when prioritizing that long list of functionalities that we managed to create as a team.

It will also be useful in discussions with the user to finally narrow down this list to its ultimate form.

But what are the mechanics of such a study like?

Before we explain the basic form of this study, it's worth mentioning that it is highly adaptable. It can be conducted individually with one person, or as a group session.

In this core, buy a feature is primarily a simulation of the purchasing decision-making process, whether in a group or individually.

And now, let's imagine we have a list of, for example, 30 functionalities. Each of these functionalities has its own price...

‍

Ilona: And the price varies. One feature costs 1 PLN, another 10 PLN, and another 15 PLN.

‍

Radek: Yes, but if we were to sum up these amounts, it would come out to, for example, 100 PLN. And the person participating in the study has 60 PLN in their wallet.

‍

Ilona: Which means they have a limited budget.

‍

Radek: Yes, meaning they won't buy all functionalities. They have to decide for themselves which of these functionalities to buy.

‍

‍

Quantitative and qualitative knowledge

‍

Ilona: On the one hand, we limit the budget, and within that limited budget, our respondent chooses what is most important.

As moderators of such an exercise, we sit next to our respondent, see what they choose, and have the opportunity to ask them about their reasons. We can ask them why. This gives us a great combination of quantitative and qualitative knowledge.

‍

Radek: Yes, and with such user research, for example, in a 1:1 session... Let's say we conducted 6 interviews with a buy a feature study... Then we can quantitatively calculate how much was spent on a given functionality in that group.

Qualitatively, we can also gather feedback from customers on why they made a particular decision. Why did they spend their money on these functionalities and not others? Which ones were a difficult choice for them? Where did they hesitate?

This is very important qualitative knowledge, which is then used, for example, as a sales argument.

Here we touch upon a great relationship between design, which brings some insight, and marketing and sales, which can use these arguments in communication to sell a given product.

This is an absolutely crucial aspect.

However, when it comes to an exercise during the phase where we're within the team, discussing functionalities that each of us brings to the table, it's a great opportunity to discuss each one of them.

It's an opportunity to truly consider together the various aspects associated with introducing a particular functionality.

Because it's not just part of our strategy, but also, for example, our budget, which the technology required to develop something might consume.

And of course, there's the user aspect itself. To what extent do we believe it will genuinely bring value to our client.

So this is also the moment where we, as a team, can discuss and think about it together. Usually, in our daily work, we don't have the time to tackle this and truly work through the topic step by step.

‍

‍

When we don't know what to test

‍

Ilona: Radek, I have a situation for you. Let's say I represent a product that's been on the market for some time, perhaps two, three, or four years. We have a huge backlog of features, and we want to test some of them with users, but we don't actually know which ones. What should we do in such a situation?

‍

Radek: I understand you're a client who visited our website www.designzima.com and contacted us through our form.

I would definitely want to start by collecting from you a list of all the feature ideas you have. And I would investigate the basis on which that list was created, because I wouldn't want us to work on things that just appeared out of nowhere.

I'd like these to be things that consider user-suggested functionalities. This applies if we have such suggestions, or if we've gathered this information from research we've conducted.

And I'd like these to be ideas that are inspired by our competitors. We see that the competition has introduced something, and we suspect it could work really well in our product. Or, for example, we might have some enhancements based on what we've already observed from competitors.

And functionalities that were developed based on our strategy that we aim to pursue. This is also extremely important. As a company, we have ambitions and aspirations; we want to achieve certain goals. And these functionalities must also be consistent with that direction.

‍

‍

Must have, should have & nice to have

‍

Radek: Bearing in mind that our goal is to arrive at a shortlist that we can then test with users, we first need to conduct an internal 'buy a feature' exercise.

To do this, we need to assign a value to each of these features. And we assign this value through an exercise called must-have, should-have, and nice-to-have.

The point is to group our features by, for example, cost, difficulty, or how necessary we think something is for the user.

And for example, must-haves are features that are inexpensive, which we consider the core of a given product or part of a product. And here, we are almost certain that they should be included.

Should-haves are features we're not entirely sure about. We don't quite feel... It seems to us that they should be included, but we're not as convinced as with must-haves.

Nice-to-haves are total bells and whistles. These are usually expensive things that don't build core value.

Once we have all the features that we previously listed in these three areas, we can assume that all features categorized as must-haves are worth one point.

Should-haves will have two, and nice-to-haves three.

This means that during the study, as a user, if I want to buy a feature that has been designated as a must-have, I will have to spend 1 point. To buy something from nice to have, I will have to spend 3 points, which is more.

This is very good because for the exercise itself, we can assign specific amounts. For example, a must-have feature costs 10 PLN, a should-have feature costs 60 PLN, and the user's budget is 120 PLN.

But you came to me, Ilona, as a client. So, after this prioritization, I would probably suggest an exercise with your entire team.

I would take 4-5 people who are primarily responsible for the creation or development of this product and conduct a group session with them.

I'd like you to collectively decide what your shortlist of functionalities will look like.

This is a great opportunity for you to have a lively, responsible, moderated discussion about what will make it onto this shortlist.

‍

‍

Tallying points

‍

Ilona: Alright. We've had this discussion, but the question still remains: what should we test?

Radek: We prepare a summary of this research. On the one hand, we tally what was indicated, what was "bought." On the other hand, we detail all your arguments.

Depending on the list we ended up with... because it might be that there are far too many functionalities to approach the user and conduct a similar exercise with them... in that case, we still make a joint cut, which is our recommendation, based on what we heard in the research with you.

‍

‍

How long do you have to wait for results?

‍

Ilona: How long can such a process take?

‍

Radek: If we're talking about an internal buy-a-feature exercise, it's two weeks. If we also include the process of discussions and research with users, the entire process will take four weeks.

‍

Ilona: So we can say that we can start with a very large cloud of functionalities, and after four weeks, we can end up with a tested list. We have our priorities sorted out regarding what we should include as the next feature on our product roadmap.

‍

Radek: Exactly. But let's remember that buy-a-feature won't tell you 100% what your user will pay for. It will suggest what your user *might* pay for. And that's already very valuable.

Thanks to buy-a-feature, we can reduce the risk that might arise if we make a mistake, if we launch something based on what we merely assume.

While intuition very often doesn't fail us and is a great tool that should be listened to, because it's developed through our experiences and it's not something out of this world, but rather the work of our brain... it's still worth asking the user, worth discussing, before we implement something, before we spend money on something.

Ilona: And another problem this exercise addresses is a certain impasse. When we discuss internally for weeks without even arriving at a list of key functionalities.

On the one hand, we could all discuss it as a team for a month and get nowhere, or after four weeks, we could have answers from users.

Types of buy-a-feature

Radek: As I mentioned earlier, the buy-a-feature mechanic is very versatile. You can create various research scenarios based on this mechanic, and the exercise itself can take different forms.

This can be done online, for example, by using Miro boards, with short descriptions, photos, and iconography. You can also prepare tools and meet with the team or a user offline.

An excellent tool is Monopoly money, which you can hold, test, and divide into piles. You can also use printed cards that feature photographs illustrating roughly what a given functionality is. It's just a matter of choosing what best suits the specific challenge and research goal.

However, as I briefly mentioned, we can conduct this research both individually and in groups. And that also depends on the specific product, because sometimes more than one person is involved in a purchasing decision...

We had a situation where we were researching the consumer profile of a high school student, specifically a freshman. And these individuals, when making a purchasing decision, do so together with their parents.

And here, for example, we had to conduct research in dyads to check the decision-making dynamics. Because on one hand, the child has a need and wants to buy, while the parent is the sponsor fulfilling that need.

So, observing the energy between a parent and child in this case is very important. Let me remind you that the marketing and sales angle then emerges. And then, we'll use the same arguments that a child uses to convince their parent to make a purchase, to persuade our customers in marketing communications.

So these are truly very valuable qualitative insights that can be gained, and we highly recommend this exercise on many levels.

Summary

Ilona: To sum up what we've discussed today...

Clients often come to us with a problem of too many functionalities, unsure which ones should be implemented next.

We, UX designers, can help them using the buy a feature method, which we discussed in today's episode. This method can help with prioritizing items on a roadmap. It can also help us gather information about our users and, for example, about a UX persona. It can assist us when we don't yet have a product on the market, to define it better and give it some structure.

Radek: If you'd like us to conduct such an exercise at your company or with your users, please contact us via our website www.designzima.com.

We can discuss your challenge. Whether you even need it. What form it might take. And we can, for example, arrange a session.

Also, feel free to contact us!So, feel free to contact us!

Thank you very much for listening to this episode. I hope to see you again soon... well, hear you again soon, that is... though I might even get to see some of you in person.Thank you very much for listening to this episode, and I hope to see you again soon… or rather, hear from you… although I might even see some of you.

Ilona:
Ilona: Thank you for listening to this episode, and we'll talk again in the next one.
‍Thank you for listening to this episode, and we'll catch you in the next one.
‍

Radek: Radek: Talk to you later, bye.Talk to you later, bye.

‍

Enjoyed this episode?Did you like this episode?

‍