Automated transcript
Introduction
**Juneza:** Hello, it's really nice to see the audience and everyone so excited to hear about the entire topic on prototyping.
**Daniele:** The stage is yours and I'm excited to learn from you.
Talk: Case Study prototyping in the Agrotech sector in Indonesia
**Juneza:** Awesome. Thank you so much. Hey guys, I'm Juneza, as Daniel gave me, gave the most beautiful introduction that anyone's given me. But I want to give you a little bit more context about myself. So I am an architect by degree, an installation artist by passion, and a service designer by choice.
But when I was given this topic of prototyping, I started thinking that, okay, across these different design domains, a skill or a tool that I have consistently used is the skill of prototyping. As an architect, I have essentially built small spaces in order to communicate that specific space or a structure to a client or a stakeholder, or even to get a peer a colleague's feedback on the space that we're designing.
As an installation artist, I have used prototyping as a tool for essentially experimenting and learning about the spaces, learning about how people are interacting with the specific installation or the art piece that we have developed. And as a service designer, apart from using prototyping as only a communication tool or an exploration tool, we have also leveraged prototyping as a tool for testing out a hypothesis.
or refining an existing touchpoint. But what is interesting is that, how do you prototype a service? You can't completely. That's the interesting bit, because unlike a product that you can test and refine and test very easily, with services, the tricky bit is that there are a concept of relationships and people interacting in a service, right?
And relationships take time to develop. And essentially prototyping a service means prototyping these relationships as well. So how do we do that? That's the tricky bit that a lot of the service designers we've been trying to figure out and navigate around. I also wanted to discuss how do you decide When to prototype, right?
Prototyping is not the first step towards testing out a specific idea or a hypothesis that we have. But when we know the amount of time that we have, the budget that we have in hand, the scale with which we are testing out this particular hypothesis, we could decide between a sacrificial concept, experiments, or prototyping before we move into a pilot stage.
These are the few questions that I had while I was deciding what should I be sharing with you guys because these are fundamental questions for us to think about when we decide to prototype or when we decide to use this particular skill or a tool. So today I want to actually share a case study.
This is me. This is I work in this agri tech sector where we work with Indonesian farmers and we are designing services around them. And I wanted to share a prototype that we built for recruiting field agents. So basically the field agents, what they do is they are the intermediary between the business and our customers who are the farmers.
So the whole process of recruitment had two phases, which was awareness phase where the field agents were introduced to what the company does and what our vision is and what our mission is. And we had an activation stage where they were given access to our tools so that they could essentially start their work with our customers.
But there was a lot of pain points along that recruitment journey that we identified, which essentially led to a lot of drop offs and many of the field agents not being activated. So we had proposed different touch points to be introduced. In this particular process of recruitment, in order to increase the activation rate, what I mean by activation is that the field agents essentially pick up this particular tool and help us in facilitating the communication between the business and the farmer.
And also we wanted to reduce the time that we took in order to get them aware about what our business is and get them to activate. So while we were discussing whether this is the right approach or if this is the right process to improve our recruitment structure across different stakeholders, we decided to prototype this particular concept and test it out on a real scenario.
So these were the different touch points that we had essentially built. We had the canvassing phase where someone from the field marketing team was Looking for a free getting them to see if they're the right person that we should be recruiting. We had a value prop communication touchpoint as well as we had a pitch touchpoint.
Apart from that, we also introduced a screening touchpoint, which is more streamlined because in the older process, it was more biased towards the field marketers picking a field agent to join the system, but we wanted to essentially ensure that it is standardized. We also had a verification process that we introduced, which was a bit more standardised.
And we also had an onboarding or a training touchpoint that we had introduced. So there were six, six to eight touchpoints that we had further introduced in order to ensure that the recruitment process was smooth. We were identifying the right candidates and the candidates also understood what was the system of the service that they were getting into.
But when this is a very high fidelity prototype and it was tested in a real life environment, but today based on the prototype, I wanted to share five suggestions or five learnings that I've had. The first suggestion that I wanted to make was before we jump into prototyping a new service, make the current service visible before we prototype or before we suggest a change in that service.
Because oftentimes the key mistakes we make as service designers is that we assume every stakeholder has visibility of all the moving parts and all the moving levers. It's direct and indirect impact on the system. So how we did this in this process is this is where we leveraged mid journey to build all the touch points that were not tangible.
These were the relationships that we wanted to highlight as well. major touch point in that service model. So through Bitjourney, we were able to showcase this particular touch point where the field marketer is speaking with a potential candidate, having a chat with them, introducing them to the business and what we are doing.
We were able to essentially communicate to the stakeholder the touchpoint of a backstage process. This is one of the CX teams speaking to a potential candidate in order to review if their documents were right. So what this helped us communicate is that all these non tangible touchpoints became more visible, became a topic of conversation, and it helped different stakeholders from different teams to discuss how this was impacting.
Their work or the different work that they were essentially introducing into this particular recruitment process. And of course, the tangible touch points, which are much easy for us to speak about, showcase, or talk about in order to improve. This is definitely, you don't need an AI to build this tool.
We already have our systems in order to showcase our tangible touch points. So this is how we've been leveraging storytelling to make a lot of non tangible touch points tangible and helping the stakeholder having a conversation around it. Now the key question is, why is it important to make all the service touchpoints visible?
This leads me to my suggestion, the second suggestion that I have is, we have to build a prototype team. As a young service designer, I always thought when I'm prototyping, I'm the main person who is Figuring this entire thing out, I have to build out the prototype and test it out on my own. But with experience, I've learned that building a prototype team is extremely crucial.
Because it's not about the success or failure of the prototype, but imagine in a roadmap, post prototyping, how does this service proposal or the change that you're proposing gets included in the business roadmap. Who will pick this up post a prototyping stage in order to develop it or to include that in their product roadmap or their operations roadmap?
So this is where it becomes extremely important to build a prototyping team and run this entire prototype with one representative from different teams who would be indirectly or directly impacted by this particular service. Suggestion three that I have was to try and take a Wizard of Oz approach. I remember having a conversation with one of the research members in my team and she had given me a heads up, Geneza, don't over engineer this.
Let's keep it simple. That made me remember the Wizard of Oz approach that is usually adopted in usability testing, where there is a human operator sitting behind the curtain or the screen and the customer who is essentially interacting with the screen would feel like they're interacting with maybe a chatbot or an AI, but it's actually a human behind the screen.
So how this particular was leveraged is, if you look at this particular recruitment process, you can see the bottom the white bit that I have, where I have included certain tools. So we have Flutter Flow, we have Google Sheet, we have certain people from different teams who are representing at different touch points.
So basically as a service designer, what I was doing is we didn't have all of these things developed or integrated. Okay. I was literally sitting behind the screen copying data from an existing app like Flutter Flow, adding it onto Google Sheet, pushing the function into another system like Airtable or any other platforms in order to integrate it on the backend so that For the customers who are experiencing the service on the front stage, it still feels smooth, but on the back stage, it's extremely hands on.
It's mostly people who are trying to make the front stage feel smooth while we are Testing of this high fidelity prototype. Because in certain cases like this, we tend to get caught up in developing the entire system so that we can prototype to the T, but it makes it difficult for us to iterate and change if in case we want to change any of these particular touch points.
Hence one of the Thanks a little bit. you Biggest suggestions that I have is take softwares off the shelf that you can essentially bring together or with little manual effort, you can essentially stitch the backstage processes so that we can test out if the particular proposal is working on ground. So this takes me to suggestion four.
This is one of the most important suggestions, which is be clear on the metrics that the prototype is contributing to, as well as the contribution of the metric to the overall outcome. Why the suggestion is very important is because there are so many touch points that we're stitching together and trying to make it work.
We could get lost in this entire service ecosystem. Having a clear metric, a clear goal is extremely valuable. In the recruitment process, our metric was essentially to increase activation rates and also to decrease the amount of time it took for the field agents to be onboarded into our system. And we were working towards those two goals.
There were other gaps that had come up regarding, oh, this particular screener doesn't work, or, oh, this particular website doesn't work. We knew our focus was on these two metrics and we stuck to the metrics so that it was easier for us to continue testing it and prototyping it. And this brings me to the final suggestion that I have is Communicating the results of the prototype.
As service designer, executing the prototype itself could be extremely time consuming and extremely energy consuming, that once you have tested the prototype, you should not give up on the communication bit. And why that's important is because communicating in a format that your audience understands is key.
So I have often found myself, once the recruitment prototype was completed, that. I had a different presentation deck if I was speaking with the business team because what mattered to them was the data and how that was impacting this particular recruitment process versus when I was speaking with the design team or marketing team, it was more of the experience, the interactions.
So I realized that the communication structure and the format. Varied based on the stakeholder that we were addressing so that they could see the value in what the prototype was adding to the new process or change in the touchpoint that we were offering. So this is a small case study I wanted to share, and these a few suggestions I wanted.
Wanted to share with you all to answer any questions or anything that you want to discuss around these topics.
**Daniele:** Thank you so much Juniza. You are a master of synthesis. I know that this project might have taken Days, weeks, months, and you were able to package it in five learnings and in such a short time. Well done on that.
Q&A: How to recruit a prototype team?
**Daniele:** To get started, I have a question for you. Which is you're saying it's important to have a prototype team. And I'm asking you myself, how do you recruit such a team in an organization? What's your way of doing it?
Because I know politics is not always easy, especially in big organizations. How do you do that?
**Juneza:** It's a very controversial topic. So when we are prototyping, at least. My experience working across an MNC and multiple startups has been that, if the stakeholders don't see the value of prototyping, I see it more as a pitch, where the service designers are essentially helping the stakeholders understand that, okay, if we essentially take this particular approach, we can arrive at this learning much faster at a smaller time and a smaller budget.
But if we want to learn fast, we need the right people to work with us. In order to test out this particular prototype. So what I have personally been doing is I essentially speak with individual teams, individual stakeholders. And try to understand where the concerns are and where the inhibitions are with this particular proposal.
If they're very excited and they see value in it, it has been easier for them to either lend a person who is in a specific region or they're part of the team to work with us for a specific time. Because one of the things that we should be aware of as service designers is that We are impacting KPIs of other team members as well.
So if I'm recruiting a field agent, a field marketer, or somebody from the field team in order to test out the prototype with me, what we should be aware of is that in those two weeks, The KPIs that they are supposed to be hitting their targets will get impacted. So we have to be able to speak with the stakeholders, get their buy-in, and ensure that they are aware that there are certain members from the team who is helping us with this.
So that has been something that I have been very empathetic towards and being very aware of, so that whenever you're recruiting people always ensure that the managers or other people above them are aware. And we also don't impact their KRAs and KPIs and or try and get the KRAs and KPIs changed for that specific quarter or a period.
So that's a conversation, a discussion that I generally have with decision makers. and try to get people recruited in the prototyping team. And also I would like to add that there is this D'Arcy format where initially I always thought as a prototyping tool that service designer is the decision maker but over time I've realized and I've learned that it's best to take a responsible or an accountable role in the D'Arcy and keep the decision makers as the main stakeholders because Then you have a lot more support system in order to build a prototyping team and test it out.
Those are the two things that you can essentially keep in mind or leverage when you're building the prototyping team and navigating stakeholder requirement and the hierarchy in organizations.
**Daniele:** The question of how much time you're going to steal my guy, that's a very important question for a boss.
It's okay, I'm happy to lend him to him. Sometimes, people use that kind of language, yes, we can lend you that talent or that resource. But let's remember, it's a human, you don't have so much power on it, but, but in organizations, there is still this thinking, so we have to interact with that and being able to say, yes, it's going to be one week, it's going to be so many hours and it means that The OKRs, the KPI that this person has, you shouldn't be measuring them as exactly as you would because this person isn't working 100%.
Yeah, definitely. And usually, I'm, again, I'm curious:
How to convince a leader to give time for prototyping?
**Daniele:** when you are with with a team leader, with a key decision maker, and he says, you no, that's too much time, can't do that I can't lend you my team for that. How do you react? What's your counter pitch? How do you work with that?
**Juneza:** So when I get a reaction from a particular stakeholder that this particular process need not be prototyped, that, so I essentially try to understand that. If this particular change in the service or addition of this touchpoint is that of a high priority for the stakeholder or if it's a very low priority for the stakeholder.
Because if it is of high priority, it's much easier to get a buy in, but if it's not a part of their roadmap or not of a priority for that specific team, then it can get a bit tricky to get that particular person's time. Essentially what I What my strategy has always been to understand that why is it not important for you and how can we make it?
Should we even make these changes in the particular prototype or service? Because at the end of the day, this change that we're trying to make or the touch point that we're introducing or defining the pain point is directly or indirectly impacting that particular team's KPI or KRA and that's going to improve their performance.
So if that's not a high priority for them at the moment, then it's And there are chances that we would also say that this is not the right time to test out this particular service change or introduction of a specific touchpoint. So that's essentially the way I handle it because at the end of the day, as service designers, we are essentially in the back end, we're in the backstage.
Most of the impact on the service would impact specific teams. And we should be very aware of it when we propose new service models or propose
So that's how I would be more empathetic towards why they feel this is not the right time to get their particular employee in the space. So in the AgriTech space as well, I can give you more context. We have the concept, the timing and seasons are very important. If I decide to prototype at a season which is very peak season for our harvest, it's going to impact a lot of the business KPIs.
I have to be more mindful when am I testing, is this the right time to test, and is this the right time to recruit a prototyping team. Finding that right time when the teams are more available, the stakeholder sees, Value in this particular prototype is key to essentially get more buy in and get a more collaborative effort from across different stakeholders.
So that's just been my observation.
**Daniele:** Timing question is a good one. Looking at when is the low part of the job, because usually jobs are like a heartbeat, and looking when is the downbeat and being able to say, that's usually a downbeat. So why not do it then?
It's like an interesting way to, to sell it. And And what you're thinking, what you're sharing with me also resonates with the thing that I've been doing lately, which is, when someone says, Oh no this is not something that we can do. So just giving them back that statement, but in a more kind of a business way Oh, so for you, it's not important that we make progress on this KPI.
And what you do when you do that, strangely enough, people then say no, Daniele. This is super important because this and this and this and this and this and this and they give you all the arguments. For you to then say, ah, okay. So for you, it's when, if this is important, so maybe we can change that so that it serves your personal goals.
And then they say, absolutely, let's do it. Why didn't we do it before? I was like, okay, cool. So instead of selling it, say underselling it, say, oh, you don't want to do that. It's a pain in the ass for you. It's too complicated. It might be, might not be the right time. And suddenly they take it back and say no, I have power.
I want this. This is important. It's a strange human thing when you take out the gift of someone, they suddenly want it back. Yeah, it's also like
**Juneza:** putting a mirror, essentially putting a mirror in front of them. I think that's a visual way to Use that as a tool. Put the mirror in front of the stakeholder.
How to prototype pricing?
**Daniele:** I'm going to transition to a question from Emmanuel Fragnier. So just for context for you, if you don't know Manu, we all call him Manu. Manu is the head of a service design program in the south of Switzerland at a bachelor level. And so he is asking Juneza in the prototyping phase, what do you think about integrating also a pricing discovery process?
Is pricing something that you prototype?
**Juneza:** So I can give you a bit of a recent practice that we're doing where we're trying to figure out if a specific service or a new service that we want to introduce into the market is something that our customers would find value in.
If you go and ask your customers, is this a service that you value? They might say yes, they might say no, but you don't know whether they are actually valuing it, right? And these customers, when we say customers, they have certain tie ups with the business and they are essentially purchasing certain products or in products from us, from the company.
So we have certain targets that we want to essentially help these customers hit. So the way we. So the way we figured out if this particular product is of value for this customer is what we did is we asked them out of these services, which ones would you find first find value once they pick the service, what we essentially asked the next question was that this is a particular target that you have to achieve in order to unlock the service.
We added an actionable touch point in order to test out if the value or the value of that particular service is seen as something that is important and the customer would be ready to pay for it or conduct some particular task for it, et cetera. So that's how we have tested out a certain new service introduction in the market.
Does it make sense or if it does not make sense for our customers. So that's one way we tested that bit out. Does that answer the question?
Examples of how to prototype and test pricing
**Daniele:** Yes, absolutely. And may I ask, what's a kind of a specific example, if you're allowed to share, because I know we are all under heavy NDAs and stuff. So from what you're allowed to share do you have a kind of a, an example of an action or for a task?
That can help to see oh, there are more going into that pricing than this pricing.
**Juneza:** So this was a test that was conducted by our research team. So we don't prototype for figuring out. What kind of pricing works? We use this particular concept of sacrificial concepts. So what the research team had essentially conducted is they had built posters of these services that we're potentially offering and it looked like they're going to be inaugurated in the next few months and these services are going to be available for the customers.
So that's how we had built the posters and engagement material. And we. Brought in few customers and we went to their space and essentially understood. which service would they would want to avail, and if that particular pricing worked for them. So you have, in the digital space, we have the subscription model, the monthly model, etc.
Similarly, we had conducted a sacrificial concept testing across the different service proposals and the pricings that we had attached to it, and understood from the customer why a certain price worked for a certain for them to access certain service, and why certain pricing did not. So this was more of a open research test that we did in order to understand what was valuable for them.
So this was not on a prototyping concept. This is more from a sacrificial concept testing that we had done. Or you could even call it a low fidelity prototype structure that we adopted in order to get quick feedback and ground reality in order to figure out which would be a better suited service for our customers.
**Daniele:** I love that name. I had never heard it formulated that way. Sacrificial Concept Testing. It's a, that's a new one for me. And I love the term sacrificial, that there is a sacrifice going on where you have to make a choice between A, B, C, and D. And the choice is not, I want this.
But rather, which one am I ready to kill which is a much difficult, more difficult conversation and which gets you more into thinking, okay, I can't have this. So that's a very interesting way to to do prototyping.
How do you find your target group?
**Daniele:** I see we have another question from Rita, which I'm going to share with us, which is how do you find your target group?
**Juneza:** Yeah, it's a very difficult question. So I'll have to give some context or some back. Let's take this particular scenario where it's a company and we already have a set of customers and you're introducing a new product, right?
If you're introducing a new product or service, what's There is a specific persona that you're building this particular service for. Now, from those persona that let's say the strategy team or the branding team has identified, you have certain attributes that are measurable. It could be it could be their age, or it could be a demographic metric, or it could be a behavioral certain decision making metrics as well, but in the case of customers that we have worked with, I've essentially, we had the sizes of stores the sizes of the farming land or the kind of crops that they work in as the screening points.
But apart from that, when you are essentially identifying those target groups, it's a very, I would say it's more of a creative approach that you should take. I remember there was a product that we wanted to introduce, which was an electric bike for Gen Z customers. So we had essentially gone to colleges and schools in order to find our customer base.
And then we sat with them and we essentially did our entire testing with them. But when you're working in a farming industry, or an agriculture space, you will have certain thresholds that you have to use in order to identify those target groups and those target customers. So it's pretty well defined in in sector that I'm working in, but if it's a new service or a product that you're introducing, you will have to look at creative ways to identify those customers.
I hope I answered your question.
**Daniele:** Yeah, absolutely. It's, I love the fact when people share, that there is no secret formula, but that it's a lot of trial and error and, just I think when peers share that, it's like this moment of, ah, okay, I'm not doing it wrong, but it's like the, That's great.
Yes it's there is some science, but there is still a lot of craft and a lot of trial and error that goes in all of that all of that stuff. And I'm very curious because we had previous conversations, which people are not maybe aware of, where we spoke about the values and the dangers of KPI and your last suggestion.
That you shared really resonated with me.
What's a good KPI for a prototype?
**Daniele:** Could you maybe share with us examples of what's a good or a positive KPI when it comes to prototyping? Maybe a practical example because I think, when we prototype, sometimes we just want to test, but then we forget what's, what we test for. And if you could share a bit of your thinking about, you The danger and the value of KPIs in prototypes and how to work with them, that will be, I think, extremely valuable.
**Juneza:** Okay, that's a very valuable question. That's a very interesting question to ask because when, in the case of prototyping, you should ensure that The metric that you are planning to test out or improve is something that is not very large. Like it's not a, let's say an increase in businesses volume or the sales of that business.
These are big metrics that you can't essentially contribute to through a specific touchpoint or service. So you should be very clear that. What is the metric that you're identifying? And it should be very easy to measure. One of the main things that I have understood over time is that the metric that you're identifying should be behavioral metrics, especially when we say outcomes, these are changes in the behavior that we are trying to essentially test.
So in the case of the recruitment prototype that I shared with you guys, the, one of the key metrics that we were testing is Is the field agent willing to share their documents through this particular system that we had created? Because initially we saw a lot of resistance and from them sharing certain documents because it was being shared through WhatsApp and it wasn't very regulated, but we wanted to test out if there was willingness for them to share and how fast or how delayed was these are just the documents being shared with us so that we could process it and onboard them.
These should be metrics that are more behavioral changes. It's something that we can essentially test out and keep iterating upon, versus if it's larger goals like Increasing the sales or the business value of that particular operation or the particular service that or business that you're part of, that is something not very easy for a service designer to essentially commit to.
So I would always suggest that be careful of the metric that you're identifying and ensure it's more of a behavioral metric that you're associating the measurement to, so you can constantly keep working on it and improving it. So that and a suggestion that I have is do read the book Outcomes Over Outputs that's been super valuable.
It was introduced to us by our design head and that has been a very interesting book for us to identify which metric that we should identify, we should essentially work towards because usually everyone's excited on the outputs. What I mean by outputs is what we're delivering and what we say it's done.
Just completing a prototype is not success, but either we should have learned that this particular system or service that we're introducing is either working or not working, that is more of a successful prototype. Because generally when we set up the prototype, we're so overwhelmed with this entire system being worked, bringing stakeholders together, collaborating with them, that itself takes up quite a bit of our energy and, It gets us excited that we were able to complete it, but when you go back and measure it and test it, you should be able to clearly articulate what it has been able to impact and what that learning has been, or if this particular proposal that you have made has not been able to derive an impact.
That's also okay, but you should be able to articulate it. That's why I had the fifth suggestion that communication is also very important of your learnings from that prototype. Often I've seen service designers. Just letting go of that last part of that puzzle and essentially setting it up, implementing it and forgetting about the communication bit of it.
**Daniele:** Awesome.
What are good frameworks for prototyping?
**Daniele:** I know that you're working on a future book around, so it's not, it's quite a secret, but not such a secret about the topic of prototyping. And I know from our past conversations that You've been really looking at different frameworks also when it comes to prototype, could you maybe highlight one or two frameworks that you've, that for you changed the way you think about prototyping?
**Juneza:** So right now there is, so I've been working with, or not working, I would say I've been doing my desk research and study for this particular book on prototyping. And there's a lot of work. that has been done for the past 10 11 years on the frameworks of prototyping. So very recently I had a conversation with the author of that book.
He's also a PhD holder and he's been testing on these prototyping frameworks for quite some years. And I asked him this question that, Is there a right framework to prototype? And he said, unfortunately there isn't because Every vertical, every business has their own way of has their own challenges and you have to keep iterating based on what kind of business space you're in or vertical you are in.
But when he was doing his research, there were less service designers for him to test out the certain frameworks that he had developed. I haven't tested a few of those frameworks. I've read more of the theory of it, but to put it into practice, there is, we are assuming that we have a lot more stakeholder buy in order to test out that framework, but hence I haven't been able to pick up certain frameworks and test it out very easily.
But going forward there are talks on us testing out the frameworks that. He had developed in the past and refining them for the current way service designers work. So yeah, that's the work that we're working towards. I, so right now I wouldn't say there is a right framework at the moment.
Hopefully in the future, we're able to figure out maybe a good framework or a starting point for service designers to get easy buy ins from stakeholders and easy way to essentially establish those prototypes. So it's a work in progress. So right now I wouldn't. Say there is the right framework as such.
It's totally dependent on service designer to service designer and vertical to vertical. Because if you talk to a healthcare, a service designer working in a healthcare space, the way they would approach prototyping would be quite different from us working in an agri tech space or someone working in a B2C space.
Yeah, that's it. That's where we are at right now.
**Daniele:** I love your answer because it's perfect for a Swiss culture, swiss people, when you ask them a question, the usual answer is, it depends, because, it's never yes or no, it's, yeah, it depends on a lot of things, we're neutral, so it also feels in a good way.
in the way we respond. And I think that's also a good reminder, that there is again, no secret formula. There are guidance, there are elements that can help but still it depends. And I think that's a good reminder also for people. What I'd love to share with the community here is that if you're interested into this kind of stuff for, I know that you're someone who's very willing to share.
So just send a message to Tunisia via LinkedIn and and and maybe you'll get to discover in the future. A, more of her learnings on that particular team. I think that's something that, that is, that will be lovely. I think also for her to get to meet other people who are doing these, who are having these challenges and you can also benefit from her learnings.
What's the most important skill for Service Design?
**Daniele:** I have another question, which is a very personal one, which is what's, what are things Maybe in the last two years where, you've learned where you say to yourself, Oh fuck, I wish I knew that before. We all go with age, through phases where we suddenly unlock something in our way of working, in our way of thinking, where suddenly we say, wow, for years I was working like that.
I thought it worked, but now that I have changed that. A new world of possibility comes so what's maybe one or two elements where you had like this unlock thing, both on prototyping, but also on service design in general because with age comes wisdom so I'm quite interested to know what's the wisdom that happened lately in your life.
**Juneza:** That's a very interesting and reflective question. Something that I have learned over time is that as a younger me, I used to leverage quite a bit on frameworks and theories and models. But the more I get into the practice, I realize that You don't have to hold on to these frameworks. You can tweak them.
You can make those changes because what is more important is building good relationships with people that you're working with, especially your stakeholders and the ground teams that you're working with because In order to be a good service designer, for me, it's not about how good your understanding of frameworks and tools are, but it's about how good your relationships and your relationship with different teams, and your understanding and your ability to empathize with different teams is.
Because we don't belong into a specific, uh, team or a pod or a category. We are everywhere. So we have to ensure that. We are able to help others, work with others, collaborate with others, and we always find ourselves in between a lot of people. So we have to improve our communication skills, our people skills, and I think that's been something that I've learned over time, and that 80 percent of people.
My job is to essentially build my relationships with people and understand where they're coming from so that I could support them or help them in their in tweaking the service or a process or wherever that gap is. So that's a skill that I realized that it's more valuable. I can't sit inside a room in a small screen and work.
Alone, I have to be around the stakeholders and the people that I'm working with and with customers that I'm working with in order to essentially be a good service designer. So that's been a huge learning that I've had over time. And that's something that I'm constantly developing.
**Daniele:** We could make a t shirt: relationships are more important than frameworks.
That's something that we could sell in service design conferences, like where all the talk is usually about frameworks. But not so much talking about, making happen the, the relationship, the kind of management of the stakeholder, which basically is politics, lobbying understanding the power dynamics, which is not something that you learn in school, but which is something that you learn the hard way.
And and yeah, that's definitely that's An important thing.
Can introverts be great service designers?
**Daniele:** For people who are more on the introvert side of things. And you're telling them, yes, relationships is 80 percent of the job of a service designer. They might be like, oh shit, I don't want to get into that practice.
Do you have maybe a few tips and tricks to help them?
**Juneza:** I've been asked this question quite a bit. from students and people who want to transition into service design that, Oh, do I have to be an extrovert to be a service designer? I want to share with you guys that I am not an extrovert at all.
I've also been an introvert. I've been a person who's more comfortable around books and frameworks and models as a young, But in order to pick up people's skills, you don't have to be extroverted. The think of it more as a skill set. It's a hat that you're wearing and you are essentially like using those.
There are a lot of coaches. who help you in communication to understand how can you have that particular relationship with a person and have that conversation with a person. Once you start developing these skills, you'll start picking it up in time. But if you want to be a good service designer, think of this more as a soft skill and not as a personality trait.
So definitely work on developing your soft skills because yes, you can be an introvert, but In order to get more people to work with you, you have to be more of a collaborator and that's definitely a soft skill that you can develop over time and you don't have to limit yourself. So yeah.
**Daniele:** Yeah. And I'm a deep introvert myself and and it still works because I think we're doing the kind of same thing, with the hat where you say, this is now my job to be, I'm in my relational job and I'm going to do that.
It works, it's like you put a suit and now I'm in a professional mode and when you come home you take out the suit and you go in your pyjamas and you're in home mode. I think there is a bit of that going on and I would believe that introverts make maybe better service designers, but I'm biased.
Because Introverts usually have a better sense of empathy because they're very good listeners. So I think if people struggle by saying, I'm an introvert, I can't go into service design, but it sounds super interesting. I think the fact that you're an introvert is maybe a secret force, which comes with a few challenges.
Obviously there are new skills that you have to But but there is there is hope. There is hope. We have Two last questions, and I'm looking at the time because we are Swiss a Swiss organization, so time is something that we deeply appreciate and we want to be precise with short answers will be more than than perfect.
Which Indian market could benefit most from Service Design?
**Daniele:** Based on your insights, which industry within the Indian market will benefit most from service design? And what strategies do you suggest for effectively targeting these industries?
**Juneza:** So in the Indian domain so service design is still picking up and it's a skill set or a requirement that is getting slowly introduced. So if you look at the different verticals, I think service design is valuable across multiple domains that I wouldn't say service design is not valuable for X or Y domain.
It's mostly. And your ability to think in systemic or an ecosystem lens. So if there is a domain which is not a part of any ecosystems or systems, then I think service design can't contribute there. But most domains, we should be a valuable member in that specific team. And to answer your second question, how do you essentially pitch service design?
So my suggestion or my learning has been that it's best not to pitch service design as a domain, but I've also spoken, there are a lot of startups in India. There are quite a bit of startups in the city that I come from and I do spend some of my weekends working at a co working space and interacting with these startups who are building some amazing services for India and for the world.
And we sit together and I try to understand what kind of structure that they have, what is their process and what is the service model that they have been building for. And when we start adding value, asking the right questions and working with the teams, they automatically see the value of having a service design approach or a lens into the work that they're doing.
But in order to, if you go out and say that, Hey, I'm a service designer and this is the value I can add, I don't think that would be the right. format or the pitch for a company who is not very well versed with where a service designer's value add could be to hire you or to essentially involve you in their process.
Because if you say you're a marketing or HR, it's very clear what that role is. Service design is still very new in India. So you, I wouldn't suggest use the term, but essentially, Show the value, have the conversation, and then you can have a conversion.
Closing words
**Daniele:** Thank you so much, Juneeza. A big thank you to you. You're investing a lot of time in preparation for these events. We have been speaking about that for now weeks.
And so I know all the preparation that is happening backstage. So a big thank you to you because this is again, all volunteer work. So it means even more. That you're giving of your precious time for the community like this. Thank you again for your work, your passion, and for your inspiration.
**Juneza:** Thank you so much, Daniel. It was a lovely conversation.
**Daniele:** Thank you everyone. Have a lovely rest of the day. Cheers.
**Juneza:** Thank you.
This webinar transcript was generated automatically. Therefore, it will contain errors and funny sentences.
Share your thoughts
0 RepliesPlease login to comment