Some time ago, I finished my first Product Review report for a client, who is developing a platform for purchasing videos, photos and texts from journalists from all around the world. The essence of a Product Review is the analysis of all the data and metrics collected throughout the development process, as well as a qualitative usability analysis. Thanks to such approach, we are able to find missing features in the client’s app, analyze the client’s outstanding needs and estimate the app’s overall potential. In this article, I will share some tips on how to get through a Product Review process successfully and write reports like a pro.
Product Review is one of the services provided by Netguru. As a result of a comprehensive analysis of the app, the client gets a report where we outline all outstanding issues and suggest solutions. In the course of a two-week-long product review process, I learned a lot about the importance of communication, time management as well as the workings of the reviewing process as a whole. There were things that I could have done better and there were certain things I will have to keep in mind next time. Below I listed the most important of them:
It is crucial for a successful PRV to work with the actual product and have unlimited access to every single bit of data. However, sometimes you will have to wait for some of it. Don't wait idly – stay productive. Manage your process in a way that allows achieving the best possible results and work on parts of the system you have access to. Use the waiting time to analyze a different aspect of the product, for example, the usability.
Don't assume that clients will be perfectly prepared for a product review either. They will fail to deliver you the things you request and they will forget you were waiting for them unless you ask many times. In our case, the client promised they would give us access to Google Analytics ASAP. It was on Monday, but we waited for this until late Friday (yeah! only five days). We sent reminders about it in every e-mail and Slack message. Yes, we were a pain in the arse – but sometimes you have to! If we weren’t working on something else in the meantime, we would be wasting our client’s time and money.
Okay, I know – we designers have our superpowers: we see every aspect of a poor UI and UX at a glance and we can describe it with fancy words that are perfectly understandable for other Product Designers. This doesn’t necessarily mean that the average user or client will understand the jargon.
You must not force the client to decode your words, the same way you must not make a user think about using the interface you designed. So keep it simple: reduce the number of technical phrases and acronyms to the absolute minimum. Additionally, when describing issues use sample user stories. It'll make everything easier to understand.
Nothing is set in stone in the World Wide Web, and every website evolves too. Content is constantly changing, features are added and pages are growing. In your review, focus on parts of the product that are accessible to its users at the moment. In our case, we knew that the development team was working behind the scenes to add some new features, but their work couldn’t become part of the report because it wasn’t just ready yet.
Yes, you can write some suggestions about the staging views, but keep in mind that they are still work in progress and will probably be changed many times before they go public, so don't spend too much time on them.
Don't assume that a client should only get very general information about the issues you found, even if they know that the product should be completely changed. Show them each element that has to be modified or replaced and provide a rational solution to the problem.
The "redesign everything" or "start from scratch" comment might not be enough. Not only it doesn’t provide any actual solution to the problem, but it also gives the impression that as a reviewer you did not take your task seriously, or worse – you lack imagination.
Remember: noting every detail, analyzing various aspects and providing valuable ideas assures the client that they need help and you're the right person to help them.
Analytic tools are awesome. Still, they aren’t that smart, and sometimes they measure wrong things in wrong places. In our case, some of the key processes took place beyond the website, so the measured data was unreliable. There were a lot of drop-offs, but most of them were caused by the structure of the platform itself, so we couldn't take it seriously.
If you can do it and know how to use them, you can add some "smarter" tools that allow tracking the user journeys and analyze funnels (I mean Hotjar, Crazyegg, etc.). They do need some time to give results, so you have to ask for them before the review.
Okay, sometimes it's easy to jot a few words down in your native language, but you will have to translate it into the report's language eventually, so you’ll be wasting your time.
It is really worth taking the extra time and effort to write down your remarks and solutions in full immediately, instead of just jotting down a few keywords. After a week or so, you'll come across your vague note and will probably have to look at the page again and rethink the issue one more time. All in all, writing accurate, comprehensive notes from the very beginning saves you tremendous amounts of time and makes the remarks you make much more coherent.
Taking notes is one thing, but in the end, you will have to give the client a professional report. Give your team members time to review your work and provide feedback. Set aside the last two days before the deadline (or more – it's just an example) for polishing your report.
Think about the time estimation for the future cooperation with the client (Next steps & Recommendations section) while writing your review. This way, you won’t have to think about it at the last minute. You can also write down your estimations for each issue so at the end you can sum them up in the report.
When you analyze an app, you see a lot of parts that could be changed or improved and you have many ideas on how to do it – that's great! Not every issue should have the same priority, and a good practice is to categorize the app's problems and solutions to these problems according to their severity.
Some of them will be really important and should be dealt with first. That said, most problems will belong to the categories "we should change it..." and "it will be nice to change it...".
After you have thoroughly studied the product, pinpointed each and every issue and provided the right solutions, you have one last task to do: you need give the client your recommendations for the future cooperation. And I mean recommendations (plural) because you should prepare more than one.
If you give your client one big plan, they can tell you that they can't afford it.
Remember how you’ve just broken down the problems into categories based on their severity? Now you know what should be done first, so you can prepare a basic plan based on this.
Subsequently, you can create more advanced roadmaps, including issues from the less severe categories. You can also present a long-term plan with a road map where you will show the client how to take advantage of the whole potential their product has.
Be flexible and prepare more options to avoid a "no". Leave some space for negotiation.
Writing up the report is one part of the job, the other is to present it. This is the moment when you have to show what you have been doing this entire time and present everything that you have found. Bear in mind that you are only supposed to summarize the report. Do not just read it out in full in front of your client. Decide on what you will say during the meeting, highlight the most important parts of the report and think about what client should read on their own (the report is a huge document, so it's impossible to squeeze everything into one meeting).
Prepare an agenda – it will prevent you and the client from wandering off the topic. Provided that you have the time, don't hesitate to practice your presentation before the final meeting with the client. Ask your Project Manager or another Product Designer for a quick rehearsal and present the report to them. They have a lot of experience and will help you improve the delivery of your presentation. You should also prepare to participate in a discussion after the presentation, in case the client has some questions or wants to clarify information they obtained.
I hope you found my article useful and that all your future product reviews will be a piece of cake.