A Case for Collective UX and User Interface Engineering
So I recently read an article on Huffington Post the other day that said Group Brainstorming is Waste of Time. The author made a good case based on his years of experience in business psychology and research. But I respectfully disagree as the article made some generalizations that at the least, cannot be applied to all group brainstorming activities. I would argue that there are steps that can be taken that can counter the problems outlined in that article. And I have seen them work.
In recent years, I have had the pleasure of being on multiple teams that built UI for awesome enterprise-grade products. On one of those teams, we simply decided that we will brainstorm the mock-ups of the new features as a team. The operative word here is team. You see, the thinking was (and still is with me), that once functional features are defined, it is understood that the team collectively owns the product. And that code and its quality are the team’s responsibility. Well, then why stop short of including user experience as part of that? Should developers not care about the target audience of the software? Should developers be agnostic to the idea and understanding of personas that their daily work is catering to?
I firmly believe they should. The era of mutually exclusive/agnostic specialty roles in software development is over. Companies are employing new development processes which are holding the entire engineering team (a whole company in some cases) responsible for the product, while the jobs of producing the art (code, mockups, requirements, etc.) still remain well defined and individually assigned. For example, engineers do not need to travel every week interviewing the customer base to understand personas. Yes, but they need to understand what those are and what use cases the software serves. Over time, developers understand the user pains and become more empathetic to UX and avoid surprises on architectural refactors.
Based on that understanding, the team decided to do mock-ups for a new dashboard feature collectively. The UX Director had done a great job in laying out the personas, users and high-level stories. She had also coached us on most UX 101. For a side project, I personally learned how to conduct KJ Sessions and Usability Test sessions. Armed with just white paper and pencils, all of us decided to do mock-ups of what the page would look like, what and how the data would be presented, state transitions, user messages i.e. the whole nine yards. After a round, each one of us presented our mock-ups and explained the page.
Remarkably, we were not deviating from each other's design drastically. As it turned out, naturally, the final design consisted of at least one idea from every engineer. I believe this naturally happened because of the experience they brought to the table. All along UX Director was there to keep us on track and do a sanity check of the design. She was not there to dictate the design that she would have liked or sideline ideas that were better than hers. She was there to make sure that the design was staying true to the end users and we avoided violations of basic UX principles. She was an integral part of this team exercise.
Now, in the context of that little story, which I have seen successfully repeated multiple times, let us look at the four explanations in the brainstorming article and see how they may not hold water.
1. Social Loafing: That did not simply apply in the case I cited, because the output demanded from the team members was outlined well. The goal was team based but tasks were not. If engineers shy away from having individual tasks in a team environment, then you have other problems at large.
2. Social Anxiety: Not that I am a face reader, but yes, you can see a team member be dejected sometimes. That is where a team leader can step in as a facilitator, make sure that opinions will not be suppressed and all ideas will be discussed thoroughly. The fact that each member must come up with something (anything) is good enough. Confidence will follow. By any measure, this did not happen in our exercise.
3. Regression to the Mean: Good point of the author. But, the way we avoided this in our case is that more talented people (or let us say more experienced UI engineers) did their own thing while not worrying about what the junior engineers were doing. Again, the expert in the room (the UX Director) can strike a balance here, by calling out the good parts of the designs by junior engineers.
4. Production Blocking: Yes, but then again if the group size is too high, to begin with, you are setting yourself up for inefficiencies. Companies often fail to get consensus on trivial issues in large groups, let alone brainstorming. Software teams need to be small and lean. The team was sized to 4 in my story. And everyone’s ideas were heard and accepted to a great extent because the group size was small and we were able to time box it.
So in short, group brainstorming does not have to be a waste of time if it is planned right, starts with reasonable group size and is well facilitated. I believe that starting off with this approach, in general, will help. But again, repeat what works and change what does not.
Originally published at https://medium.com on March 31, 2015.
