What happens when you design under a strict NDA with no access to the real end-users, but you still want to implement a participatory approach?
Well, you use proxy users!
Well, you use proxy users!
This project was made in (reluctant) collaboration with a company which shall not be named due to NDA-restrictions.
We had no access to anyone within the company, and therefore used what can be called tertiary proxy users to still be able to perform participatory workshops.
We had no access to anyone within the company, and therefore used what can be called tertiary proxy users to still be able to perform participatory workshops.
I cannot go into details about the results of our process, and frankly I'm not that proud of the result either. However, I will show some parts of the process in which we used proxy users and in which I learned a lot about how to aprroach participatory design.
The use of proxies instead of real users of course sparks a lot of issues, limitations and discussions about what is participatory or not.
If you think this is as interesting as I do, you're very welcome to read this essay I wrote about our process, where I try to define the different types of proxy users, and discuss their limitations and benefits:
If you think this is as interesting as I do, you're very welcome to read this essay I wrote about our process, where I try to define the different types of proxy users, and discuss their limitations and benefits:
Participatory design approaches with proxy users
As you can see above, we used a lot of different methods and tools throughout this process. However, I will focus on two of them here: workshop facilitation and Wizard of Oz testing.
Workshop facilitation
In the beginning of our process, we had proxy users work with collages to express their definition on a specific topic (which I cannot describe further). The participants worked in pairs, where they had to guide each other through the collage process, and their interaction with each other was also an important part of the workshop.
The final collages were used as a kind of "evidence" of how people define this specific topic, and of how complex it could be to describe.
The final collages were used as a kind of "evidence" of how people define this specific topic, and of how complex it could be to describe.
We gained a lot of surprising insights, especially through observing the interactions between the participants, which really highlighed how important participatory approaches can be to a project - even when it's with proxy users!
Wizard of Oz testing
Toward the end of our process, we wanted to test out certain touchpoints, both to see if they worked individually, and if they fitted into a bigger user journey we had created. The touchpoints were part of an app system - however we choose to make low fidelity mock-ups of the touchpoints and print them out to test, since this was a first test and we did not want to spend time and energy on a fully working figma prototype.
To simulate interaction, we therefore used the Wizard of Oz testing method, where one of us would act as the computer for the participants. So when they "clicked" on something on the prototype frames, we would give them a new frame to simulate human-computer-interaction.
To simulate interaction, we therefore used the Wizard of Oz testing method, where one of us would act as the computer for the participants. So when they "clicked" on something on the prototype frames, we would give them a new frame to simulate human-computer-interaction.
In this way, we were able to perform a quick and easy testing, which highlighted a lot of minor errors and misunderstandings in the design - probably the same we would have found with a digital prototype.
Moreover, the participants had never tried this kind of testing before. Because the design didn't look as "polished" as it looks like in most digital prototypes, we managed to pass some of those barriers users normally have when testing digital systems such as apps, and they therefore seemed even more open to suggesting design and usability changes.
Moreover, the participants had never tried this kind of testing before. Because the design didn't look as "polished" as it looks like in most digital prototypes, we managed to pass some of those barriers users normally have when testing digital systems such as apps, and they therefore seemed even more open to suggesting design and usability changes.
This type of prototype testing was very beneficial for the project, and something I would like to try again!
