Directive Versus Collaborative UX Consulting

By Baruch Sachs

Published: September 9, 2013

“Our engagements to consistently require thought leadership around best practices for using our products. This is sometimes a new experience for our clients, who just expect us to enable them to do what they want to do rather than learning how they can do something better.”

My UX team consists of highly skilled, outgoing UX professionals who live and work all over the world and engage with a diverse set of customers—both rewarding and challenging. Generally, our consulting style is a blend of directive and collaborative consulting. By this, I mean that we provide thought leadership on how to create successful user experiences for our software products, but we do this with a customer rather than to a customer. This is a common and effective approach, blending leadership with a desire to be inclusive and get everyone on board with our ideas and see them come to fruition.

Recently, after an engagement of several months, one customer told me that one of my consultants was almost too adaptable to their needs. This struck me as a bit odd because adaptability is what we are all about in the consulting world. We lead people without commanding them. We adapt to and work within a customer’s culture, while still exposing them to new ideas and methods that will make their project a success. Since my team and I work for a software vendor and are the subject-matter experts for all things relating to the user experience of our products, I expect our engagements to consistently require thought leadership around best practices for using our products. This is sometimes a new experience for our clients, who just expect us to enable them to do what they want to do rather than learning how they can do something better.

Hearing that we need to be more forceful in applying our methodology, UX best practices, and UI design approach is not something that I’ve become accustomed to over the past few years. However, I do see a slight shift that has led me to think more deeply about directive versus collaborative consulting styles and how they relate to user experience.

Most UX engagements—and indeed, most general consulting engagements—employ a mix of both directive and collaborative styles. Very rarely, in my experience in user experience, is an engagement entirely one or the other. Given the fact that UX consulting is as much about leadership as it is about design, it is becoming more and more critical that we understand how our leadership style affects our consulting abilities.

Leadership Styles

“As UX professionals increasingly take more of a leadership role with their clients and customers, it is becoming critical that we better understand the concept of leadership.”

As UX professionals increasingly take more of a leadership role with their clients and customers, it is becoming critical that we better understand the concept of leadership. There are four main leadership styles:

1. Focusing on tasks and concrete objectives
2. Focusing on people and their needs and developing followers
3. Taking a directive approach, in which the leader sets an organization’s direction and makes all decisions
4. Taking a participatory approach, in which the leader shares decision making with others
5. Taking an adaptive approach to leadership

This fifth, adaptive leadership style speaks strongly to me, because the quality of being adaptive is critical to being a consultant. Adaptive leadership uses context to determine which of the previously mentioned leadership styles is appropriate in a given situation.

Consulting Styles

“In directive consulting, we take the leadership role. We initiate all activities and tell the customer exactly what to do to be successful.”

Consulting style follows leadership style. So, in directive consulting, we take the leadership role. We initiate all activities and tell the customer exactly what to do to be successful. This style of consulting can be very effective, but it is important to truly lead a customer that needs this style rather than making them feel as though you are pulling them in whatever direction you want them to take.

In a collaborative consulting environment, we provide information, best practices, and suggestions to a client, but it is up to them to decide how best to use the information we’ve provided—with our expert guidance, of course.

The most basic form of research, doing a Google search, quickly shows which style of consulting is more popular. Search for collaborative consulting, and you’ll get a great many hits. There are consulting companies with collaborative in their name and lots of articles on how to be more collaborative in your consulting approach.

Searching for directive consulting yields far fewer and less substantial results. In fact, you’d have to dig to find anything on the topic. When your leadership style and approach to consulting are directive, rather than your customers perceiving you as being supportive, they may perceive you as being someone who just tells other people or groups what to do, without explaining yourself or fostering consensus.

How the Maturity of User Experience Affects Your Leadership Style

“User experience, as a practice, is at a critical juncture: an ever-widening audience is aware of its value—even if they don’t understand its value in depth.”

There is now less and less need for the profession of user experience to prove its importance. User experience, as a practice, is at a critical juncture: an ever-widening audience is aware of its value—even if they don’t understand its value in depth. Thus, the thirst for UX leadership is growing. In the past, it was enough just to be collaborative in our consulting approach. We worked side by side with our customers and sometimes provided leadership to help them craft a successful user experience.

Now, as our customers increasingly are looking to us to lead, our leadership and consulting styles need to be more adaptive. Sometimes we need to be the leader. Sometimes we need to be the collaborator. At still other times, we need to be the participant. It all depends on the context—the situation that we find ourselves in.

Adapting our consulting style requires us to tap into the psychological side of user experience, which enables us to perceive which style of consulting a client really needs—even if the client is unable to ask for it specifically. The ability to be adaptive in our consulting style and use context as our guide has become critical to our overall success as consultants.

- See more at: http://www.uxmatters.com/mt/archives/2013/09/directive-versus-collaborative-ux-consulting.php#sthash.ZmKg9ajA.dpuf

