Examining Structure & Roles

At Myplanet, we’ve explored both ends of the spectrum when it comes to adopting the roles that Agile (and in particular, Scrum) prescribes.

For example, certain team members have experimented with limiting themselves to predefined Scrum responsibilities, while others have worn more hats than can fit on one determined head (aside: you can fit more than one, but probably fewer than ten). We’re definitely not finished with our iteration on roles, but we have discovered certain unique positions and helpful team structures that can benefit a professional services user experience project. This part in the Process Bricolageseries argues that in a professional services engagement, UX design should be a shared responsibility spread across team members with necessarily unique skill sets. To support this notion, I examine the integration of traditional and non-traditional Agile roles—in particular, Product Owner, Creative Rep, and UX specialist—in to the UX design and build process.

Of course, any examination of roles requires some context on organizational structure (don’t worry, I’ll keep it brief). At Myplanet, we’ve embraced a mainly flat “startup within a startup” structure. In short, this positions Myplanet as a pseudo-incubator with relatively autonomous project teams who handle the majority of production work. These teams draw on a pool of specialists and directors who provide surgical-strike-like assistance and support for key elements of our work.


While we’ve never siloed ourselves by discipline—we have no ‘design’ phase since design is an activity that transcends any particular project phase—at one point we did have a specialist-team divide. Specialists would engage in early phases of our process (Discovery, Research, Definition) and hand over the output to the teams to extend and build out during our Implementation phase. However, the loss of context here was problematic. Currently, we’re moving rapidly towards a model that gets the teams involved in and owning the project at earlier phases. This shift requires every team member to have both a broader understanding and increased interest in UX design.

At Myplanet, we’ve embraced a mainly flat “startup within a startup” structure. In short, this positions Myplanet as a pseudo-incubator with relatively autonomous project teams who handle the majority of production work.


In an Agile context, this is all kosher. Agile is focused on the team as a unit, and collaboration, cross-learning, and the fully-skilled team member are all desired outcomes. The notion that the team, rather than the design hero, can best support UX design is also ubiquitous in the process community. Jeff Gothelf’s exposition on the merits of team-based UX design in a Lean UX framework, Jared Spool’s ongoing interviews and articles related to the power of the team, a particularly poignant Cooper article, and even Ethan Marcotte’s brief description of his own team’s iterative responsive design process in Responsive Web Design are only a few examples.

Beyond the Agile rhetoric, our own early experiences with semi-siloed disciplines has motivated us to move towards a one-for-all, all-for-one approach: “Sure, interaction principles supported that decision, but how did esoteric technical limitations come into play? Oh, we didn’t consider that early on? Uh oh...” Given the spectrum of skills necessary to complete a comprehensive UX project, where work ranges from aesthetic visual language choices to hardcore computer science stuff, we’ve realized it’s ultimately impossible for a single designer to gain sufficient insight in a tight timeframe to make sweeping decisions for the project as a whole. By embracing collaborative structures from various disciplines—like industrial design and architecture-bornedesign studios—we bring together a variety of perspectives to solve design problems.

However, where Agilists might aim to spread that broader insight across the team, we believe the strength of the team lies in its diversity, and that some divide in skill sets is actually beneficial. By sheer limit of waking hours, a single team member can only learn so much. The level of generalization necessary to own everything on a full-service team—a huge breadth of responsibilities, from aesthetics to front-end to back-end—would drastically reduce the time available to get really good at creating part of the UX product. We need people who are amazing artists working alongside super astute mathematicians (so to speak). In a software development environment, the Agile jack-of-all-trades types might make sense, but in the context of user experience, we can’t afford a team of masters-of-none.

In short, these needs mean we must actively create roles that are still specialized—but not compartmentalized. At UX Immersion 2012, Jared Spool’s keynote focused heavily on the differences between these two types of roles, and I couldn’t agree more. There is a fundamental difference between a doctor who specializes in operating on wrists and still delivers babies, and one who refuses to do anything else:


And the thing is to be a doctor in Massachusetts he has to continue to take doctor classes which involve things like how to conduct a C-section. He has to learn how to do things which are not just hands and wrists to keep his license as a doctor, as a surgical doctor. If he were the only doctor on the island, he’s the dude you would want to deliver the baby because he’s the guy. So even though he’s a specialist, he knows how to be a doctor. He knows how to do doctoring things that aren’t related to his specialty... There’s a difference between being a specialist and being a compartmentalist, someone who can only do one thing, and as soon as anything else comes at them, they have to say, ‘Whoa, whoa, whoa. That’s outside my field. I can’t do that.’”


We encourage everyone to engage with everything, but only to a level where they can still preserve time to specialize. While a ‘pure’ Agile team might idealize the generalist—the individual who can take on any task—our teams revere the T-shaped individual. So, where a traditional scrum team might identify only the Scrummaster and Product Owner by role, we’ve added a Tech and Creative Rep. What do these roles look like for our UX proservices and how do they share in the process of UX design?

