Monday, April 25, 2016

Roles and expected contributions

On a remote day of work, there was very little discussion. I was focused on the application over the team's Flowdock channel when a discussion started.

Four developers at the office had started to wonder about a user interface design element on something one of them was working on right now. The question on the channel was directed at the user interface specialist, with a picture: "what if it was this way instead?".

The discussion continued  on defining relationships of concepts to be selected: should you be able to select two at once out of the list or just one? Should there be a "no selection" option too?

The user interface specialist comes up with a conclusion on selection  between radio buttons and combo box, that the discussion boils down to: "There's no reason to hide the selections from the user".

A developer comes back with a consistency argument: there's another element conceptually just like this just right above this and it uses a combo box. Why shouldn't the two be the same?

I enter the discussion, repeating the consistency argument. But I also add a piece of data: in 90+ percent of the cases, the user does not want to make a selection of this. Selecting anything but "no selection" is a special case.

The conclusion changes with the added data. In this case it's natural to have a combo box over the radiobuttons. A design is agreed upon.

I share this story to emphasize that it does not matter whose role is what and what contribution you could expect based on the role. As a tester in the team, I have a lot of empirical data and a keen eye on the real use cases through listening to end users.

Seeing this through a discussion over addressing it through hands-on testing just made everyone's life a little easier. Hat tip to my developers on initiating a discussion that required them effort due to remoteness, and on persistency on caring how it would be.