What are your alternatives to written documentation in software projects? Katarzyna Malecka, an experienced UX designer and product manager, reveals best practices for combining the two roles and describes her process of using wireframes, prototypes, and tests in product development to stop burning daylight on documentation.
Product managers can leverage wireframes and prototypes to keep business executives, teams, and clients on the same page.
Imagine the situation. Once upon a time, after many meetings, you’ve finally gathered requirements from stakeholders and checked all the constraints and possibilities with the development team. Everything looks great since you know that the knowledge is there, ready to be implemented. The last thing to do is to put everything on paper.
So you start to work on that. And give up after the 43rd page of documentation, when you realize that you have been describing how to register and log in. You’ve gone too far with the descriptions. Writing down those simple (as you thought) functionalities took you so many lines of text that no developer would ever want to read them.
This kind of problem is quite common. Written documentation can consume a lot of time – both during the preparation phase of the project and continuing with every little update shortly after that. Just a tiny change requires a million small fixes on your masterpiece. It’s a nightmare.
But what if you didn’t have to write anything down? Think about replacing the text with drawings. Here you are! It is one of the best ideas from the UX phase that spread onto other project management phases.
The Application of Wireframing and Prototyping to Product Management
Why are wireframing and prototyping extremely helpful in replacing paper documentation in software projects? It’s quite simple. You can “picture” most of the requirements instead of using thousands of words. Another important thing is that to prepare and build an interactive prototype, you neither need development nor a single line of code written. Let me introduce you to the most common approaches to wireframing and prototyping.
Lo-fi wireframes are used at the beginning of the project. They can show the very basic concept of the software. Ideally, you focus on crucial functionalities and present the simplest version of the customer journey. It can look almost like sketches of the software. Kind of a ‘raw’ approach, but on that phase, this is what you need the most.
Discussion over lo-fi wireframes improves understanding of what should be done within the team of designers, developers or testers. It also helps stakeholders understand the final shape of the product. Not everyone, though, will realize that it is not the final version of the software and the discussion may take you a bit longer than expected.
The good news is that any changes in that step are not costly. It takes time, but at the end of the day, wireframing can be a real money saver. Using lo-fi wireframes prevents you from a misunderstanding of the requirements (which usually happens when the product is described in 100-page documentation).
Hi-fi mockups present the final concept of the software. Mockups are based on final designs and show all the features and functionalities. They cover not only basic customer journey but also edge cases. Mockups show the final version of the software (still: not the one that is finished), but on the stage when changes are still inexpensive. Sometimes this method is avoided because it requires more work and effort put into it.
The Static Prototype
The static prototype is prepared with the use of wireframes or mockups. It’s a very simple way to present the whole customer journey, step by step, without coding. You just put all of the wireframes or mockups in the right flow and present it to the team or stakeholders, or even end users during tests. The static prototype helps to understand the path user will have to follow while using the software.
The Interactive Prototype
The interactive prototype can be prepared the same way as the static one above. It is, similarly, a brilliant way to present the customer journey. When interactions are added the prototype acts just like real software. The better prepared the interactions, the closer it is to the final product.
The above – lo-fi wireframes, hi-fi mockups, the static and interactive prototypes – are able to remove most of the text documentation, but they won’t replace it completely. Prototypes can hardly show non-functional requirements such as:
- data security
- site performance and speed
- conversion analysis
But remember, functional requirements are possible to be shown without only text documentation. Thanks to that approach it is easier to manage the software production process. Looking at even the simplest wireframe is a good way to visualize the final product in mind. When some questions occur, you can rethink requirements and change what should be changed before even one line of code is written.
The Case for Using Wireframing & Prototyping in Product Management
While working on the mobile application for taxi drivers, I understood that even the best description of the new feature our business owners wanted to implement was not good enough.
Developers asked questions: where to put the new button, where to insert the new copy. How should an error or a confirmation of success look like – all of these from the end user’s perspective.
The requirements I gathered from business leaders had a different approach. They asked why we should prepare the new functionality and how it will improve our service – in general. Not how it should work from the customer’s perspective – in details.
It was the time for me to change my approach and use simple wireframes to visualize business requirements in a way developers would know how to implement. I prepared two iterations of wireframes: the first was in line with business goals.
When I had it done, I gathered the owners of the ideas in one room for one hour. I showed them the wireframes since I wanted to make sure if I understood their vision well. It occurred to me that there were two simple changes needed – one in the texts and another with the shape of a button. I fixed wireframes during the meeting and then we all agreed that this was it – this is the new functionality we want to have in our mobile app.
These wireframes were the only documentation I then had to give to the developers, and they understood what needs to be done at a glance.
This example leads us to another great thing that you can take from the UX phase and use it during the whole project – tests.
How to Prepare Tests
It is a common mistake when the software is not tested with the end users before the release. Many times I observe project managers who tend to postpone receiving feedback from the end users. The reason is not so bizarre – the fear that the product will not attract the customer’s attention is understandable. Negative feedback can happen and then it is not an easy situation from a project management perspective. Bad welcome from potential customers at the very beginning of the project could close the project at all.
The case here is that negative feedback will always be likely to happen. But if the tests are properly conducted, you can use them to improve the product. The best way to hear a piece of bad news is to hear them as soon as possible and at the very beginning of the project.
How to prepare a great user test, then? That is when you take a look at the UX techniques of user research.
1. Test the software using the prototype
At the very beginning it is better to use lo-fi prototype – just to test the idea and main functionalities. Users won’t judge the design or how it works exactly. But they can give you feedback regarding the most basic stuff like:
- Is this software self-explanatory?
- Do users understand the purpose of it?
- Do they know how to use it basically?
- What do they do not understand?
- What are the suggestions?
Having answers to the above questions you can rethink the requirements, discuss some changes with stakeholders and improve the product at this stage. It is cheaper to hear all of these opinions just after the release of the software.
2. Test with real users, not with your coworkers
Only the real user, that is not biased by working in this branch of business can provide constructive feedback. This is the way to gather real opinions that are more likely to be opinions of future customers.
3. Do not take it personally
Try to listen calmly to what people have to say. It is precisely their feedback that will lead you to a better product at the end. It might be hard but it will be very useful and you will definitely appreciate it a few hours after you hear all the issues which appeared during tests with users.
Be aware that people taking part in tests are trying to do their best at finding errors! They may feel that they are in this particular situation only to find what is wrong with the project, so they may not even say what they like. It is good to ask them about it too! And remember: do not take it personally, try to not get angry or upset. It is just a test of the product, not a test of your skills.
The Case for Using Tests in Product Management
The example I’ve mentioned before about how I managed to replace the paper documentation with wireframes was a great one. Now it is time to explain why it was also a good choice to test these wireframes with end users – taxi drivers.
It wasn’t an easy decision to test the business idea (that was also well understood by the development team) with real customers. The risk was that users of our app wouldn’t like the change we planned to do. And then what? We were obliged to do it no matter whether customers liked it or not (that is the truth). Still, I tried.
I prepared a simple, static prototype with the wireframes I had. I asked customers (not workers) for their opinion. The result of that was very interesting; it was not clearly negative nor positive. It was a completely different approach. Drivers reacted to the planned change in a neutral way. But they commented that if we implement this function in a way we are planning to, they would not use it. Why? Because… the buttons are in the wrong place from their perspective. They will not be able to reach them during the ride – as it can be unsafe when they are on the road. They proposed to move them below. I did it.
For the business and development team, it was a minor tweak – the core idea has not changed. The UX has changed. Without the test with the users, we would not have known this and the whole project would be a fiasco as our target group wouldn’t use it. Not because it was a bad idea, but because they just couldn’t reach the buttons they needed.
To wrap up, I really enjoy combining the two roles – to be responsible for the UX phase and project management. Understanding three different perspectives – business, development, and end users’ – gives me more confidence. It also helps me during discussions, as I understand that the expectations within these three groups are different and it is my role to manage them all.
Illustration: Copyright © Oksana Drachkovska.
|Title||How Wireframing & Prototyping Can Help Product Managers Find Balance|