Interaction between product manager and usability expert

The product manager plays a role throughout the product development or the projectexecution cycle. The product manager delivers requirements, discusses them with the feature teams, collaborated and provides clarifications during the design phrase and also plays a key role during the development and testing cycles - defining what the flow for the feature should be case there is a lack of clarity among the development team (and there will typically be some small part or element of the workflow or the screens or the UI that may not have been well detailed during the requirements or design process and needs the inputs of the product manager); in addition, most Product Managers I know would do extensive testing of the product, primarily of new features or features that were modified; and also spent time in the beta programs, discussing with the beta users about specific features or providing clarification or passing on the more severe defects.
The usability expert does not play that extensive a role throughout the cycle, but in the initial phases of the cycle, the inputs of the usability expert are critical. I remember a particular cycle in which we were doing a comprehensive redesign of the product, based on a summary of user issues and requests over the past few versions, and also because the product UI looked dates and needed to be modified to seem better and fresher (and those are somewhat nebulous concepts, but you would not believe how well these concepts sound when you pitch the idea to senior management). In such a case, the flow of ideas between the product manager and the usability expert was something that started way before the requirements phase; in fact these could start before the previous version was done and out of the gate.
The usability expert and the product manager have a set of inputs that help them as they start their process, and for larger products, the number of screens that they have could be considerable, so they do need to prioritize. These inputs would be -
- Complaints and suggestions by customers and on the user forums (especially if these get mentioned a lot),
- Inputs from the usability expert and the product manager themselves (if you show product screens to a usability expert, you can be sure that they will have their opinions on the workflow plus and minuses of certain screens, and the product manager typically has a list of peeves about some screens in the product),
- Technical changes that require a modification to an existing screen or make an improvement possible. It is possible that the components used for screen design have gone through certain changes, which in turn ensures that the screen needs modification or maybe there was a certain workflow that was desired but was not technologically possible, but is possible now
- And there could be some other inputs that also lead to screen or UI modifications
The process is somewhat cyclical, with the expert typically laying down a new desired workflow, which would be commented on by the Product manager and sometimes by the product team, and based on these discussions, a new iteration would be made. Because this may need to be done over many UI screens or workflows, the creative mind of a usability expert may do this screen by screen, rather than working over several screens at the same time, thus ensuring that different product teams can get started. This is where the Product Manager can prod and work with the usability expert, atleast being able to detail out preliminary requirements that can be fully detailed out by the usability expert. It can be a challenge for the Project Manager to handle this kind of scheduling, but cooperation with the Product Manager can help make this smoother.

Presentation - who should do the presentations ...

In previous posts, I have talked about the kind of data, graphs and slides one should use in a presentation, especially when the presentation is being made to people who are in a more senior position. One has to be careful about what to present, presenting a top level summary and not doing an overkill with data, and yet having backup data and graphs for the queries that might come (it always comes off well if you have data on your tips, or have access to the data on your finger tips and goes a long way in generating a more positive impression).
The next important question is about who should do the presentation. And for a question such as this, there is no correct answer. It really depends on a number of circumstances, depends on the members of the team, and so on. Here are some points to ponder over:
- Importance of the presentation: Sometimes the presentation is really significant; for example when a new project is being launched and the kickoff means that senior executives would be present. In such a case, one really needs to have the best foot forward, and there is no question of trying out different members of the team in order to get them more presentation experience. If you were going to kick-start a project and the meeting was a review meeting, the presenter needs to be the best person for the job. On the contrary, if this is a regular meeting (many such meetings can be standard meetings where not much changes are expected but are a part of the regular schedule), one can try to get different team members to present either the whole stuff or break it up into different parts done by different team members. There is no real problem in even starting out by the meeting by introducing the team members and explaining the people who would be doing the presentation.
- Inclination: In every team, there will be people who are interested in doing such presentations because it gets them noticed and known by people outside the team especially if they come across as confident and knowledgeable. On the opposite side, there will be people in the team who are really not interested in doing presentations, and this is not something that one can force somebody into.
- Specific ability: Sometimes there is the need to fit a specific ability to the need of the situation. There could be a team member who is very good at data, at being able to understand the different data points as well as analysis of data and different permutations and combinations of data (this would be very useful when this is a review meeting that goes into detail into coding data or defect analysis); on the other hand, when you have a meeting that talks about project starting and about the various options and variables, about customer inputs, you need somebody who is more clear about the requirements, about the options in this, about what the customers think like, and so on. Everybody would know some details, but there are always some specific team members who are more fluent in different parts of the project, and one should always try and match these abilities, unless it is a really routine meeting.

Focusing on the usability and ease of reading

Recently. I was driving past a gas station next to the highway, one that I had passed by earlier and this time saw a new board announcing some new eating options. Given the speed at which I was driving, I would normally be able to read the signs on the board, but the lettering was in a fancy script where I was not able to read it (or rather, it would have taken more time to read it than the time I had while driving past it). I asked the other people in the car whether they were able to read the names of the outlets that were on the sign, and none of them were able to read in the short duration of time that we had while passing by. This was not true of other signboards that were in plain simple script, not some fancy script.

While reliving this experience, my experience in an IT industry came to the fore, all the discussions with the usability experience and the discussions with the usability expert came to the front. If the gas station signboard was written after consulting with an experience expert, then they would have realized the use case and had the sign board written in a way that people could read it while passing by and maybe be attracted enough to stop by before they passed the place. 

And this is what usability is all about. While doing the design of any new user screens or even when looking at the redesign of an existing screen or user facing UI, or anything similar, it is always important to look at how this will look at the users. When the design is being done by the people behind the development and testing team along with the product manager, it is necessary that it be consulted with a usability expert. It is important to emphasize this point because there have been so many cases where the people that have been working on the product for so long feel that they know what the customer wants and will resist what a usability expert emphasizes on (there are specific examples I know where the usability expert has recommended changes in the workflow or the screen, and the development team has not been able to appreciate the changes or are very resistant to these changes).

One way to make sure that the development team understand the need for usability is to get the team members looking at user forums or defects logged by customers, as well as getting them to actively looking at beta programs and interacting with the users - this can get them to quickly change their perspective of what is important for the product.