Product Owner

  • The Product Owner has traditionally been the business analyst and keeper of the backlog. He or she is heavily involved in communication surrounding the product, translating the needs of the team to stakeholders and vice-versa. In the context of proservices, where the client is an external, third party, the Product Owner has the challenging role of ongoing education. We frequently work with clients new to Agile, and we must consistently and clearly identify the benefits of our process and the rationale for certain rules. But because we create UX products, the PO needs to have a good handle on the ways our process supports user-centered design.
  • The Product Owner must also work with the client to win approval and buy-in from the client’s stakeholders and superiors. Equipping our immediate client with the tools and insight to make a case and ‘manage up’ is critical to carrying our UX vision through to completion. And in this respect, the Product Owner must have a thorough understanding of the vision and experience criteria for the project.
  • Finally, there’s this role called the UX strategist that’s recently entered our industry. There’s not much agreement on what exactly this role entails, but we do know our Product Owners are part UX strategist. By translating raw research to comprehensible recommendations, helping the client reprioritize goals in their backlog according to user need, and supporting the broad product vision, the Product Owner is very much actively influencing the outcome of the UX undertaking. Of course, the PO needs specialized support when it comes to design and technology, and that’s where our reps come in.

Creative Rep

  • The Creative Rep is, quite literally, the representative for design. Part user advocate, part proxy for the creative director, the Creative Rep is responsible for creating and driving the creative vision of the project, ensuring quality of product, and supporting the Product Owner in communicating the rationale for design work to the external client. As a representative, the person who occupies this role is elected by the team, meaning anyone with the right skill set could move into the role. (It’s just like high school student council all over again!)
  • The Creative Rep is also active in story completion, responsible for extending the design system to accommodate the user needs slotted for the sprint. Of course, anyone can take on a design task from a story in the backlog. We try to encourage our development-oriented team members to do so, in which case the Creative Rep becomes a mentor to help guide this work.
  • The CR is concerned with usability testing. He or she performs both short and long-form user testing to help improve our UX systems throughout the project. And, where possible, the CR reviews functionality as part of quality control and user acceptance testing.
  • Altogether, the CR is a generalist within the boundaries of the design specialty. The CR should also have a solid handle on core front-end development concepts to inform their interactive work, but we don’t expect our CRs to generalize outside of design (no C# necessary).


  • Where necessary, we temporarily augment our teams with specialists who focus heavily on a particular area of their discipline. For example, we have specialists focused on interaction design, visual-interactive design, content strategy, and devops. Teams can call upon these guns-for-hire to execute on a particular step (for example, producing art boards or running a design studio); conversely, we encourage our specialists to stick their noses in wherever possible to help critique the product.
  • Specialists are also responsible for distributing knowledge of their craft throughout the teams, working closely with the Creative Rep to build his or her expertise. It’s the work-yourself-out-of-a-job mandate that all mentors strive for, and its critical to evenly improving the calibre of our teams.
  • When considering the often finial budgets of a professional services engagement, maintaining a pool of specialists gives us the ability to provide very focused expertise where it is needed, without creating the overhead of a team member whose extreme focus will limit them from having work to do at all points during a project. Of course, we’re striving for a balance here: the ominous “utilization” question looms over Kevin, our Ops Director, who needs to make the numbers work. But we also understand that giving ourselves slack time — not idle time — is critical to being creative, and so downtime for specialists to pursue tangents related to their craft is something we want to preserve.

Technical Rep, Scrum master, Front-end Dev, Back-end Dev

  • The PO, CR, and specialists play a major role in defining and designing our user experience products, but they’d be nowhere without the ongoing support of technical minds on their teams. As mentioned, a true UX engagement requires insight from both sides of the brain, and we encourage our technical types to participate in design-focused tasks from visioning to design studios to visual quality control. Check out Yashar’s article on the Tech Rep to learn more about these roles.

Conclusion: Balancing empathy & expertise

One of the greatest intangible benefits that comes from mixing a respect for individual specialties with the collaborative impetus of Agile is a balance of empathy and expertise. Regardless of the operational or utilization benefits, more individuals involved in more aspects of a project leads to greater understanding and empathy for the various disciplines. This shared understanding can become surprisingly rare when design, development, and business roles are highly separated or siloed.

At the same time, we avoid dilution and design-by-committee, encouraging ourselves to focus, position ourselves as leaders for a particular practice area on our teams, and take ownership over different aspects of our projects.

The shared-but-not-too-shared-responsibility model works well for our engagements, where the complexities of full-service user experience (from designing to building), external stakeholders, and operational or budget limitations come into play. Of course, we wouldn’t be true process bricoleurs if we didn’t constantly encourage iteration or manipulation of the approach where it makes sense, so we’re constantly looking for new ways to experiment with our roles. How do roles work in your Agile organization?

For an introduction to our "How We Work" series, read Part 1: Making The Case for Bricolage.

Sign up for our newsletter