via UXmatters http://www.uxmatters.com/mt/archives/2013/09/directive-versus-collaborative-ux-consulting.php

How to Assess the Maturity of Your Information Architecture

Go to article

By Nathaniel Davis

Published: March 5, 2012

“[Creating] an IA maturity assessment tool … helps to quantify IA solutions in a more tangible and actionable manner.”

 

Methods for measuring the various aspects of a Web site’s information architecture are hard to find. In this month’s column, I’ll demonstrate how we can use the six tiers within the information architecture (IA) vertical of the DSIA Research Initiative’s UX Design Practice Verticals, shown in Figure 1, to create an IA maturity assessment tool. The benefit of this method is that it helps to quantify IA solutions in a more tangible and actionable manner.

Figure 1—UX Design Practice Verticals

These UX design practice verticals were the product of an IA exercise that charted the primary activities of eight unique forms of practice that play out in any comprehensive UX design project—large or small. Information architecture is one of those practices. It’s possible to arrange the following six tiers of the IA practice vertical—which together make up the primary areas of interest of information architecture—in a way that permits the quick evaluation of a site’s IA maturity:

• information navigation
• information organization
• information relationship
• IA management
• IA strategy
• IA research

By placing the first three of these IA interests on a Y-axis and the remaining three along an X-axis, we can produce a baseline chart like that in Figure 2. This chart immediately suggests that, when creating a solution for navigation, information organization, and anything that pertains to enabling information relationships, we should measure all three against a strategy, efforts around managing an information architecture, and research that monitors patterns in information and user behaviors.

Figure 2—IA maturity assessment grid

For example, as Figure 2 shows, thinking about navigation for a domain of information involves more than planning the pathways (A)—it means thinking about how to manage (B) the navigation over time and what periodic research (C) will be necessary to gain insights into the pathways that you’ve created.

Once you’ve considered all three of these aspects of your solution for navigation, you can demonstrate that you’ve thoroughly examined the navigation for your site. You should then apply this level of due diligence to organization and relationship. However, the actual methods that you employ in assessing each column determine the maturity of your site’s information architecture.

Boolean Criteria for Measuring IA Maturity

In my research, I’ve explored two sets of criteria that enable an IA maturity assessment. My first approach uses a more formal set of attributes. It goes into theoretical tangents that would put most of you to sleep. So I think I’ll pass on that one. The second approach uses Boolean-based criteria that consist of four basic values. Even though this second set is less rigorous in nature, it correlates well enough to its formal counterpart to offer valuable insights. The Boolean criteria for measuring IA maturity that I’ll review in this column are as follows:

• None—Nonexistent (0)
• Constrained—Limited and/or static in nature (1)
• Approaching—Somewhere between constrained and flexible (2)
• Flexible—Broad and/or dynamic in nature (3)

Performing an IA Maturity Assessment

Let’s see how we can apply a maturity assessment to an information architecture that is based on these Boolean criteria. Our fictitious subject: the pizzeria startup of a pizza-loving software programmer and data analyst.

To inform the selections on their menu and their business model, the analyst performed a study to understand local preferences for pizza. Her study showed that typical pizza consumers in their market eat four basic types of pizza. Having this knowledge helped them to prioritize what to include on their menu.

Unexcited about creating sandwiches or pasta dishes and understanding the difficulty of trying to predict the inventory for a large menu, the software programmer—who sees the world in smaller pieces, as he became accustomed to doing in the lean software development culture at his former job—realized that their business model needed some refining. So, he applied lean thinking, drastically slashing their large proposed menu down to just the four basic types of pizza that they discovered customers would prefer through their research. If they find there is demand for additional options, they can add them to the menu in the future. This strategy greatly reduced the operations-driven nature of their business and allowed them to get to market quickly. They consequently named the pizzeria after their new philosophy: Lean! Pizzeria.

The two owners hired a digital strategy firm to capture the essence of their model and produce a static Web site as soon as possible. Sound familiar?

The objectives for the site were just as lean as the owner’s innovative menu:

• Allow customers to view and select one of four types of pizza.
• Allow customers to view and select a soft drink.
• Allow customers to place orders with the pizzeria via text message.
• Require users to provide their contact and address information.

The resulting desktop Web version of their site might look like the mid-fidelity wireframe shown in Figure 3. At this point, we can begin our IA maturity assessment.

Figure 3—Desktop Web site for Lean! Pizzeria

Figure 4 demonstrates that, overall, the demands on the information architecture for the desktop Web site are fairly low.

Figure 4—Boolean IA maturity assessment

Figure 4 assesses IA maturity from the viewpoints of strategy, management, and research, as follows:

Strategy

