Here at Codebots, we strongly believe in helping each company find their own Way of Working. From the battle hardened trenches of product design, we’ve come up with a few ‘activities’ you can do you ensure you don’t make the same mistakes we made early on. These are based on the Design Thinking Mindset, that you can read more about in our blog How can I use Design Thinking to scope products? But first, let me set the scene…
It’s a lazy Tuesday in the office and you’ve just finished treating yourself to a meal from the fancy burger shop up the road. A far cry from the one you and your team normally frequent. No, this one had hashbrowns on it! Just as you are starting to regret your decision to have a heavy lunch, one of your account managers comes over and tells you about a brand new project a client has come in for.
Brilliant! As your stomach churns, they tell you about this wild new idea they have. You don’t think it sounds particularly ground-breaking, just a simple update to their current system. Nevertheless, you head to the meeting the next day with the account manager, eager to get started.
As the client begins to explain all their problems, you start to get a better idea of their situation. Ideas form in your mind, and as soon as the meeting is over, it is time to get to work! Over the next few days or so, you’re whiteboarding and reading through all the documentation they client has provided.
Your team is happy with the result, and you all start designing up what you are going to build. The client seems to love the direction of your solution, and is eager to see it in action. A few weeks later, the first release is ready to go out to the users, and you all wait with bated breath for their response. A few days later, the client call you up, angrily listing all the complaints they have received from their users on the new system. “How could they not like it?”, you think to yourself, as the gut-wrenching realisation that you missed the mark completely hits you.
If you’ve ever found yourself in this situation, I can empathise with you! It was one I found myself in early in my career as a product designer. Coming into a field of web design, where the most important thing was how nice everything looked and if users could find the buttons on a page, it was quite a shock to the system to be in position where those were the things way down the list of things to consider.
As the User Experience (UX) role was still coming into existence outside of the most cutting edge of companies, it was here that I learnt the most important lesson about building products:
Listen to your users!
That project we worked on that missed the mark so completely could have been different if we had gone and listened to the users, and put them at the centre of what we were building. We have since learnt our lessons, and we’ve identified five activities you should always consider when scoping a project:
1. Discovery interviews
One of the most important tasks you can do while starting out a new project, whether it be a whole new business idea of a modernisation of an old one, is actually sit down and talking with those who are going to be using it. Ground breaking, I know! Even in this day and age, I still regularly have to convince clients and development teams how important it is to just listen to the users.
I’ve been in my share of meetings where a client comes in and demands we do it exactly their way because a family friend told them it looked good. While they may be telling the truth, your family friend isn’t the one buying your product. Another issue is when development teams declare that they can substitute themselves as users because ‘they are users of software.’ Once again true, but those team still aren’t the ones who are going to be buying the product.
By shifting your mindset and hearing from your target users - all those people who aren’t financially or emotionally invested in a product - we get valuable data that we can use to support the users, not your mates down at the pub.
This one simple step at the start of a project helps clear away so much of the fog-of-war that teams face, providing clear patterns and evidence on what to build for. There is an article Activity: Discovery Interviews with more in-depth details on the importance and how to conduct interviews. Here are some of the key takeaways:
- Discovery interviews help you better define your target market and users and can also help you find that niche that your product belongs to.
- Talking with your users can help uncover hidden things about how they view and interact with your business. Customer support normally deals with your users when things go wrong and have great insight into how to make it better from that angle. But the real hidden gems are with the things that people like that they might not be telling you.
- You don’t have to do exactly what your users are saying. Its one fear many people have when they are faced with talking to the users. You are looking for patterns in what they are all saying and using that to find a solution that works for your business practice and model as well as what underlying issue the users have.
2. Defining the problem
Many a project and product can be derailed early on by not aligning the entire team to the central problem you’re all trying to solve. When the stakeholders are thinking one thing, the development is thinking something else and the users are thinking in a completely different direction, you’re never going to be able to build anything that works.
One of the earliest activities you can do is get your team along with the key stakeholders and define what the problem is you are all trying to solve. Design Thinking has you do this after speaking with your users, at Codebots we do it before and redefine after interviews. Do whatever way makes more sense for your Way of Working. Just do it early! I’ve written an article with more depth of Defining the problem and the different types they come in. Here are some key points to consider:
- Make sure ALL of the team is present in the meeting and a facilitator is present to keep you all on track. I’ve seen more than one project come to a grinding halt because one key stakeholder didn’t feel the need to be there, and when they finally caught up, they had wildly different ideas and hit the panic button.
- The team should work together to come up with the problem statement, but at the end of the day, the decision maker makes the final call. Whether it be the project manager or CEO, that person should be 100% happy with what the team will be building.
- The problem statement may change during the early stages of a project, that’s fine! It means you’re honing in on something that is going to be great. Doing research and talking to users will reveal more things to consider and that might get you to pivot in a different direction. Embrace it. The goal of a project is to build something that solves a problem. If what you first come up with isn’t actually worth solving, then don’t double down on it.
- The problem is more important than the solution! This is the big one. So many projects come undone because the team focuses in on the solution someone came up with very early on. That solution is rarely if ever truly solving the problem and is just an idea. Refocusing the team to care about the problem and solving that over making the solution leads to all sorts of wonderful results. When you tackle it from a problem space you start off with something like this: “How can we get people excited to use mobile banking?” Something like this opens up the door to many wonderful and creative ways to solve this problem. Compare this to a solution like “Gamify our mobile banking app so people deposit more money.” There is only one possible path here and it is making a huge assumption that it is going to work.
3. Brainstorming
While brainstorming is nothing new to most people, the way in which you do it may be. It is one of the most key activity sessions you can run while building a project as it is where truly creative and ingenious ideas are formed. What I learnt from Design Thinking and Jake Knapp’s Sprint book is how to run these sessions to maximise idea generation and squash stubbornness (results may vary.)
One of the best things about brainstorming is getting the entire team together to come up as many ideas as possible. And by whole team, I mean the WHOLE team. So many projects wind up being a couple of designers locked away in the backrooms going mad with power. A great project involves everyone, from those who are going to be building it, right up to the business owner who is investing in the product. I’ve written an article on how to brainstorm that you can read Brainstorming ideas. These are some key points:
- Get the whole team to be involved and block out the hours needed for this activity. Having everyone on the same page coming up with ideas creates a positive direction for the product and gets everyone invested in it. When those who normally don’t contribute to building products have a hand in coming up with the ideas,they suddenly get very interested in making sure it works.
- Focus on that problem you’ve come up with. Here is where all sorts of left field ideas for solutions spring up that may be even better than what someone thought up at 2pm after a burger lunch. It also helps unleash those people who sometimes cling onto the first idea that pops into their head. Seeing so many other ideas on the wall gets them to rethink and come ideating.
4. Rapid prototyping
This is one of the activities that I see done the least and normally done wrong by those who do it. It also one of the best and fastest ways to validate that the product you are trying to build is even going to be worth the time and investment to develop out. When people hear ‘prototype’ many people jump to ‘MVP’ which in turns jumps to ‘thing we are going to show our users.’ Then they quickly retreat back into their shell and demand that anything made and shown to users is 100% the best thing possible. Next thing you know it is months down the track and you just spent all that time making a dud.
The goal of rapid prototyping is to make something quick and dirty that either gets your idea, intent or concept across to users to see if they like it, test out if a piece of functionality is even possible or to try out a business workflow to see if people think it is worthwhile. Your users will understand if it doesn’t look well designed and sparkly. Just spend as little time as possible to test out the idea you have, and either adjust or start again with another idea if it failed.
I’ve written an article on what rapid prototyping is Rapid prototyping These are some key points:
- It is always better to fail fast and hard at the start of a project when minimal time and money has been invested. It is ok for your team to make a dud from an idea that turned out to really only work on paper. Now you know and can focus on another idea that has legs.
- Many people (including myself) tend to get bogged down in the details, designing the perfect flow, making sure the functionality accounts for every single edge case. That is all well in good during development or implementation. Here you want to just get the idea across to those you want to test with. You’re trying to validate you have solved your problem with this. If your users are able to overcome their problem with your hacked together prototype that is being held together with masking tape, then your final product should be amazing!
5. User testing
As I said before, the best way to build products is by listening to your users. That’s why two of these five recommended activities are focused around just that. User testing is similar to discovery interviews in that your team is going out and learning more about those people outside your bubble. The difference is that this time you’re coming with a possible solution for them to try out.
Now you can watch them use your prototype to try and solve their problem. Did it work? Did they like it? How can we make this better? All questions that come out of these sessions and can quickly let you know if you’re onto a winning idea or if you need to go back to brainstorming. Maybe you’re just a little bit off and just need to change a few things. Either way you can get those valuable learnings to help guide the direction of the product. We’ve written an article on how to conduct user testing User Testing Here are some key points:
- Testing early helps reduce the fog-of-war of product development and ensures your team is on the right track. There is no worse feeling than building something and only testing it when it is live in and in front of users. At that point, your whole job is about fixing things, instead of working to add more features. Plus, you’ve just wasted time and money working on something that could have been identified as wrong months ago.
- Do it more than once and keep testing your ideas and prototypes on your users. Do it often and you’ll keep positioning yourselves in the best possible path to victory. When the sailors set to sea to find new lands, they didn’t consult their compass at the start and end of the voyage, they did it all the time!
Conclusion
These five activities are just part of a larger series we’ve collected to help you craft products that put the user at the heart. It is important to remember that it is not how many or which ones you choose to do, you always need to keep testing it with people. It will ultimately result in far fewer projects that run off the rails and help keep everyone involved happy.
If you’d like to learn more about our Activity kit, where you can learn various methods to help start off a successful project, have a read of our ‘What is the Activity kit’ article.
Written by Jordi Kitto
Software Developer
Jordi developed this very site you’re on right now! And when he’s not working on this site, he is showing off his latest Apple products to everyone in the office, or working on his side hustle
