Putting together a killer team
Let’s get one thing out of the way: creating a market leading digital product is not easy! There is a lot that can go wrong and even more you need to get right.
Putting together a team that can consistently deliver on their promises is one of those things you need to get right. The other day I got asked the question: “What is your ideal team?” My first answer was: “That depends…”, which is the correct answer to many design questions.
But, it got me thinking and so I decided to expand on this important issue. Is there such a thing as “the ideal team”?
Well, yes and no… let’s have a look at this in more detail.
What is your ideal team?
Let’s establish a few parameters here.
First of all, I do not believe there is such a thing as “the ideal team”. There is, however, “an ideal team to solve the problem at hand”.
Does this mean you need to put together a new team for every problem? Of course not, that would not be practical. The core of your team should be stable. As stable as possible. Every change to the core of your team is a ripple; a ripple with consequences. We will look at some of the core positions later in this post.
But every team should have room for a couple of subject experts whenever needed. Temporary members with expertise on the problem the team is trying to solve. They add value to the team for this specific problem only.
Second, I am talking about the “design team” here. It is important to understand that the design team is only a small subset of a much larger group responsible for the product. Stakeholders from other disciplines, like marketing, sales, engineering, etc., are logical components as well.
Just throwing together a group of smart people with fancy titles won’t do the trick. Consistently successful teams have a set of clearly defined roles that work together well and complement one another. Effective teams always keep their goal in clear sight, regardless of process and methodology, and they ensure their decisions are effective and of high quality by only involving those who are necessary to make these decisions.
The right mix of people can accomplish more in less time and with better quality.
The Design Team
The design team conducts design research with potential users and customers, identifies behavioral patterns, needs and goals based on that research, and develops the form and behavior of the solution that will address those needs and goals within the set constraints.
The ideal design team is small enough to keep communications efficient, but large enough to have every needed skillset on board.
The core team is most effective when members are the same from initial research all the way through implementation. There is no need for skillsets to overlap. What is important is that team members share a common language and an overall method.
When we look, as an example, at Scrum Process Management we see that a team is multi-disciplinary. Team members are so-called T-shaped and not M-shaped. T-shaped employees have deep knowledge on one subject matter and a broad knowledge on the other required subjects. M-shaped employees have deep knowledge on multiple fields; this is not a requirement for Scrum team members and it can actually hurt the team’s effectiveness.
This is something to take notice off. When hiring staff it might look smart to hire people who can contribute in multiple fields and there are many books available who state just that: “The employee of the future is an expert in everything he or she does!” But ask yourself two things:
- How feasible is this? How realistic is it for one person to become and remain an expert in multiple fields? And how social will that person be?
- When we put people together in a team, and they all think they are there to be the expert in a certain area, how well will that go?
When we look at the methodology of Scrum, we deal with so-called Sprints. At the beginning of each Sprint the team determines what they will take on during a Sprint Planning session. For this the team uses its “velocity”, a number that becomes reliable after 8 – 12 sprints. With sprints lasting 2 weeks, this means a sprint team will know its velocity after 4 to 6 months.
Knowing this we can understand why agile teams slapped together with free-lancers for 6 month projects are not very successful. They just don’t get a fair chance to perform well and are split-up before their performance can be measured properly. We can also understand why “pilot projects to test the scrum methodology” lasting a few months also suffer the same fate; afterwards scrum is tossed aside by management as not working.
Taking care of your core members and keeping them happy within the team will pay dividend in the long run.
The core members of the design team are:
- The Product Owner.
- The Scrum Master.
- The Interaction Designer.
- The Visual Interface Designer.
- The Industrial Designer.
The Product Owner
The product owner is the linking pin to the outside world for the design team. He or she must be the ambassador of the product’s vision and roadmap.
It is not easy to build momentum and convince people to take risks in a team-driven environment. There must be someone who makes the final call if there is doubt on which direction to take. The product owner should know, maintain and collect the needs and goals from all stakeholders. Collecting this information should be done in collaboration with team experts whenever necessary, but ultimately he or she is accountable for the final destination and priorities set.
Being a good project owner is not easy. You should provide direction, but not lead. The team should have freedom to be self organizing as much as possible. As a product owner you are their connection to every stakeholder. This means you should be available to the team at all times. It is important that you are receptive and willing to champion design and be comfortable with the design process, because you will be the one who reviews rough work in progress before it is shown to the stakeholders. This helps refine the work, but also the way you express it.
If a product owner is simply passing on direction provided by the executives, the team will need to identify and get close to the real project owner. You cannot be effective as a team when decisions made by your product owner are frequently overturned by people in the shadows.
The Scrum Master
This must be one of the most misunderstood roles around. I have seen my fair share of Scrum Masters who were between a rock and a hard place because their management did not have a clue about their role. Yet, I will be brief here, the Scrum Master should:
- Remove impediments and facilitate the scrum team in decision making.
- Fully understand Scrum, and coach the team.
- Ensure that scrum practices are used properly.
- Be a servant leader for the team, no manager.
- Help the Product Owner, by helping or consulting them on finding techniques, communicating information, and facilitating related events.
- Be the ambassador in- & outside the team.
- Be the enhancer of the value created by the Scrum team.
- Be a full time job and a single role.
They are not project managers, they should not be responsible for having cookies in the meeting room, and in most cases they should not be envied!
Recently I saw a job application for a Product Owner / Scrum Master / Project Manager all in one. Yeah, that’s going to be a success.
The Interaction Designer
All design professions require a similar foundation: the ability and will to visualize solutions in concrete terms.
Interaction design requires the same skill. But, interaction design includes a characteristic not shared by the other design disciplines and therefore requires an additional ability; to think in terms of system flow. As a key part of that system most likely is human, it also requires an understanding of the goals and thought processes of “typical humans” who will be using the system.
This combination of human understanding and system flow is the story, or narrative, of the design.
A good interaction designer (IxD) is always curious about how things work and why they work the way they work. He or she will always be interested in how easy something is to use for people. Interaction designers should have a general knowledge of what various technologies are capable of, but should be able to rely on engineers, programmers and the like for detailed knowledge and implementation.
The visualization of system behavior is one assignment for the interaction designer. This means deliverables like:
- Information architecture charts.
- Labeling and navigational structures.
- User flows.
- Experience maps.
- Wireframes.
- etc. etc.
Visualization skill is usually for people with a certain amount of confidence. It takes faith in one’s own judgement to put rough ideas out in the open for criticism. However, this faith must be teamed with a willingness to listen to others and hear why you might be wrong.
Apart from visualization, there also will be a need for documentation. This has become a bad word in many a design team, but I still feel this is a required skill for an interaction designer. Communicating about design requires the ability to organize and prioritize ideas in such a way that it can be presented to your audience in a coherent, concise and persuasive narrative.
Collaboration skills and empathy are very important in interaction design. Communication skills are critical. An interaction designer must present work with a convincing rationale to any stakeholder.
Just to be clear: in most teams my role will be that of Interaction Designer.
The Visual Interface Designer
The visual designer is responsible that the visual representation of the system effectively communicates the data and provides clues to the expected behavior of the product. At the same time he or she should visualize the brand’s ideals, message and positive impressions.
Essentially, the visual designer must aim for maximum usability, combined with maximum desirability.
Visual designers (VisD) also play an important, albeit less obvious, role in the interaction design. While the IxD can identify flaws in system behavior by thinking through how to explain something, a VisD can identify flaws by thinking about how things will look on screen. If a particular flow, behavior or set of on-screen relationships is difficult to render in pixel design, that is a warning that the design is not as clear as it should be.
Because the VisD is trying to develop a visual system that has as few elements as possible, he or she usually is good in spotting unnecessary inconsistencies. The VisD may also spot problems when doing animations to demonstrate particular interactions.
The visual designer must be able to steer stakeholders away from purely subjective preferences, which are even more of an issue for design language than they are for behavior.
Visual interface design is not the same as graphic design. Digital design involves lower resolutions. It requires an understanding of usability principles, such as how to determine the size of a click target. It also emphasizes function over form; brand expression is certainly secondary in application design. Visual design differs significantly between websites and applications; it might take two different designers altogether.
The Industrial Designer
An industrial designer (ID) is responsible for designing hardware that is ergonomically and environmentally appropriate, aesthetically pleasing, and cost effective to make.
ID participation in stakeholder discussions and some of the user research is essential. Ideally the ID is present to extract the right information and provide any “translation” the design team needs.
The ID works closely with the IxD on the form factor and interaction framework. Collaboration with the VisD is also required to come to a coherent design language.
In conclusion
The above team positions are just the core of the design team.
Additional members, full-time or part-time, might include:
- software engineers,
- mechanical engineers,
- electrical engineers,
- business analysts,
- system analysts,
- content specialists,
- SEO specialists,
- usability testers,
- subject matter experts.
I cannot stress the importance of that last one enough. When a design team needs to develop an app for mortgage management, assign a mortgage specialist to the team. If we need to develop an app to be used by oncologists… well, you get the idea.
Of course, all of the above paints a perfect picture. Sometimes, however, we don’t live in a perfect world.
Design by committee is a well-known danger for design teams. In risk-averse environments, committees are “safe” because no one is to blame when things go south. Committees may also be motivated by a consensus ethic, which is common in academia and health care. If a committee has a specified chairperson with authority, it makes sense to consider that person your product owner.
If there is no clear leadership at all, things are more problematic. Find a person to lean on for advice and support. Find someone who is open minded towards design. Find someone who has leadership qualities. At first ask this person to support you informally; meet from time to time and ask his or her opinion on how to best present a conclusion or idea to the group.
If your meetings with engineers or experts are too large, or if too many stakeholders who have nothing useful to say at a particular meeting insist on attending, you have a problem too. There is no simple solution to this. It involves educating your stakeholders, trust building, developing processes for good design and frankly some good old fashioned political maneuvering to keep things going. Nobody ever said it was going to be easy…
Until next time!
