All you can see is some white space, some seems-to-be-accidental information about a few events and an advert. After some time, on the really bottom of the page, you found a button ‘Go to the Shop.’ You think it is worth to try.

You want to get this ticket! So you click. And then it is another white space. You see nothing. But when you click randomly, other pages open. You are confused. You feel helpless…

Now imagine, that is not a broken website or a one-time situation. A lot of the web pages work like that when people with disabilities try to use them.

The Users

In theory, the Internet is for everybody. The practice shows that not necessarily users are equal. A lot of people are excluded just because companies didn’t think about them as users worth focusing on. 

When it comes to thinking about accessible software, everyone pictures users that are blind or deaf. But they are not the only ones. The person can be physically impaired, for example, after some accident that can happen to anyone. It also includes people with color blindness or vision problems (like myopia) or cognitive difficulties. Or even foreigners that do not know the language very well. 

It is worth to notice that a lot of impaired people do not think about themselves as ‘special users.’ Sometimes it is just a temporary problem, like a broken leg, or sickness. It can also be something permanent, but the person is so used to his or her limitation that does not perceive it as something to make a lot of fuss about.

Small problems with vision, for example, when problems occur only in the bright surrounding, or during dawn, or when letters are just a little too small. Or even captions are needed when the user wants to watch a video but cannot do it with the sound on (it happens to me all the time!).

These are just examples of people and their issues, but also people in different situations that occur to millions every day.

Think about digital accessibility as the equivalent of wheelchair ramps for sidewalks. We all understand that the person in a wheelchair should be able to navigate efficiently. But we also realize that improvements for wheelchairs brought value for other people. Like mothers pushing a baby in a pram. A person with a suitcase. Even a delivery man with a lot of boxes in a trolley.

Another example could be automated doors. When a company uses them, it is a vast improvement for people with disabilities. But also, doors like that can save money. As they open when it is needed, companies can save energy used for heating. Plus, they work touchless. No fingerprints on the doors mean less cleaning. In coronavirus time, it is also a very hygienic way to get into the building.

There are tons of examples. I mentioned those just to show that the design improvements help people in wheelchairs or with other disabilities. But at the same time, other users benefit from that.

The Numbers

Today, one billion people globally live with some form of disability, and disability prevalence is higher for developing countries (data by GADIM, 2020).

Think about that. One billion people around the world with disabilities. Do they have considerable spending power? If yes, then why companies just ignore that?

This is the situation now. And it will not improve. Our society is getting old. We are getting old. It is quite impressive, but it also comes with a cost. More and more users will have problems with vision, hearing, motor, or even cognition. Companies should start to get ready for that. Accessibility rules address all of the issues. Including it within a project and introducing it to the product will benefit everyone in the future.

The Brand

Excluding users by brands is counter logical.  While many businesses fight for even 1 percent of the possible market, it sounds not wise to ignore 15-20% of the population who have a disability.  

The person who has a positive experience with a website will likely tell others, who again tell others, and so on.  If a person with a disability were able to buy a product online quickly, she or he will tell others in their disability groups, family members, friends, work colleagues. Imagine that. It sounds like a good idea to calculate the possible increase of business that could be achieved simply by making the company accessible in the online world. Add to that PR and marketing effect, and it is even more significant.

Those should be significant motivators for brands to be more accessible for all users.

The Project

When accessible features are inbuilt into your website, like alt text for images and captions for video, it optimizes your Search Engine. SEO increases the number of visitors to the site by obtaining a high ranking placement in the search results page of a search engine like Google. Captions also can be useful for users, that want to watch the company’s video content without a sound.

It all seems like worth doing. But how to introduce the accessibility topic to the project you manage? Here are a few steps:

1. Provide information

Share the information within your organization. As mentioned in this article, you can provide a lot of data: how many users have a disability of what kind. You can specify that the limitations of users vary; based on that, steps to improve digital products could be different. You can highlight the possible impact of your company’s business and PR (if applicable). You can even prepare a short business case, show numbers, and calculate the effect. It is up to you!

2. Show the user story

Build awareness of stories of users. Use short but universal stories that will reflect with listeners’ lives. Describe it with details; the best choose ones that could be associated with your company’s business.  You can use examples from that article, just to highlight the problems you want to address. Encourage empathy.

3. Do the research

Check digital products you are in charge of. If they are online, conduct research using web tools or with real users. If the project is in progress, check mockups or designs – then you can introduce improvements before developers start to code.

The probability that you will find users within your own company is quite vast. If so, ask politely if they would like to participate – not to stigma their limitations, but to highlight the importance of this work – for others. Together you can help other people in everyday life.

4. Engage

Accessible User Experience (UX) and Inclusive Design are new approaches, trying to ensure that the product is accessible to as many different users as possible. You can ask your UX Designer and Graphic Designers if they are familiar with those topics. If not, find some materials or courses, also encourage them to dive deeper by asking for empathy. Especially UX Designers should participate, as there is a lot of work that could be done by them at the very early stage of the project.

Ask also developers if they are familiar with modern accessibility standards. Nowadays, there is a lot of tips and tricks for programmers. Giants like Microsoft, Apple, and Google have prepared libraries and software just to help code better – in terms of accessibility. It is quite fresh, so there is a probability that you will surprise some of your IT colleagues! 

5. Make it common

Start to include accessibility topics in your and your’s team every day’s work. Even small tasks, small improvements count. When you start to do even little steps toward better accessibility, other teams also can feel encouraged to do so. 

6. Spread the word

Having all of that, having improved outcomes of your projects, let others know about that. Spread the word. Ask your marketing department if your company could publish a case study. Show the impact of your work, encourage others to make some changes. It is a win-win situation, both to you and your company, as well as to people with disabilities. 

To wrap up, one billion users with different forms of disabilities have problems with surfing on the Internet. Websites are excluding them by not providing correctly developed websites, and having that in mind could benefit the company you work for. 

As a project manager, you can change the world for the better. That is the truth, and you should know it 🙂 Good luck!

The post Is Your Project Management Strategy Accessibility Friendly? appeared first on PM Column.

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

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

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
• SEO
• 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 

The post How Wireframing & Prototyping Can Help Product Managers Find Balance appeared first on PM Column.