My first attempt at putting my Product Design knowledge into Practice -Week 6 (Part 1)
I’ve learnt so much over the past couple of weeks and finally got to put my knowledge into practice. Worked on my first product design project for a duration of 2 weeks and it was a really exciting experience. I think my presentation was quite good. I mean, it was a lot better than the the first one I had in week 2. The feedback my teammate and I got were very constructive. And so it wasn’t the kind of criticism the left us feeling like we were dumb and had done a horrible job. It was the kind you get after you’ve put in a lot of work and done a good job that would have been better if you weren’t just a beginner. We decided that we would revisit the project, make corrections and improve upon it.
Here are a few things I learnt while working on the project and from the feedback gotten after the presentation;
1. Interviews- Asking the wrong questions
For our primary research, we decided to conduct interviews to really understand our users. The mistake we made however, was asking the wrong questions. Remember what I mentioned in one of my articles about asking the wrong questions? You can check that here. Well, I guess it’s easier said than done because we made that mistake. And quite frankly, it’s very easy to get carried away asking the wrong questions if you’re not a 100% clear on the actual problem your research is based upon. Each question asked during an Interview should be relevant enough to take you a step closer to understanding why your user is facing that problem. The kind of questions we asked weren’t specific enough. They were too abstract and didn’t really help our cause. The data you gather from your research, interviews in this case, is literally what determines what your product would likely be. But when you ask the wrong interview questions and design a product based on the data gotten from that interview, you end up with a product that’s not useful to anyone.
2. Your design Case study is not a dissertation
Your design case study outlines the problem, shows your solution and explains your approach right from the beginning (problem) to the end (Design). You don’t want people feeling overwhelmed at the sight of your presentation slides because they think they’re about to read a very long essay. This means make your words as few as possible. Also, you don’t have to explain in detail every single step you took to arrive at your solution, a mistake my teammate and I made. We included everything possible in our slides, thinking that was the best way to show our thought process in detail. Your case study isn’t for you, you did the work and know what’s in it anyway. It’s primarily for other stakeholders in that project. So it has to be easy on the eyes and simple to understand. It needs to tell a story from start to finish. Humans love stories, that’s the only to get them fixated on your case study. If you get the chance to present it yourself, you can now go into further details while speaking.
3. Focus on Humanity not Demographics
Just for context, our project was to create a solution for a problem a particular gender faces. During our research, we didn’t know at the time that we spent so much time investigating the problems from a wholistic gender perspective rather than being more specific and trying to understand the humanity of the people. This influenced the wrong questions we asked. Study the why, the how, the what, the when, the where… per person not per category. There’s more to people than the issues faced by their gender, race, culture, and other factors they’ve been categorized into by the society. Their individuality means they have their own personal concerns that may not have been accounted for and you may never know or understand those issues if try to study your users as a group instead of individuals.
4. Your Research result and Design must be directly connected.
After carrying out your research, your findings must inform any artifacts, which will in turn influence your design. It’s so important that there be a reason for every design decision and requirement you create. Those reasons don’t just come out of thin air. The results gotten from your research have to be the major reason why you make any design decision. For example, the Information Architecture of your site map shouldn’t be based on instincts. There needs to be a reason why you choose to organize your content in a certain manner. At the end of it all, when someone takes a look at your case study, they should be able to detect the link between your research, artifacts and design.
5. Team work makes the dream work
Product design entails so much that its impossible to do it alone. You need to collaborate with people who are equally as devoted as you so you can get more work done faster and more accurately. You also need people to brainstorm with, so you see things from other perspectives and you get to learn and grow. We went from being about 5 to just 2 on my team and I was mad initially because it meant more work on my plate. But a few days into the project, I realized it wasn’t as bad as I thought it would be because we both put in the work and communicated effectively. We both respectfully dissected each other’s Ideas and I’m glad it worked out. This is a subtle shout out to my amazing teammate 🎉 Chinwe Uzegbu
That’s all folks! Thanks for reading and I hope you learnt a thing or two.