Chapter 4. Bringing Together a Team
Since the entire course of your project will involve the application of intellect to identifying and solving problems, the capabilities and aptitudes of your team members (stakeholders included) will be the single greatest contributor to the success of your project. No amount of process, no brilliant development methodology, and no force or aptitude of management can bring about as much success as a talented, driven team can. That is, unfortunately, one of the weaknesses of what we’re able to offer through this book. We can provide roadmaps, strategies, and tactics to help you find your way through the project, but if the people applying those concepts and doing the design and development work aren’t adequately creative and qualified, you’ll be swimming against the current the whole time.
Of all the things EffectiveUI has figured out how to do well over the years, hiring amazing people was our first priority and has remained our principal focus. We’ve been very fortunate in being able to attract some of the top people in our field, because our company works on the cutting edge of this domain and is able to provide a more challenging, user-focused alternative to talented people. All of the learning that’s described in this book has been developed through putting those people together in challenging situations.
But most people don’t have the opportunity to access a pool of specialized, highly qualified individuals. You may be cobbling together a project team from various departments in an organization, or working with an IT team that is more accustomed to maintaining legacy applications than building new ones. The only designers available may be print and brand designers from your marketing department. You may have access to terrific developers, but no access to UX design professionals, or vice versa. The single most important thing you can do to help the success of your project along is to get the best possible team assembled, so vigorously addressing deficiencies should be a top priority.
That advice really bears repeating on its own and in boldface:
The single most important thing you can do is to get the best possible team assembled.
Given the difficult constraints you and your company are probably operating under, this may not seem like particularly useful advice on its face. Good people are expensive and hard to find, so the cost and scheduling constraints for your project may seem to prevent you from being picky about who you have working on it. But this is one among many ways in software development where it’s easy to be penny-wise and pound-foolish.
Cheaper, more readily available resources are that way for a reason: they’re less experienced and qualified. These deficiencies, in turn, cause the development of the product to be less effectively performed and less efficient. Less experienced people can’t anticipate or address issues as effectively as pros. They make progress more slowly, produce lower-quality results, make more mistakes, and are less capable of making estimates and hitting goals. The burden of all of those problems accumulates over the course of the project, leading to a higher chance of low-quality results or outright failure.
It’s important to appreciate the enormous complexity and difficulty of building a software product and not discount the skill it takes to succeed at it. If you’re building a skyscraper, you wouldn’t consider hiring a bunch of day laborers to do the job. Their progress would come much, much more slowly, and their lack of experience would lead to problems in the project that would cause massive ripple effects and impose enormous risk. It is exactly the same with software.
So if you’re stuck thinking, “I can’t afford to hire highly trained professionals for every position,” consider whether you can afford less-qualified professionals who underdeliver, fail to meet expectations, develop an unstable system, overrun your budget, or simply fail. Experienced professionals may be more expensive per hour, but they’ll require fewer hours to produce stronger, higher-quality work, and the six weeks you might have to spend finding them will be more than made up for by the risk and difficulty you will have averted.
The Project Leader
The role of the project leader is not well understood, so it’s too often left unfilled. There may be a primary stakeholder who provides oversight and answers questions, or process-oriented project managers charged with managing the schedule and budget, but they aren’t what the project needs as a leader. Effective project leaders have a unique and multifaceted role:
They are managed by the stakeholders, but they must manage the stakeholders.
They manage the project team, but they serve the project team in their drive to make progress.
They stand for firm fidelity to the business and user requirements, but they fight to preserve a rational approach to uncertainty and the unknown.
They carry the high-level vision for the product and are a living encyclopedia of the cumulative knowledge developed throughout the project.
The project leader is the standard bearer for the project, charged with ensuring its success, no matter what obstacles the project may face.
Relationship to the Product
An effective project leader fully owns the product—its requirements, its challenges, and its outcomes—by staying deeply immersed and engaged in the project through its entire course. No one else involved in the project will have the opportunity to consistently stay at this level. The project team will be busy solving specific problems and implementing specific functionality, so they can have difficulty keeping the whole product in mind and staying focused on its high-level goals, mission, and criteria for success. Stakeholders have many other priorities to attend to and can’t keep their minds engaged with the project. They can’t keep up to date with the project’s day-to-day discoveries and challenges, which makes it hard for them to make informed decisions.
Only a person who lives in a state of high-level, long-view orientation with low-level, daily engagement can successfully hold the vision for the product together, liaise between the needs of the business and the practical realities affecting the project, and effectively guide successful decision making. This is a very time-consuming role that requires a passionate commitment to the project’s success and a deep immersion in its minutiae.
Relationship to the Stakeholders
As previously mentioned, the project leader is in the unusual position of being accountable to and managed by the stakeholders, but also of needing to manage and exert a certain level of control over those stakeholders. To the stakeholders, who have limited contact with the project team, the project leader is the individual representative of the project. The stakeholders look to the project leader to provide them with an understanding of progress and to apply the pressures of accountability. To the project leader, the stakeholders are the guardians of precious information about the business’s needs, the product’s users, and specifics of different facets of the business that influence the product. Stakeholders are also the gateway to resources.
Stakeholders must participate wholeheartedly, constructively, and capably in the project, and they’ll need prodding and guidance from the project leader to do that. If the project leader can’t induce stakeholders to participate in a helpful way, the stakeholders will represent a huge source of risk for the project.
Because the project leader is the project’s ambassador to the stakeholders, her credibility and trustworthiness with them is of tremendous importance. The stakeholders are entrusting the project leader with costly resources, with the task of solving a critical business problem, and with representing their interests through the course of the project. The better the project leader’s credibility is, the more willing the stakeholders are to provide resources, to be deferential with respect to the project leader’s assertions about the processes and constraints that guide the project, and to allow the project leader wide latitude in making decisions on their behalf. The project team must be able to rely on the project leader for quick and reliable answers to questions, which requires trust on the part of stakeholders to allow the project leader to make those decisions autonomously at times. There are many opportunities to build trust with the stakeholders through effective facilitation of the project, which we will discuss in the coming chapters.
The project leader needs to educate, guide, and manage the stakeholders through the product development process. Stakeholders will be experts in whatever field and domain of the business they’re representing, but may have little or no experience in developing innovative software products. Since the process is often counterintuitive and requires patience and restraint, the project leader’s credibility is again of critical importance to helping the stakeholders understand the project’s progress and how to best support it.
Stakeholders usually don’t understand how software is built and don’t have an intimate understanding of the state of the project, so they can interfere in the project in inadvertently problematic ways and represent a source of risk. But stakeholder interference should never be an excuse for failure. The project leader is responsible for the project’s success and must defend it from any source of friction and risk, even if that source is her own superiors. No excuse matters if a project fails or falls short of expectations. The project leader must recognize her comprehensive responsibility and accountability and seize control of everything influencing the project, stakeholders included.
The project leader may also act as a moderator and facilitator for events and exercises that involve the participation of stakeholders. Because of their differing positions and backgrounds, stakeholders are likely to have diverse and sometimes contradictory opinions. It’s the responsibility of the project leader to corral stakeholders’ opinions toward actionable consensus and ensure that stakeholders don’t impede the momentum of the project.
If project team members are pulled from a variety of departments in the company, the project leader may also find herself accountable to the managers of those departments, regardless of whether those managers themselves are involved in the project. It’s extremely important to the success of a project that the project team is working toward, and is accountable to, the project’s goals. When the team is comprised of employees from different departments, they might act as agents of their departments rather than as members of the project team. Their responsibilities to their respective departments also might strain their ability to give the project the attention it requires. So it falls to the project leader to act as an intermediary between project team members and their respective departments and managers. The project leader must reassure managers that their resources are being put to good use and ensure team members feel free to focus on the project. As well, department managers who aren’t active stakeholders in a project might nevertheless try to influence it by way of project team members. The project leader needs to recognize this and step between the team member and the manager to retain control of the project and stakeholder expectations.
Relationship to the Project Team
A project leader needs to be deeply immersed in the project and embedded in the project team. Stakeholders and process-oriented project managers tend to manage teams with a certain degree of distance and abstraction. The project leader, on the other hand, must be on the ground with the project team, working with them through every critical decision and staying abreast of the current state of progress, risk, thinking, uncertainty, and unresolved questions. It’s only through this active level of involvement that the project leader can effectively guide decision making, keep the project team focused on the high-level goals, and have a total, accurate understanding of the state of the project. This total understanding is critical for her ability to make accurate commitments to stakeholders and to maintain the delicate alignment of expectations and reality.
The project leader is in yet another dichotomous position in relation to the project team. Because she is accountable to the stakeholders and to the success of the project, the project leader must manage and guide the project team toward a successful outcome, but she is also there to support to the project team. Designers and engineers working on innovative projects need quick, decisive answers to thousands of tough questions; many of those answers can be provided rapidly and correctly only by someone who is responsible to the stakeholders and the high-level goals of the project and is also familiar with the low-level details. As the project team wades deep into the details of the project, the project leader needs to ensure that they don’t lose sight of the project’s high-level goals and that their decision making is guided by the framework requirements.
Who Should Be the Project Leader
The nature of the project leader’s role likely means there are few people in your organization who are both capable and available to do it. The person filling the role must have a strong degree of trust and credibility within the organization, and those people typically don’t have time to lead a project. For most projects, the role of the project leader is at least a half-time focus.
Your project may already be spearheaded by someone who can fill this role, making the choice automatic. If that’s not the case, you may look to someone from the department or business unit at the head of the project for someone who can fill this role. If your organization has UX or CX specialists on staff, they may also be a good choice.
Have the time available to devote to the project
Be passionate about the project and dedicated to its success
Have the humility necessary to allow her to facilitate a process that will be guided more by other people’s ideas and vision than her own
Excel at motivating people and enabling their success
Have the trust, credibility, or clout necessary to wrangle stakeholders
The project leader’s role is very much like that of an entrepreneur. It’s a role that requires passion and an ability to preserve a focus on vision and goals while attending to all of the tiny details. The success or failure of the project is entirely the project leader’s responsibility, even though other people do almost all of the work necessary to succeed.
If you’re working with a third-party vendor for UX design and development services, it may also be an option to have one of their UX designers, interaction designers, or product managers fill this role. This can be a challenging choice, though, since the project leader must have credibility and trust with the stakeholders and latitude to make decisions on their behalf. Representatives from vendors are usually treated with cautious distrust if there isn’t a strong history of partnership between the two companies. On the other hand, the representative’s extensive experience in product development may be a credibility-strengthening quality that isn’t available from within the organization.
As a matter of convenience, throughout this book we’ll assume that “you,” the reader, are responsible for helping to lead the project, whether as the project leader or as a key contributor.
The Stakeholders
Every project has a set of stakeholders, whether or not they’re all immediately identifiable; many more people will try to influence the project than will be willing to actively participate in it. For professional service companies, stakeholders are almost always representatives of the client, but those representatives have their own stakeholders. For internal projects, stakeholders are those people who control the budget, the resources, the mandate, and the domain knowledge that fuels the product’s development.
The participation of stakeholders is essential to a project’s success, but there are many ways that stakeholders can unintentionally hinder the project. Most stakeholders aren’t familiar with how innovative, UX-driven software products are built and can at times unwittingly behave in ways that derail progress or interfere with good decision making. It’s important, therefore, that the relationship between the stakeholders and the project is set up for success, and that the stakeholders are aware of how they can best support the project’s progress while still having their interests attended to.
The project team relies on stakeholders to provide a thorough and stable understanding of the project’s goals and its user base. As the development of the product begins and design encounters unknowns, a steady stream of difficult questions arise. It’s critical to the progress of a project that answers to those questions can be readily obtained and are firm and reliable. From the beginning of the project through its end, the project team relies on stakeholders (by way of the project leader) to provide reliable, steady direction for the product. Stakeholders need to provide clarity that diminishes uncertainty and risk, rather than increasing uncertainty and risk through frequent changes and unstable decisions.
Securing Authority
Since the decisions and direction provided by the stakeholders to the project team need to be stable and reliable, the authority of the stakeholders to commit the project along specific lines also must be stable and reliable. This may seem a strange concern, since stakeholders are typically higher up in the company and are ostensibly conveying their authority down to the project leader and team. But a lack of clear and secure authority in stakeholders is actually an enormous problem for many projects.
The stakeholders must ultimately speak as one voice and communicate a unified vision for the product, provide only one answer to a question, and choose only one favorite from any list of options. The project’s success will be greatly jeopardized if:
The decisions made by the group of stakeholders actively participating in the project must be definitive and must be supported by stakeholders and influential people who aren’t actively participating in the project. This degree of authority and support often isn’t automatically in place, and if you don’t secure it at the beginning of the project, you risk the bottom falling out of the project midway through. Your stakeholders might have their own stakeholders, but the project can’t wait for or depend on decisions to be run up the management ladder. The active stakeholders on your project must have the necessary authority to commit to decisions that won’t be overruled after they’ve been made.
Authority afforded by trust
The list of people interested in affecting a product’s development is always much longer than list of people who have the time or ability to actively participate in the project. Some managers of involved departments or business units assign someone under them to participate in the day-to-day activities of the project, but then these managers will appear suddenly when they disagree with decisions or when the project grows in significance. The same can happen with managers who either declined to participate initially or who weren’t initially actively involved but later decided to assert themselves in the project. Other stakeholders may participate in the original concept work on the project, disappear during the early stages of development, and then reappear later in the process.
This kind of behavior poses a number of serious problems for the project. From the project kick-off through to its end, the progress of a project entails a tremendous amount of thinking, design, decisions, and compromises. Anyone who hasn’t participated actively in that progress lacks much of the context and information that is necessary for understanding why certain decisions were made. They also lack the perspective necessary to balance their ideas and individual agendas against the other priorities and considerations that are guiding the project. Late-arriving or on-again, off-again stakeholders, not understanding or appreciating the decisions that have come before, often challenge decisions or revisit basic premises that would shake the foundations of the project. As we discussed in Chapter 3, changes stakeholders may perceive as simple may, in fact, be enormously difficult and costly. These changes will probably be improper if they’re imposed by stakeholders who haven’t actively participated in the project.
So, although late-arriving stakeholders can be welcomed if they trust and are deferential to the progress that’s been made so far, you should head off late-arriving and hidden stakeholders who might derail the project. This requires some effort up front to determine who should be active stakeholders on the project. The group of active stakeholders must consist of people who are in a position to contribute to the project; they must also be vested with the trust and authority of the other potential stakeholders.
This means that a manager who assigns a subordinate to represent her interests in the project must trust him to make decisions in her stead, must be available to him if he should want her input, and must be committed to working through him and never around him. It also means that departments and business units that decline to participate actively in the project must place trust in those who are actively participating. This usually means the group of active stakeholders needs to be strongly representative of the diverse domains and interests within the organization so all interests can trust that they will be well represented.
Authority in rank
It can be difficult when some of these hidden and late-arriving stakeholders are senior managers and executives in the company. Many projects start off as initiatives of lower-level areas of individual departments, but then grow in prominence as they near completion and their ability to significantly impact the business becomes more apparent. Senior managers tend to tune in to the project as it nears completion, and to have strong opinions and interests that weren’t present as the project ran its course. They also hold prominent positions in the company, so existing stakeholders and the project leader have difficulty challenging their demands. Or they represent departments that want to take over management of the project and profoundly redirect its course. Companies that are large, highly political, and bureaucratic are particularly susceptible to these issues.
It’s therefore important that the group of active stakeholders is backed up by sufficient authority in rank to insulate the project from this type of problem. If the project mandate is delivered by senior executives, the project is more likely to be well insulated against incursions by less senior managers. But if this isn’t the case, you need to secure some high-level backup early in the project. This may be accomplished by seeking out the executives who aren’t necessarily able to actively participate in the project themselves but are likely to be affected by the product outcome. Spend time with them to find out what practices, information, and people they feel must be in place in order for them to fully trust the process without participating in it. You’ll need to get them to explicitly commit to trust the process and to lend their support, should other executives start to meddle.
Collaboration and Decision Making
Though stakeholder participation in the beginning of the project is mostly structured in the form of in-person workshops, their participation through the rest of the project is much looser. It’s not necessary—though it may at times be useful—to bring everyone together in person for every decision. Stakeholder schedules are likely too busy to allow for many in-person meetings.
It’s important to figure out early on how collaboration and decision making will work for the project. The momentum and success of the project depends on stakeholders rapidly answering questions, providing guidance, and deciding on course adjustments to respond to discoveries and risks. Some method of collaboration should be agreed upon and put into effect early in the project. It doesn’t really matter what that method is, so long as your stakeholders will use it; orderly, consistent collaboration is the goal, and every company and stakeholder has a different approach to this. You need to make it clear that stakeholders must tune into and participate in the discussions and decisions that happen during the project. Stakeholders must understand that if they don’t actively participate and respond, they’re forgoing their rights to affect those decisions later on and they may begin to lose the context necessary to contribute to future discussions and decisions.
The Characteristics of a Successful Project Team
The raw materials that go into building a software product are the intelligence, ingenuity, and creativity of the team that builds it. So it follows that the strength of the project team you’re able to assemble will have an enormous effect on the project’s outcome. Modern, UX-focused software projects tend to be built by relatively small project teams, usually 5–15 people who won’t all be working simultaneously.
This may seem obvious, but a strong degree of unity within the team is critically important. There’s an energy and efficiency inherent to groups of people who are all thinking about the same problem and working alongside each other; this doesn’t exist if they’re isolated from one another. Unified teams share a sense of ownership in creating something valuable and reflect each other’s enthusiasm, whereas members of fragmented teams just focus on handing off deliverables without embracing a sense of being part of something larger. Collaboration in UX-focused project teams needs to happen by way of discussions and design, not through deliverable hand-offs.
If people are brought together from a variety of departments or from a mixture of internal and external sources, they may feel accountable to priorities other than the project itself and may work from different locations. Bringing everyone together into one centralized office can help build a sense of unity around the project and also makes collaboration much easier. If you can’t get everyone together in one space, you should try to provide team members at least one opportunity to meet face-to-face; it makes a remarkable difference in their ability to work together. EffectiveUI has multiple offices and we often work in distributed teams, but in our main office, all of the designers, engineers, project managers, and other project team members are together in one space. As we’ll discuss in later chapters, the process of building UX-focused software involves constant and active collaboration amongst all the roles and disciplines involved in the project. Thus it’s important that visual and UX designers aren’t segregated from software engineers. Being together also helps the team members become better acquainted with one another’s concerns and professions, which in turn helps everyone make better decisions. A software engineer who’s had strong exposure to UX design does a better job of building components with good UX, and a UX designer who’s familiar with engineering practices and constraints creates designs that are easier to engineer.
The need for the different professional disciplines to work together implies another important characteristic of a successful team: mutual respect amongst team members for one another’s expertise and the value and constraints of each discipline. In settings where the visual and UX design staff and effort are segregated from the software engineering team and effort (as in a waterfall process, discussed in Chapter 3), there’s a strong tendency for the UX and visual designers to be unaware of or to not heed the constraints imposed in software engineering. As a result, they specify things in their designs that are needlessly difficult to implement, or they offer only a small benefit in exchange for significant expense in engineering. A software engineering team that’s segregated from the UX and visual designers also tends to undervalue the thought and time that’s gone into the designs they’re attempting to implement, so they’ll compromise or change certain things to either suit their personal preferences or gain small engineering expediencies at tremendous cost to the UX.
For UX-focused projects, you need to have UX and visual designers who understand and respect the challenges presented through software engineering. You also need to have software engineers who appreciate the value of UX and visual design and the need to strive to honor the designs they’re provided. The mutual respect for one another’s disciplines is also necessary in the project team members’ continuous, intensive debates (which constitute the overall product design process).
Another key attribute of successful teams is recognizing the primacy of the user’s needs for the product. A culture of attentiveness to and empathy for the user is essential for the team to make appropriate decisions all along the way. Without a strong focus on the user:
Software engineers can let technical expediency or a desire for “elegance” get them off track.
Designers can get too focused on making something pretty instead of first making it functional.
Other contributors can forget to set aside their assumptions and defer to the guidance provided by users and user research.
Getting Professional Help
We’ll do our best throughout this book to equip you with an understanding of the components of a software development project and how everything is developed, but you also need to understand that certain things can be done only by a professional. Few would expect to develop software without software engineers; it’s a highly technical and advanced field. But, unfortunately, the same care often isn’t given to UX design, UI design, and user research.
Why? These disciplines deal in concepts and materials that are much more intelligible to nonprofessionals than software code and architecture are, so there’s a tendency to undervalue them. Many fail to recognize that UX design, UI design, and user research are as advanced and as technical as software engineering. Failing to apply professional, experienced resources to UX and UI design challenges and in user research is tantamount to undervaluing the role of user-focused design and results in an inferior product. Our assumption is that your goal is to produce a product with a superior UX quality, and that goal is attainable only with professional help.
Get specialized, professional help
It’s also important that professionals are properly specialized. Within software engineering, there’s a wide range of platforms, languages, and subdisciplines, and it’s important to work with engineers who have extensive experience with the technologies you’ll be using. Even if you have people in your IT department who are familiar with the right technologies, their experience may be limited to maintaining products. They may not be familiar with how to develop products from scratch, or they may not have worked on user-focused projects.
Visual and UX design for software is also highly specialized. The print and web designers from your advertising and marketing departments might enthusiastically volunteer to do UX and UI design, but their design experience does not translate well to UX and UI design. Likewise, user research for the purpose of building software is not the same as market research. It requires a special intuition built through extensive experience and not just “people skills.” Like a radiologist whose training and experience allows him to see tumors and abnormalities where everyone else sees only a haze of gray, the experience of professional user researchers and UX specialists attunes them to the important observations and the areas in need of exploration as they progress through their work.
Cost considerations
The more capable, professional, and specialized a person is, the more expensive he is. When cost-focused companies are faced with expensive hourly resources, they tend to bring projects in-house, hire more junior staff, or offshore projects. But this is a penny-wise and pound-foolish mistake.
Hiring more expensive, professional resources will mean your budget will buy fewer hours, but that’s more than offset by the benefit to overall efficiency. If developing software were more like manufacturing widgets, the more people you hired, the faster you’d pump out units of progress; there’s a linear relationship between number of employees and rate of production. But because of the extreme complexity of software projects, using experienced resources has a nearly exponential effect on overall efficiency, not a linear one.
This is because the units of production, whether in UX and UI design or in software engineering, are not self-contained and independent like units of a manufacturing process, nor are they perfectly designed in advance. Each unit of progress is the application of intellect to a problem in an effort to build a solution. Each unit becomes part of the delicate latticework upon which the whole of the project rests. So the pace of progress depends not only on the speed of a person’s ability to produce per-unit results, but also on the likelihood that those results are correct and reliable. If they’re not, then the stability of the product is compromised and time must be spent returning to resolve old problems (and every other problem that spawned from them). The effects of many small errors can easily accumulate into grinding, intractable problems that undermine or sink projects. A more experienced resource can work at a quicker pace, and the results of his work are much more likely to be correct and stable. More experienced resources also require less supervision; organizations often underestimate the costs associated with supervising junior resources.
Using more professional and experienced resources radically increases the likelihood of the project succeeding. Ultimately, the only measurement that matters is whether you launch a successful project roughly on time and on budget—not whether you maximized the number of man hours that went into it. The use of experienced resources offers a much greater likelihood of ultimate success and also helps make the project itself a much smoother, more reassuring experience for you and your stakeholders.
EffectiveUI worked with a client that learned this lesson the hard way. The client engaged EffectiveUI to do some of the initial business planning, requirements gathering, and design work for a new product concept. But when it came time to build the product, the client decided to use an offshore company with hourly rates that were a fraction of EffectiveUI’s. They thought they could spend the same amount of money and get a greater volume of results. The offshore company assured our client that they would succeed, then disappeared for about eight months to develop the product. At the end of the eight months—and after a number of change orders and cost increases—the offshore company came back to the client to inform them that they were unable to produce a product that functioned at all. It wasn’t just incomplete or of poor quality; it was essentially nonexistent from a functional perspective. To make matters worse, they were convinced it would be impossible to produce a functional product without a great deal more time and money.
The client finally decided to engage EffectiveUI to rebuild the product from scratch, and we were able to build a very successful solution for less cost than the offshore firm had originally quoted. In the end, by taking the higher-risk approach of trying to save money on the hourly cost of development, our client wound up spending twice as much as they should have to get the product built.
Insourcing Versus Outsourcing
It’s difficult to choose between building a project in-house versus using a vendor (or some combination of the two). There are obvious implications to cost and control. If the product is important enough to your company, many individuals and departments may be clamoring for control and participation. As a result, they might not be willing to hand that control to an outside firm. On the other hand, the resources needed to build a successful, UX-focused product may not be available internally, though there may be some misconception that they are. As we discussed earlier, designers in marketing and engineers in IT maintaining legacy systems don’t add up to a UX-focused team for building new products.
We recommend looking to the preceding section to guide your decision to insource or outsource the project. You’re in the fortunate position of having good options if you can build an internal team of professional, specialized resources who are able to work together with a unity of purpose, in the same space, and with mutual respect for one another’s contributions, and if those people fit the other attributes we described.
But unless your company has a strong track record of producing UX-focused products, you’ll be hard-pressed to find most of the key professional resources internally. Even if your IT department has qualified developers, it can be difficult to wrest control of them from their current accountabilities. Your only design resources may be marketing staffers who have the wrong specializations or who may already be deeply committed to other major initiatives. And the issue of management and technical infrastructure can also complicate things; each different type of professional requires their own software and IT infrastructural support and should be managed by people experienced in managing that specific type of professional and UX-focused projects in general.
UX-focused projects require strong teams who are working near the leading edge of software technology, so it’s likely that looking at a specialized, third-party vendor will be high on your list of options (or it might even be your only option). The strong value you get out of working with a vendor is that the vendor should have all of the attributes of a successful team in place and available to you as a turn-key solution:
Qualified and engaged staff
Unity of purpose and location
The right kind of management and technical infrastructure
Experience in UX-focused projects
No complicated cross-accountabilities within the organization
It’s also possible to build a team out of a mixture of internal people and outside consultants. But you need to establish that same unity, mutual respect, and clear focus; that need places a greater burden on you to ensure everyone comes together properly. And if, for example, you have internal software engineering resources and have contracted outside design resources, neither group will likely be accustomed to working with the other. The software engineering people are used to being in their own department, and the design people are used to being segregated from software engineering (handing off designs as deliverables and disappearing to their next projects). You also might encounter hostility from the internal team, a sense of smugness from the consultants, or other culture clashes that you need to address to keep the team working together successfully.
Offshoring
There’s one thing that’s very important to state explicitly: innovative, UX-focused projects are not good candidates for the use of offshore vendors. Offshore companies tend to favor volume over quality, throwing large numbers of lesser-qualified resources at problems. As we’ve already discussed in this chapter, that approach is fraught with risk and not nearly as cost effective as it appears.
Offshore companies with highly talented and experienced resources do exist, but even they are problematic to work with. Progress in an innovative, UX-focused project relies on quick feedback cycles among stakeholders, the project leader, UX specialists, design, and software engineers. Time zone differences between your internal team and offshore companies hinder—if not outright destroy—timely and effective collaboration, and generally have the effect of segregating the offshore team, excluding them from the overall project and design process, keeping them focused on narrow units of progress, and obscuring their insight into the state of (and challenges to) their progress. If your goal is to produce something exceptional, this just doesn’t work.
Evaluating an outsource vendor
In selecting a vendor to perform some or all of the services for the project, all of the criteria used to define a successful team should be used to assess a vendor. For example:
Are their resources sufficiently qualified and specialized?
Do they fully understand the relationship between UX design, visual design, user research, and software engineering? Have they created a setting where they can work together effectively?
Are they focused on the user and the UX (rather than focused primarily on visual design or software engineering)?
You should also review the lessons from previous chapters and ask the vendor questions to discover whether they’ve learned those lessons too. The way the vendor proposes to manage uncertainty and the unknown in a project will be very telling. Vendors are accustomed to being asked to provide formal, documented processes and to pretend that uncertainty is minimal. But ask them about how they dealt with unknowns and changes in other projects and how they propose to manage scope so you can see whether they provide an honest, realistic point of view. If they don’t—if they tout their patented process as being universally and comprehensively effective, or if they put a great deal of emphasis on upfront requirements building and big design up front—then be wary. Vendors who use this approach tend to try to hold you, the client, at arm’s length in an effort to conceal the internal details of progress. That approach doesn’t allow your project to benefit from the wisdom available through the stakeholders and the project leader. It also prevents you from having a clear, unfiltered understanding of the state of the project. You also don’t have immediate control over its course as the inevitable unknowns and risks are encountered. This leads to surprise disappointments, budget overages, and change orders.
The ultimate goal for both your company and your vendor should be to create a strong working partnership that is built on mutual trust and respect. Your company gains that trust and respect by:
Being reasonable about the realities of uncertainty and the unknown
Being effectively supportive of the development process
Keeping focus on the high-level goals
Being clear-headed and passionate about the product you’re building
The vendor gains trust through transparency and a willingness to acknowledge and take responsibility for issues as they arise. It demonstrates its trust by allowing the project leader direct access to the project through development. If a vendor is resistant to this level of transparency, it may simply be because they have been burned in the past by clients who didn’t reciprocate that trust. But they should at least acknowledge it as a goal and be working toward it.
You should also examine the role of the vendor’s account management and project management. Good project management is crucial to:
On the other hand, project management and account management are often used as layers to obscure the internals of the project from the client, translating everything into periodic, heavily packaged, diplomatically presented abstractions. This is a product of the vendor’s experience working with clients who reacted poorly when presented with a direct view into the messy realities of a software project. So, again, although a certain amount of trust hasn’t yet been earned at the beginning of a project, both you and the vendor should strive to build mutual trust and develop a more tightly integrated relationship. When you’re trustworthy as a client and, resultantly, in tune with the project, the vendor won’t feel compelled to hide reality behind pretty packaging and diplomatic account management. This mutual respect improves the overall efficiency of the project.
A deep examination of the vendor’s portfolio of past work is also important. Portfolios—often represented as an impressive collection of logos of wellknown, ostensibly satisfied clients—should never be taken at face value. It’s important to gain a deeper understanding of what, exactly, the vendor’s role was in any given project. You may find that in their showcase projects, they provided only the design services, or only the software engineering services, or perhaps they consulted only at a minor level. You’re looking for a vendor with experience in bringing together all of the disciplines from UX design to software engineering, so the vendor should have several strong case studies of instances where they did just that.
It is possible to bring together the design services of one vendor with the software engineering services of another, but we’d strongly caution against it. This situation requires that trust be built amongst three parties instead of two. That trust can be difficult to build because the vendors will likely perceive themselves as being in a zero-sum battle for your budget. It also makes it significantly more difficult to create the setting of a unified, multidisciplinary team; rather, it creates a setting of segregated roles whereby the respective parties pass deliverables back and forth but don’t necessarily collaborate on anything. This is why full-service agencies, though generally more expensive and in high demand, are most often the best option.
Be wary of engaging agencies that are focused primarily on marketing and advertising. It’s often the case that if a project is part of a marketing or CX initiative, or if the product is web-based or has a strong online component, your company’s first impulse will be to work with whichever agency has helped with past marketing or web initiatives. When asked whether they’re capable of building the product, these agencies will almost invariably answer “yes”—whether it’s true or not. If they don’t already have the capability, they’ll see your project as an opportunity to build that capability on your dime.
Besides their basic inexperience, the problem here is that marketing and ad agencies approach these types of projects as websites on steroids, beefing up their web design and development staff and applying web solution strategies to the project. But there are enormous differences between websites and software. UX-focused software, as we’ve discussed, requires specialized resources in UX, visual design, and software engineering. Web design and development skills do not translate to software design and development capabilities. As well, the technical infrastructure and management practices required for a software project are vastly different than they are for web projects. An in-depth investigation of the qualifications of the agency’s resources and their contributions to their portfolio projects should reveal their true capabilities.
Also, it’s worth doing some digging to ensure that the company you’re hiring will actually be doing the work. Agencies that don’t currently have the in-house capability to build your product may simply hire a more specialized agency to do it on their behalf. In those cases, you’re needlessly paying a middleman. And an additional party in the middle of everything can only harm the unity of the team and the trusting, integrated working relationship that needs to be established.
The following are some additional questions you can ask of the agency you’re evaluating to see if they’ll be a good fit.
Full disclosure
Because EffectiveUI is a full-service agency and we’re essentially describing ourselves in this chapter, it’s important for us to acknowledge the risk that our recommendations in this section will seem self-serving. This was unavoidable—this book is a compendium of our views on the best practices in this domain, and we spend our days (and a few nights and weekends) using these practices in our work. For what it’s worth, it wasn’t our idea to write this book. We were asked to write it by our publisher, O’Reilly Media, because they noticed we had been delivering strong results in UX-focused engagements where other, ordinarily competent agencies had failed, so they wanted us to help you understand how we’ve been doing it. There are a number of independent research papers, mostly by Gartner and Forrester, that have helped inform our views and can provide impartial support for our assertions, particularly for this chapter. Unfortunately, we’re unable to quote or cite them directly in this book because they’re proprietary works.
We’ve taken great care to ensure that this book is the source of credible, accurate information and not just a big perfect-bound advertisement for EffectiveUI. If you’ve sought out this book for the full range of advice it provides, then you’re likely not in a position to hire a company like EffectiveUI anyway. You’re probably looking for a roadmap of how to do it on your own—and that’s precisely the information this book provides.
Get Effective UI now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
