ReplyAll: My First Experience with Rapid Prototyping
Designing a mobile app to solve a specific business problem.
For this project, I designed a solution to solve my partner’s (the user) business problem. I had 3 days to interview my partner, sketch up some prototypes, and iterate our designs through feedback. On the fourth day, I pitched my user’s problem, solutions, and processes to the class.
In order to solve the problem, I needed to know what the problem was. I interviewed my user, Jeff. After a few minutes, I learned that he was running a one-man business, but had no time to handle incoming client requests while studying full-time at General Assembly. How was Jeff going to manage a full-time business and a full-time student life at the same time? This was a rather specific problem, so I probed further. I asked about the business itself, his clients, and what his responsibilities were to them.
- Business: Digital Piece of Mind
- Clients: Elderly
- Responsibilities: Assisting clients (the elderly) digitize their lives, whether it be designing a website, a book cover, or being unsure how to use social media.
All of these were important, but then I asked the most important question:
Jeff, suppose there was a way for you to be a full-time student and run your business. Do you think that you can handle doing both at the same time?
A resounding no. So the problem changed. It went from, “I want to go to school and work at the same time,” to “I want my clients to understand why I can’t address their problems immediately, and I want to maintain their trust and loyalty.”
During the interview, I learned that Jeff’s clients contacts him directly via phone calls, SMS, and email. While Jeff is busy at school, he gets multiple incoming calls, emails, and texts from clients. Jeff didn’t have the time to reply to them until after his commute home (around 8PM). If Jeff had a way to reply to all his clients in a timely fashion, he could maintain their trust. This was my solution, now I just need to get there.
Research and analyses
Since Jeff is in the business of helping people, I thought I would look up software that customer service agents use. I came across a few:
Just looking at the features gave me some cool ideas. A good chunk of CS software made use of a unified inbox of sorts that aggregated phone calls, emails, social media replies, and live chat. Since Jeff gets contacted in 3 different ways, I thought up of an inbox that would aggregate his phone calls, texts, and emails in one place.
Next, I needed to figure out how Jeff can reply to them quickly. This was when I saw that one of the CS programs offered to save common replies. I needed something like that! But it wasn’t enough, because that would still mean that Jeff needs to write them initially and save them one-by-one.
I thought about how to automate this process and came up with an idea similar to Google’s Inbox app. Inbox reads and interprets an email message, then gives the user a few intelligently pre-generated responses to select from. Now that I had core features to work on, it was time to sketch.
First up was the storyboard. I did a quick mockup of a scenario in which my user would experience the problem.
After that came the interface. I worked on the unified inbox first, then the reply screen after that.
I decided to include a client profile view as well, since it would be helpful to have information about your client as a business person. The conversation history interface was added in case Jeff needs to refer back to any previous details from a client conversation.
Getting user feedback from others
I pitched my app idea at 5 individuals during a “speed dating” session. The feedback and practice I got during this was invaluable. Almost every interviewee told me the reply screen idea was great, but it was too cluttered. This made me revamp the interface design to use more negative space.
I also received idea proposals for cool features that would make the reply system more versatile. One user told me that I should implement a method to aggregate more than just voicemail, texts, and emails. Another wanted the profile screen to show client behaviors and more. Ultimately I didn’t include these features because they would detract from the core problem I was trying to solve.
While pitching my ideas, I learned that I was giving them much more detail than they needed to know. The final slide deck needed to be 5 minutes in length so there were obvious presentation skills that I needed to work on.
Verifying the solution
Finally I showed the design to Jeff and asked for his feedback. Jeff was extremely happy with the design, especially the less-cluttered reply interface. The positive feedback helped me verify the solution, so I proceeded to create the slide deck to pitch this project to be continued.
What went well?
- Sketching: Learning to put my ideas on paper and being able to visualize the solution was huge. It allowed me to look at things from a different angle.
- Solving the problem: I was able to identify the goal my user was trying to achieve and the obstacles in the way of that. It set me up in the direction that I should go.
- Presentation: Since I got to know Jeff, I was able to really empathize with him and his problem. This enabled me to tell the right story during the pitch.
What didn’t go so well?
- Researching: I had a hard time trying out any of the existing products because I didn’t run a business and they were all subscription based services. Jeff has a specific business problem and I had no idea what existing apps I could use to get inspiration from. And even when I did get inspiration, they were all desktop programs, and I wasn’t sure how I would use that in a mobile app.
- 5 minute presentations: I went over the time limit multiple times during the speed dating session. It was difficult, but I learned how to be concise before the final presentation!
What have I learned?
- Wants vs. Needs: I learned that what the user wants isn’t always the right solution. In my case, what the user wanted wasn’t even feasible! Jeff wanted to bite off more than he could chew, but in an ideal world he just can’t. There were also many minor feature requests that weren’t important in the grand scheme of things. I would refer to the Henry Ford quote here:
If I had asked people what they wanted, they would have said faster horses.
— Henry Ford
- Don’t be afraid of messing up: Failing can be a positive thing because I can learn from it.
Where can I improve?
- Competitive/comparative analyses: Put more thought into market analysis when pitching the solution. Many people were curious as to where I got my inspirations/feature ideas from. It’s also good to identify competitors and what features they offer/don’t offer.
- Sketches are temporary: I still need to be less hesitant when putting ideas on paper. I found myself thinking too much about messing up before I put my pen on the paper. As I stated above, it doesn’t matter if there are mistakes in my sketches because identifying them early is key.
- I need to take more pictures!
- Sketch out the rest. I only worked on the core solution. Some missing interfaces would include settings, and initial app setup.
- Do more user testing after adding these interfaces. Make sure that they don’t detract from the purpose of the app.
- Refine details, iterate designs, and produce more prototypes.