• As the Strategy column in Figure 4 shows, the strategic approaches for navigation and information organization are limited and static. If a content management system (CMS) were in place, it would most likely raise the rating because of the potential flexibility the CMS would offer. For now, navigation and organization each receive a maturity score of only 1.
• The strategy for information relationship, however, is more dynamic because it allows customers to customize the quantity for a pie or soft drink in their order. As a result, the assessment for strategic maturity around information relationship scores a 2. However, this is a very low 2, partly because this behavior is modifiable only by editing the code rather than managing it through a CMS.
• Overall, the information architecture scores 4 out of a possible 9 for strategic maturity.

Management

• Referring to the management column across the board, the management of the information architecture is primarily a manual effort, limiting its flexibility from the perspective of automated tasks—for example, controlling navigation with a taxonomy engine that is connected to a CMS. This could change once the site uses content management.
• As a result, the management maturity of the information architecture is 3 out of 9.

Research

• The site exists on a hosted platform that provides basic metrics and path analysis for research. These prepackaged metrics will be useful to the owners, but of limited benefit because there’s no customization of analytics. So, the research of navigational patterns within the information architecture scores only a 1 for maturity.
• Research to improve organization and information relationship is nonexistent. The reports don’t provide statistics on actual orders—like pie size and quantity—or time of day. Doing this would require additional coding and greater integration with the hosting company’s analytics tool. Since the site’s analytics don’t provide insights about the information architecture’s organizational and relational fortitude, the organization and relationship data points both receive a 0 for their maturity.
• In the end, the maturity of IA research receives the lowest score, only 1 of 9.

“The mode through which information appears should not require a separate information architecture, only an expansion of informational attributes within the existing information architecture.”

Now, let’s take a look at the mobile version of the Web site, which is shown in Figure 5. In assessing an information architecture, the mode through which information appears should not require a separate information architecture,

only an expansion of informational attributes within the existing information architecture. As a result, just as a digital strategy would most likely require a cross-channel user experience plan, a single information architecture should hold together the desktop and mobile modes of interaction. Knowing this, we can assess one more additional aspect of the navigation strategy for the Lean! Pizzeria information architecture.

Figure 5—Mobile optimized Web site for Lean! Pizzeria

One element of the information architecture’s navigational construct is that it’s responsive—the sequencing of the link nodes that support navigation changes according to the mode or device. Notice how, in the desktop mode shown in Figure 3, the global navigation in the upper-right corner includes three items, but for the mobile mode, they are all suppressed, and there is only a Help link. This dynamic behavior in the navigation raises the maturity of the navigation strategy to a 2, as shown in Figure 6. However, similar to the relationship strategy score, this is a very low 2.

Figure 6—Boolean IA maturity assessment

Final Maturity Assessment

“With a Boolean assessment approach … and the data and patterns it reveals, it’s possible to greatly improve the analysis and prioritization of information architecture enhancements.”

 

Through our review of the vertical segments of the maturity assessment chart, we’ve calculated Lean! Pizzeria’s IA maturity in strategy, management, and research. Consequently, the last column in Figure 6 reveals the totals of the individual maturity scores for navigation, organization, and relationship. We can now calculate the IA maturity of all six areas of interest for Lean! Pizzeria’s practice of information architecture.

As shown in the cell in the lower-right corner of Figure 6, we can estimate that the information architecture for Lean! Pizzeria’s digital strategy is functioning at one-third (9/27) of its optimal potential, suggesting not only room for improvement, but also which types of improvements to explore. With a Boolean assessment approach similar to the one I’ve just described and the data and patterns it reveals, it’s possible to greatly improve the analysis and prioritization of information architecture enhancements.

Summary

“Information architects … have struggled with determining what constitutes an information architecture’s measurable components.”

 

A major reason why the maturity of a site’s information architecture has remained difficult to quantify is because information architects and other UX professionals who organize and create relationships between information have struggled with determining what constitutes an information architecture’s measurable components. Through clearly framing the practice of information architecture and vetting that framing of IA practice against DSIA Research Initiative’s UX Design Practice Verticals, the Boolean IA maturity assessment method that I’ve just reviewed has become possible. However, this is only a glimpse of what would make a complete IA maturity assessment actionable.

There is much work left to do to improve our understanding of the work products of information architecture. As more professionals choose to practice information architecture comprehensively, I would expect to see an IA maturity assessment—in one form or another—become a standard artifact in future IA documentation.

Note—Measuring the maturity of an information architecture is a new area of research that I first explored publicly in my ASIS&T Bulletin article titled, “From Tsunami to Rising Tide: How to Plan for a Successful Information Architecture Strategy.” That article presented my original thoughts for a domain maturity model for information architecture strategy. That thinking contributed greatly to the criteria I’ve used in this column and is central to the more technical criteria that I have not explored here.

Reference

Davis, Nathaniel. “Boolean IA Maturity Assessment.” DSIA Portal of Information Architecture. Retrieved March 2, 2012.