Team Dynamics in the Innovation Space – UX Planet
The role of UX design has evolved over the last few years: from wireframes in Balsamiq, Omnigraffle and Axure, to running Design Thinking Workshops and conducting user testing.
I have been thinking about my career path and what other value I bring to companies beyond designing better solutions. I passed this baton to different cross-functional teams, leaving me to just polish the outcomes of the workshops and conduct stress tests.
The shift of my job description also has opened a new door where I see a company and the interaction between employees as an experience all its own. The employees, as individuals and as a group, impact the innovation and process, making it either easier or more difficult.
I am talking about the big or small idea to build a new application. There are companies, and we know who they are, that are better at building new things than others. But, why is that?
The biggest obstacle for a company is overcoming the individual or group mental models. One part is the process mental model that is the framework of past successes. It provides management and leadership the reassurance that continuing down this path will be safe and lead to repeated success. The other is the assumptions that come with domain-specific knowledge and not really understanding a different subject matter. One or both mental models can block the ability to innovate and ship a new product.
In experience design, we often question the antiquated mental model process by asking what the scope is and what deliverables we can create? The assumptions are often reflected in feedback from interaction patterns, wireframes and prototypes.
What are Domain-Specific Mental models?
Let’s look at an example in the FinTech world and how these different frameworks provide a very specific point of view. We are looking at the product owner/stakeholder, a new UX designer, and an actual customer.
Three Common Frameworks
Here are three pretty common mental models from product owners, UX designers, and customers that I have seen while working as a consultant at different companies.
The Product Owner (a.k.a. business analyst, stakeholder, project manager) Mental Models
- A stakeholder for accounting software might have an accounting degree or practiced accounting before becoming a product owner. In his world, she/he may insist on past personal experience as the universal truth due to his/her field experience.
- The personal opinion is often based on other software experiences. A stakeholder may just use Apple products and insist that the new accounting software should work just like Truebill on the iPhone.
- A competitive audit is a common ask where UX or strategy reviews the top 3–5 competitors. The audit compares the features and designs of several applications to identify what has been well or poorly designed and executed in development. The downfall of a poorly done audit is that the company may just rebuild the same features to catch up with the competitor and fail to innovate on their current application.
- The business goal is often to find out what proposed new feature will gain more market share. In a well-oiled company, the feature or application is often vetted against the ROI (return on investment) before going into a design phase. In most cases, though, it might be a singular stakeholder view and could be a huge flop.
The UX Designer (a.k.a. Product Designer, UI Designer, IA Designer)
The UX designer may think of current industry trends, publications or a new feature that a major company like Google may have implemented.
- The designer may have recently discovered virtual reality (VR) on a website and considers this a great splash page for a new personal accounting application. They may imagine how nice it would be to talk and interact with a virtual bookkeeper.
- There might have been a recent article in FinTech discussing the trends of voice banking, a still-maturing trend. The designer may pitch adding voice banking to accounting software as part of meeting industry standards.
- Google implemented a new experience to their calendar. Instead of color coding different calendars such as work, a friend and home activities, the user can now see each calendar in its own vertical swimlane for the day. While this may work for Google, it may not be the best experience to implement for the payroll calendar on the application. Some may prefer a more traditional calendar view and expect to see vertical swimlanes used for different days of the week.
The Potential Customer
The actual user may consider anything that beats the current experience as better. The bar may be extremely low or high depending on the current experience.
- The person(s) we actually built the application for may have very different expectations from what we may actually think of. In many UX meetings, we talk about age, income, profession, and tech knowledge in order to have deeper insight into how the user may prefer to use an application.
- The standard, though, might even be lower. Before online banking, a person had to drive or walk to a physical bank location to deposit a check. When depositing a check online became available, a simple functional feature was good enough because, even if the userflow was less than optimal or clunky, it still saved the person a trip.
- However, for a new banking application, the minimum expectations are super high. Most users have more than one bank and are now familiar with the applications. The new application has to at least meet the feature set of its competitors and, ideally, provide something the other bank does not, such synching with Quickbooks.
Design Thinking and Workshops
Those three mental models are often in conflict. On a well-oiled team, the friction actually leads to very powerful innovations, rethinking current mental models, merging them and creating a new paradigm.
Design Thinking does unhinge the different stakeholders from previous mental models, and move their framework to the customers and what they may experience.
In troubled teams, the stakeholders will try to overpower each other. The loudest or the person with the most decision power will drone out the voices of the other team members. Workshops like design thinking, affinity mapping, etc. can help stabilize the team dynamic. You must still meet the challenge of maintaining balance in the room, though, since the loudest person may still try to overthrow the entire process.