The Power of Prototyping in R Shiny: Saving Millions by Building the Right Tool - posit::conf(2023)
Presented by Maria Grycuk The development of software can be costly and time-consuming. If the end users are not involved in the process from the start the tool we built may not meet their needs. In this presentation, I will discuss how prototyping in Shiny can help you build the right tool and save you from spending millions of dollars on a tool no one will use. I will explore the advantages of using Shiny for prototyping, particularly its ability to rapidly build interactive applications. I will also discuss how to design effective prototypes, including techniques for gathering user feedback and using that feedback to refine your tool. I will emphasize the importance of presenting real-life data, particularly when building data-driven tools. Presented at Posit Conference, between Sept 19-20 2023, Learn more at posit.co/conference. -------------------------- Talk Track: Shiny user interfaces. Session Code: TALK-1125
image: thumbnail.jpg
Transcript#
This transcript was generated automatically and may contain errors.
Hello everyone, my name is Maria and today I will be talking about the Power of Prototyping.
Let me start with a short introduction. I am a Senior Delivery Manager at Epsilon, which in practice means that I am supporting our clients in creating new products or enhancing tools that already exist. I am working mostly with big corporations where we are creating internal tools for their teams.
One of the most important aspects of my job is to support our team to create successful tools. For me, a tool is successful if, first of all, it is being used. Because only if this first condition is met, we can talk about your product bringing value.
A cautionary tale
Today I will be talking mostly from my own personal experience. I would like to start with a short story. You can see a spoiler here, it won't be a success story.
It started as a typical project. There was a manager who had this great idea for a new tool that he wanted to introduce for his colleagues. He started development on his own. After a year, he realized that he would need some help from more experienced developers to fix a few bugs and also implement more complex features.
He decided to contact us. We started working together, but he was our only point of contact. He was the one deciding on the priorities. He was also validating our work. This is why we asked him a few times if it would be possible for us to talk with the users, mostly to understand the product better, but also maybe to suggest some improvements. But this manager was very hesitant about it.
He always repeated, not yet, let's finish this one additional functionality, or let's improve this one small feature. So we continued the development.
After an additional three months, we released the first version of the application. Only then we started talking with the users. We were able to meet with them to see how they are interacting with the application and also ask them a few questions.
As a result of those meetings, we prepared a report. Here you can see the result of this report. Nine out of ten people had problems with usability. In the end, they told us that they won't be using the application in the current state.
On the next slide, you can see a few more detailed comments, but they are quite similar. People were mentioning that the app is overcomplicated and it is very hard to use it without proper training.
After over a year of development altogether, we created something that people were not going to use. As you can guess, the project was closed and the app was never really on the production.
Of course, after a project like this, we started asking ourselves, what could we have done better? The first answer that we had is that we should probably talk with the users sooner. Of course, even before contacting us, this manager could have some talks with the users. He could just deploy the first version of the application and ask them to provide feedback, but maybe also we could be more pushy when asking for contact with the users.
The case for prototyping
That's why currently when I'm starting any project, this is the one phrase that I'm trying to follow and I'm trying to convince all of the clients to release as fast as possible.
To be able to do this, you need to start simple. For me, the best way to be able to release fast is to start with a prototype.
When I say prototype, I mean the first version of your application with only a few main functionality fully developed, but it is important here to focus on the default user path. Whenever you have your business case, just focus on the one main thing you want your users to be able to do in your application and then strip it out of everything else.
There are, of course, some things that can be mocked to just show to the users that it is possible to implement it, but it does not need to be fully functional. Because only then you can have something that you can show to your users in just a few weeks rather than a few months.
Why Shiny for prototyping
Now, some of you may ask me, what is this amazing tool that you are using to have prototype in just a few weeks? In our case, especially for data-driven applications, Shiny would be the tool that we are using.
There are probably many reasons that a lot of people from the Shiny team could share, but for us it is, first of all, the fact that you can prototype very fast. So, you don't need to have any web development knowledge. It is enough to know R and Shiny will take care of everything else for you.
The second point is that you have a lot of out-of-the-box packages like bslib that was just presented. And also there are even ready-to-use templates that you can download like on our apps and on our webpage you can find some of them. And then there can be your starting point.
Another point is that you can deploy very fast in Shiny. It is very easy to deploy your app, especially if you have Posit Connect and it's just one click of a button, but there are also alternatives there.
And the last point that, in my opinion, is underappreciated is the ease to show the real data. And, of course, on one side you have a lot of ready-to-use components that are allowing you to create an interactive application that your users can use to explore the data, but also we can pre-process the data directly in R. So, you don't need to have any additional tools and we all know that usually when we are starting our project the data is not perfect and it needs some cleanup or modifications.
Why real data matters in prototypes
And I would like to focus a bit more on this last point and tell you why I think that it is important to show the real data to the users when you are even just prototyping.
So, first of all, it allows the users to focus on the functionalities rather than discussing the data in accuracy. So, I've been in a situation that I had to present a prototype with only mock data and it still brought value, but we spent a lot of time discussing why this 15 is not 17. And even if I explained to the users that the data is mocked, then I had to explain myself where do I plan to take the data from. So, in the end they were just focusing on this one part.
Another point is that it is just easier to compare to the current process. So, whenever you are introducing a new tool in your organization you are probably trying to support or even replace a process that already exists, maybe this is just sending an Excel file to your manager. But then if you are showing the users the same data in both places, they can easily compare those two ways of doing the same task and give you a better feedback.
And the last point is that it allows to select the best way to present the data. So, we all know that if we would use some default sets like Iris, your data will look probably decent. But then when you are starting to use production data, it may differ a lot. So, one of the examples I have is that we created a big table in one of my projects with rows and cells colored based on some business logic. And it looked very well with the mocked data, we were very happy with it. But then when we started using the production data, the colors were all over the place, it was just not possible to read this and we had to completely redesign this feature.
Gathering user feedback
So, let's now assume that we were able to build a prototype, we are even able to show the real data. So, what is next?
So, next we need to start talking with the users. And today I will be talking about two ways of gathering user feedback that worked best in my project. So, I will start with user interviews and then I will go to user workshops.
So, when I say user interviews, I mean a set of one-on-one meetings between the users and the interviewer.
And here it is important, first of all, for the meetings to be really one-on-one because only then the user can fully focus on the application and also answer honestly for questions. So, if his manager is in the room, it will be a bit more difficult sometimes to do so.
The second point is that the user has to interact with the application. So, this is not us showcasing the app and just explaining new features, it is just sending a link to a user and asking them to perform some actions. And it is good to keep the instructions as simple as possible. So, for example, avoid saying something like, could you please go to the page three and just edit data in the row four. It is much better to focus on this business aspect. So, for example, asking something like, could you please modify the number of chamomile shampoos in the magazine in Chicago in November. Because then you can see how easy or difficult it is first for the user to find the information about this chamomile shampoo, but then also to modify it.
And another point is to limit explanations to minimum. And it may be challenging at first, especially if you see people struggling with the app, you want to help them. But it is crucial to just observe and learn from it.
And the last point here is to remember to give opportunities to provide open feedback. So, one thing that I'm always doing is I'm asking the users to speak aloud about the thinking process. Because then they can tell me not only what they are doing and why, but they are also sharing their expectations quite often. And this is a great source of information on how we can improve your application.
And also after this first part of the interview, so after the user stopped interacting with the application and performing those tasks, it is good to save some time to ask additional questions. And here the only rule is to just avoid suggesting the answer. So, I would avoid questions like, don't you think that this functionality is great or the most useful? It is much better to ask which of the functionalities is the most useful. Or even better, how often are you going to use different functionalities here?
User workshops
So, this was the first part about those one-on-one meetings, user interviews. And now I will go to the second part about user workshops, which is a set of meetings with a larger group of users, ideally five to seven, but I think ten is still manageable. And all those meetings, people are working with the application individually. They are then sharing their experience, which is later discussed, and some improvements are suggested.
And on those meetings, it is good to split into sessions focused on one functionality. Here you can see an example agenda from a workshop I did a few months back. I just replaced the functionality names with placeholders.
And you may be surprised that for each functionality, we have two hours dedicated. And it may seem a lot, especially that those are quite simple things, like editing the data or even filtering it. But it was really needed, mostly because a lot happens during these two hours.
So, first of all, there is some individual work. We are sending the link to the users, and we are asking them to, again, go through the app, to focus on this one particular functionality, to perform the tasks that they would normally do. And then I am also in the room answering questions, looking how they are interacting with the app. So, it is quite similar to what I described before. But then during this process, they have time to note down some feedback that is later discussed, prioritized, and then, again, discussed. So, you can imagine that if there is like 10 people in the room, probably the discussion can take some time.
And another point is to give an easy way to provide feedback. But you should also think about yourself here, to make it easy later for you to gather it and summarize it. What we usually do is, we are preparing for every separate functionality to be a board like this, with the things that people liked in a given functionality, they didn't like, the things that are missing and are obligatory, they have to have them to be able to use the app, and the things that are missing and can be implemented later somewhere in the future.
What I also started doing is that I also created another space called parking lot, that people can add some random thoughts that they had in mind, just to not interrupt during each session.
And the last point is to save some time to prioritize. So, after all of the sessions, it is good to have additional one to just take, you know, three to five cards from every board like this, put them, again, in one place, and prioritize them and discuss this prioritization. And this discussion is extremely important.
So, for example, I've been in a situation that, you know, after this exercise, I looked at the cards, and I saw that something that I thought is super important based on the conversations was somewhere at the bottom. So, I asked the users, why is this the case? And they told me that this is obvious, that it needs to be implemented. And it wasn't obvious for me. So, it would probably not be that obvious for the development team as well. That's why I think this time to talk about it is very important.
And usually the results of such workshops are just a report with a list of priorities and a short description about each priority, sometimes also if you can add some simple visuals that can help. And this report is later also very useful during the development. So, if you have reviews with the users, you can even go back to it. You can discuss it and show them that you are listening to them and trying to implement the improvements.
And I told you at the start that user workshops and user interviews work best in my projects. So, now I want to just defend it a bit. So, first of all, it allows for a detailed discussion, something that I mentioned, I think, a few times during this talk. But because of this, you can understand not only what people want you to do, but also why. And then you can suggest some alternatives. But also have a bigger picture and make sure that when you are designing a new feature, you are taking this into consideration. So, both in the architecture, but also in the UX design.
Another point is that you need only five to ten users, which I think is not a lot. One thing to remember here is that this group should be diverse. So, if you are building something that should work across departments, probably you should have people from different departments. The same from people from different regions.
A success story
And I would like to finish my talk with another story, this time a success story. And it started in the same way. So, there was this manager with this big, amazing idea for a new tool that he wanted to introduce in his organization. And he needed our help to develop it.
So, we learned from our experience. So, even before starting a project, we talked with him to be able to have some users involved in the process. But fortunately, he was very open for this. He not only was talking with the users a lot about the product, but also he was open for us to have those discussions. What is more, he agreed to start with a prototype.
So, just after three weeks, we already had something that we could present to the users and discuss with them. We decided to go with the user interviews because it was still when COVID was there. So, we had to do it online.
And the results of these interviews were not as horrible as the ones that I showed you before. But we learned that one of the main functionalities is not working in a way that people are expecting it to work. In the end, it wasn't a huge change from the UI perspective, but it was big enough change that we had to redesign the data architecture. So, imagine this happening five months into development. It would be a real big change that would influence a lot of features.
So, we continued the development. And after just additional five months, we were able to deploy the first version of the application. And the feedback was very positive. People were excited about it. Currently, the app is used by thousands of users. And we are still adding new features.
Currently, the app is used by thousands of users. And we are still adding new features.
So, to summarize my talk, if you want to build a new product and not go bankrupt, involve the end users early on, release fast, and don't forget about using the real data.
So, if you want to talk more, feel free to reach out to me on LinkedIn. I would be happy to discuss the projects that you are doing and also your challenges. And here, I also wanted to thank Posit for inviting me. And thank you all for joining here today.
Q&A
Thank you, Maria. We have time for one quick question, which sort of aims at the advice to release fast. Do you have any advice on how to balance doing that and making a good impression?
I think the best advice I would give is to just start with a group of users that you trust and you know that will be open to seeing a tool that is not perfect. Because in the end, it won't be. And it will be buggy. It won't work perfectly. It probably won't be the prettiest if you want to be asleep. So, you can always start with people that you trust and people that you know are open to seeing things that are not ideal.