Apply a project framework to a situation. Looking at the conflict through the rigid structure of a project lens, you can identify what you need to solve the problem.
Projects consist of goals, parameters, requirements, activities, and outputs. Defining elements yield schedules and assignments and risks and dependencies. Projects establish a framework for working together. Using a lens to look at a situation in terms of a project means distancing it from other potential influences like politics.
Know what aspects of design are hallmarks of your style.
Some design challenges will respond favorably to your style, but others will demand breaking the mould. For most designers, “style” is their go-to concept, the collection of patterns, tricks, and licks that they apply immediately to any design problem.
Leaning on your go-to concept as a way to break the ice makes sense, but good designers learn to recognize their crutches, and attempt to iterate past them. With each revision, the design should look less like yet another page in the designer’s portfolio and more like a real solution to the problem.
Team members lose focus of project objectives because they see something novel, and wonder how it might fit into their project. ”Shiny objects” is the favored term for ideas that have captured the imagination of the public or the industry. These ideas get a lot of play in industry press, and quickly make their way into design conversations:
"Why can’t our site be more like Apple’s?"
"What about a Twitter stream?"
"Our site needs social sharing functions."
Design decisions driven by what’s new, and not by what’s needed, are appealing because they’re easy to make. They’re not easy to implement or justify.
The effect: Project resources become diverted to exploring this great new thing, and not solving the core design problem.
The challenge: Team members may see the project as a failure if it doesn’t include the shiny new thing.
Members of the project team lose focus on project objectives because they are distracted by a competitor. This competitor may be outside the company, but is often inside the organization — a separate team working toward the same, overlapping, or competing objectives.
The effect: Project teams can’t operate efficiently because resources are diverted to “deal with” the competition.
The challenge: In design, a better product is the best way to beat the competition, especially when other aspects of the situation are beyond the team’s control (eg: office politics). Human behavior, however, prioritizes undermining the competition. It can be difficult to deal with this situation when our survival instinct kicks in, and team members become transfixed by arguing why the other guy is inferior, and not on investing in making their own product better.
Know what format and structure for peer reviews helps you the most.
For some designers, the peer review is a great opportunity to get feedback on initial concepts and ideas. In these conversations, the designers hash out the design direction, ignoring details and ensuring they’ve solved the core problem.
For others, designers lean on peer reviews to help flesh out the details of a well-articulated concept. In these conversations, the designers compare the design direction to the requirements and constraints, ensuring that they haven’t violated any of the project parameters.
Your agenda might focus on refining the concept itself, getting feedback on your design decisions. What you might find more helpful is working with peers to refine your presentation of the concept and practice facilitating the discussion about it.
Knowing what kind of peer review helps you most, you can set the expectations of your peers. You want to avoid taking your colleagues by surprise with a detailed design, when they might be expecting something less mature.
Know what it takes to bring out your best design work.
For some designers, the trigger is a relatively low bar: simply putting a design challenge in front of them is enough to start the creative process. For others, they need to reach a tipping point. The higher that point, the more energy it will take to get to get the best design work.
One high bar is total project failure. In this case, the designer needs to confront the ultimate brink — the risk of the project going away — before bringing out top-shelf design skills.
Triggers can be people (working with your favorite colleagues), situations (working on certain types of products), activities (incorporating user research).
Product teams may create early mock-ups to frame the problem, which locks them into a particular mindset.
In design, too much preparation leaves no room for innovation. By over-preparation, I mean walking into a situation where the design team has thought so much about the problem, and relied so much on pre-existing assets, they can’t think about the problem independently of their initial solution.
The effect: Good design strategy takes the design just far enough to validate the objectives and constraints, and establish an overall direction. When a design concept lingers too long, becoming entrenched, it can cause conflict because some team members may be unwilling to go.
The challenge: Overcoming this situation is hard because people tend to prefer familiarity. They may feel a sense of ownership of the design concept and be reluctant to let it go.
Despite their best efforts, project teams may not be able to articulate a single clear design problem. While it’s unnecessary for a client to have a fully-fledged assignment at the outset, the design team should be able to state the design problem confidently after at least one discussion. By the time the project is underway, every member of the design team should be able to summarize the objectives and scope of the project.
The effect: Without a clear definition of the design problem, the project team may run in different directions. Conflict comes from each member of the team evaluating design directions with a different set of criteria.
The challenge: Articulating the design problem is perhaps the hardest thing to do in design. Establishing goals and parameters feel very “un-design” to a designer. These efforts, while potentially unpleasant, yield better results because they let the team know what success is.
Know how good you are at hearing the need and defining the core design problem.
Design problems come in translucent packages: sometimes it’s hard to see what the real challenge is. Product owners surround the design problem with extraneous and distracting data that may not directly contribute to the solution.
Sometimes the package is plastered with too much relevant information, which also serves as a distraction from solving the problem.
Some people are great at cutting through the packaging to elicit a clear assignment. Some need time to sort through the packaging. Still others need to pursue a few different solutions before the problem becomes clear.
Know how quickly you like to work.
Designers work to a rhythm. Some are moderate, where designers appreciate the distinct swings between doing design and doing reviews. Their unit of choice for measuring time is the week, giving themselves time to noodle on a concept and zero-in on an approach. A week gives reviewers enough time to balance their responsibilities between this project and others.
Others prefer an up-tempo approach, iterating daily or even hourly. They prefer to hold informal conversations around design. They can render new design concepts quickly, and talk their way around holes in their deliverables.