Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

How To Build An Agile UX Team: The Culture

This is the first in a three-part series on how to build and grow successful user experience teams in agile environments1. It covers challenges related to organization, hiring and integration that plague UX teams in these situations. The perspective is that of a team leader, but the tactics described can be applied to multiple levels in an organization.

Building any kind of agile team is a lengthy and challenging process. Building a user experience team within an agile organization challenges not only traditional design practices but typical design team dynamics.

Further Reading on SmashingMag: Link2

In this first part, we’ll look at the type of culture that would support a strong UX component in the agile process and how to structure the organization so that designers are most effective and are able to thrive.

Organizations Become Supportive Through Dialogue Link

Agile Culture7
Teams work together to celebrate their wins at weekly team-wide demos.

Critical to the success of any user experience team is an organization that values its contribution. This is not unique to agile shops, but it becomes even more critical given agile’s rapid cycle and participatory rituals. In a typical resource-allocation scenario, no more than one UX designer is assigned to a cross-functional (i.e. scrum8) team. In fact, this scenario is usually optimistic. In some cases, a UX designer will be straddling more than one team. “Team” is the core concept of the agile philosophy, and as such it must include the designer as a core member.

Development managers need to set the expectation with their staff that design is critical to the team’s success. As you begin to build your UX practice in this environment, ensure that you have frequent conversations with these managers to review how their staffs are reacting to the addition of designers to their teams. These conversations will help anticipate issues that may hinder the cohesion of the scrum team. In addition, lessons from fixing one of these issues can be applied pre-emptively on other teams.

By the same token, it is incumbent on the UX designer, their corporate champion and team leader or builder to promote the values of the craft in the organization. Again, this is not unique to agile environments, but it is critical to keeping the team focused on core UX and design issues. Key to this promotion is transparency. Let the team into the designer’s world. Let them see what they do and how they do it, and let them experience the benefits that come from doing UX and design work. When all members of a cross-functional team can articulate the benefits of design activities such as,

  • speaking with customers,
  • understanding the business and competitive landscapes,
  • constructing the information hierarchy,
  • assessing visual communication,

then they will be far more inclined to carve out time for those activities in each iteration. Include the team in the actual design exercises. By practicing participatory design, the designer’s contribution will become evident, building their credibility and crystallizing team cohesion.

How To Structure The UX Team Link

Organizationally, there are essentially two ways to structure the UX team: as an internal agency of shared resources or by using a hub and spoke9 approach, with designers dedicated to specific teams.

Internal Agency Approach Link

Using the internal agency approach, incoming work is routed through a central point of contact (typically the UX manager) and then assigned to the designer who is best suited to the work and who has the bandwidth to take it on. The challenge with this approach is two-fold.

First, it promotes a culture of specialization in which designers limit their contribution to particular segments of the craft (for example, mobile, e-commerce, social experience design, etc.). Secondly, with no loyalty to the scrum team, priorities become driven by which product owner can yell the loudest, typically leaving the designer in the middle, awaiting the outcome to know where to focus. Additionally, this approach taxes the UX manager heavily by forcing them to constantly assess bandwidth, availability and applicability of skills to the required tasks, all while helping the product owners manage competing needs among the design staff.

Hub and Spoke Model Link

The hub and spoke model, on the other hand, is the better practice. Dedicate each designer exclusively to one particular scrum team. They should feel like they are a part of their scrum team and feel connected to that team’s focus. In doing so, the designer’s priorities become clear. Their priorities are synonymous with the team’s, thus enabling them to clearly understand where to expend their energy.

Asking for a designer’s input or effort on a “quick” project or “internal need” is a fairly common occurrence in many companies. It is incumbent on your organization’s leadership to protect the one designer or team structure, so that each team’s designer isn’t peppered with these ad hoc requests. Such requests distract the designer from their team’s mission and inevitably consume already limited capacity. In the eyes of the designer’s teammates, these efforts erode any progress that has been made in confirming the designer’s permanence on the team.

Working With The New Teams Link

New ways of working for designers will, at first, be uncomfortable. For many design managers, assigning their staff to particular teams brings a new challenge. No longer does the design manager dole out specific work to each person on the team. Instead, the designer’s daily agenda is driven by the prioritized backlog of the scrum team. This is a duty that managers were likely used to doing in the past, and its removal may feel like a reduction in responsibility and authority. To fill this potential void, design managers should work with their staff to understand their team’s priorities and suggest methods of structuring the work in a way that allows the best user experience to get built.

Weekly one-on-one meetings with each designer should reveal any challenges unique to their situation. In addition, regular touch points with each team’s product owner will provide insight into any design challenges on the horizon. And monthly high-level retrospective meetings become a forum for managers to share successful and failed tactics across the organization. With all of these tactics in place, the driving goal should be to solidify the designer’s place on each team.

Dedicating your staff to other teams does not portend the doom of the centralized user experience team. The centralized team is still very much needed for mentorship, professional development and general design support (such as critiques). In addition, a centralized UX practice can bring learning from the individual scrum teams back to the broader group, disseminating lessons that improve the process elsewhere.

The centralized UX team also serves as a “safe haven” for designers to vent their frustrations with the agile process, commiserate a bit with their colleagues and reassure themselves that they’re not alone in their agile UX challenges. Weekly UX team meetings are the building blocks of this community. Outings to design events, talks and recreational events help solidify the bond between distributed designers. A UX-only email distribution list or other forum could also provide this safe haven on an as-needed basis and supplement discussion outside of the regular meetings.

Conclusion Link

Company culture and staff organization are the two fundamental building blocks of agile and UX integration. By creating an environment that values design, promotes its benefits and spreads this gospel through the allocation of UX resources across individual teams, companies will lay the foundation for successful team-building and adoption of the agile process down the road.

In part 210, we’ll discuss why hiring is such a critical part of the agile UX team’s success and how to maximize your chances of hiring the most appropriate staff.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10

↑ Back to top Tweet itShare on Facebook

Jeff Gothelf is Neo's lean evangelist, spreading the gospel of great team collaboration, product innovation and evidence-based decision making.
Jeff is a speaker and thought leader on the future of user experience design, often teaching workshops or giving talks on building cultures that support teamwork and innovation. Jeff is passionate about advancing the principles that lie at the core of Neo, and often does so on a global scale.
Prior to joining Neo, Jeff lead the UX design teams at TheLadders and Web Trends. Earlier he worked with and lead small teams of software designers at AOL. He is the co-author (with Josh Seiden) of “Lean UX: Applying Lean Principles to Improve User Experience.”

  1. 1

    A key to success for any Agile or Scrum team is dedicated resources–be it a PM, developer, product owner, trainer, etc.

    The challenge for an Agile team is often how to incorporate UX. I like what you said about “the designer’s daily agenda is driven by the prioritized backlog.” This is exactly how you plug UX into Agile/Scrum teams for two reasons:

  2. 2

    I like what you said about “the designer’s daily agenda is driven by the prioritized backlog.” This is exactly how I have plugged UX into Agile/Scrum teams. In my opinion, this provides two benefits:

    1. Allows designer to know the end product and understand the big picture. While UI may evolve sprint to sprint–developers, product owners, PM’s and BA’s can see where the app is going at all times and can always discuss level of effort when building specific features in the current and next sprint.

    2. Working off the product backlog allows UX’ers in Agile teams to estimate their work and be assigned points to each sprint. From my experience, the heavy lifting UX with info arch, design concepts, wire frames, etc are done in iteration zero. By having points per iteration you are part of the deliverable; therefore, you are part of the project.

    Looking forward to parts 2 and 3.


    • 3

      Hi Jason,

      Re: “From my experience, the heavy lifting UX with info arch, design concepts, wire frames, etc are done in iteration zero.”

      We recently integrated designers into specific teams and found exactly this. The problem that followed was that there wasn’t enough work to fill the sprints going forward which resulted in designers requesting additional work (outside the project) which made them a non-dedicated resource as additional work obviously has commitments. Do you have any experience of this situation?

      • 4

        We try to minimize the amount of work our designers do up front. The general rule is “if it’s not on the backlog, don’t work on it.” Now, this doesn’t guarantee that work will get built and launched but it gives it a greater shot.

        We also try to do as much parallel path design/dev as possible to keep everyone focused on the same things at the same time. We do this with light sketching, conversation and iterative refinement of the designs.

        It works most of the time. :-)


        • 5

          I completely agree, the work done upfront should be just the minimum needed to get an idea of the big picture.. anything more than that is potentially wasted effort as its at the mercy of changing requirements. Real IA work (eg. domain modelling), upfront.. things like wireframing I’d expect to be done within sprints.

      • 6


        It really comes down to how well your teams can self organize and collaborate.

        I like Jeff’s approach regarding “parallel design/dev to keep everyone focused on the same things at the same time.” I think this works well for projects that have regular releases–demo or production.

        In my world, we try to get as much design up front because there are definitive iterations with little future releases planned (this is more iterative dev than agile). By doing most of the heavy design work upfront I notice it helps dev with estimating points for the next iterations and helps product owners prioritize functionality that will deliver real value. Yes, in these cases typically design work tappers off the deeper we go into the iteration plan–allowing my limited design resources to go work on something else. However, I always have some points per iteration for wireframing/designing or usability testing on what was built in the previous iteration.


  3. 7

    Hey Jeff, thanks for this reading. Really looking forward to the next two posts. However, I have question that I’ve faced myself with while dealing with agile teams including designers. Given a shorter sprint of say two weeks, how do you prioritize tasks for the front end developers in order not to wait until the designer finishes their first part of work, and what does the designer do while he awaits for the implementation to happen (assuming the sprint is ending, and he’s accomplished all the design tasks)?

    • 8

      easy, stagger the sprints, agile is really just a squence of mini waterfalls. So a realistic sprint goal might be to get PSDs of something finished, not complete that feature from initial concept to live on the site.

      autodesk produced a brilliant document on how staggering and front-loading works for them –

    • 9

      In my experience a great deal of design work can be done in what’s called iteration zero. This iteration technically doesn’t have to be a two week sprint. It’s basically the pre work needed to begin development–environment set up, wire frames, IA, UI concepts, etc.

      Before an agile project starts, there is a product backlog containing all the features of the app. Use this to create the apps complete UI, with the understanding that some or all of it will change as the project moves deeper into dev.

      As you proceed through the iteration plan, always assign points to your tasks. But the real key is to always work an iteration ahead of developers. For example, if the project is in iteration 2, dev is coding stories prioritized for iteration 2 and designers should be creating UI’s for stories prioritized in iteration 3. Once iteration 3 begins, dev team has what they need and business has agreed to the design (or at least should have).

      Happy to provide more detail DM me @jgthomp.

    • 10

      Hi Cristi –

      We try to developer/designer pairing as often as possible so that designs are created, in code, in real time. This helps keep everyone focused on the same problems at the same time.

      Typically, towards the end of the iteration our designers are doing acceptance testing and experience validation (end to end reviews) prior to launch. They also do start thinking about the next iteration but very little design actually gets done in advance.

      Our goal is to get the teams working as much as possible in a parallel path. It helps keep everyone focused on the same issues at the same time.


      • 11

        First of all, thanks for addressing this issue. I appreciate Christi for raising an important issue. I have seen the same issue in few projects I’ve worked on.

        In my experience, a developer and a designer pairing to develop a software will lead to a lot of frustration. The best practice is to assign a single designer to a team. If so, can a designer pair with five or six developers in a team who attempt different user stories in a two weeks iteration? This lead to a lot of frustration, the designer is over used. This type of pairing will kill the user experience. I have seen the developers bringing ideas to control the UI.

        Let us leave the idea of a designer pairing with a developer. The developer will develop the UI based on the design provided by the designer. In a two weeks iteration, a designer who starts on new user stories will take at least five days to come up with design. Will the front end developers wait until the design is approved? This is what Christi also raised. Now add to this problem, the complexity of the user story. Take an engineering application which needs research. The designers need to go to the developers to clarify doubts and this will go iterative and on the code cut off date, you have a half baked UI.

        I’m going to disagree with Jeff on few issues. The first one is that the UX iteration and the development iteration can go parallel to each other. This will be a failure in my opinion. May be this will work if the application UI is simple like adding few buttons or images. This will not work for complex applications like engineering.

        Secondly, upfront design is a successful approach. It can be done via “iteration 0”. Whether the project is simple or complex, this will work.

        • 12

          @Varghese, I’ll second you on that UX iteration and the development iteration going parallel may cause a failure. It seems that everyone is leaning towards agile method here. Yes it is new and effective, but there is still a frontier for agile doing a great job. Agile development promotes minimum planning including user research, marketing analysis and IA up front — I think that has to be based on the fact that you’ve been very certain about your business objective and user requirements, so you actually have got a big UX model upfront in your mind, and in the following iterations the UX work will generate micro changes. Otherwise, if it’s a big project, the product idea is still very rough and you’ve done little to understand your market, the dedication into iterations could be a waste of time, because the developers may find they worked day and night to release something very cool but not favored by the intended users. There are true stories like this.
          In a nutshell, I think when to use agile method depends on the nature of a project, and as a UX designer, I hope to see more thinking about how to fit user centric design into the agile trend. Thx.

  4. 13

    I think if I hear the word ‘agile’ associated with web design again I’m going to vomit – flavour of the month? Time for a new buzzword. :)

    • 14


    • 15

      Agile is a very successful way of achieving consistent work-streams across all groups in a project. I’ve worked for companies on both sides of the fence and those working within agile have always produced better and quicker results.

      I don’t feel it should be regarded as a “buzzword” because a lot of companies are running a lot smoother because of it…

    • 16

      It’s not a buzzword, it’s the name of a framework.

      • 17

        .. a framework that has been in consistent use for 10 years across a number of industries. That’s hardly ‘buzzword’ territory.

      • 18

        It’s actually not a framework, it’s more of a methodology in my mind.

        • 19

          Not quite! There are methodologies involved, things like scrum, kanban, extreme programming and so on. Agile is a framework and as such doesn’t tell you anything at all about what specific methods or techniques to use, it is just a set of overarching principles & values that the various different methodologies work within.

          • 20

            @ Ian,

            I politely disagree with your comment that it’s a framework. In my mind I agree with Dave that it’s a methodology. A framework has to have specific schemes and arrangements. Agile does not, to your point. It does not dictate HOW you should do something but a philosophy of a goal. Not how to achieve that goal.

            Our company loves to do Agile. We use it’s positives as a selling point. My UX group in the company has had to deal with Agile methodology and we’ve come to a number of eye opening conclusions.

            I’ve tried to take months of discussions and distill it down to a simple graphic on how to do UX in an Agile environment. Unfortunately I have not had time to expand it with the explanation of the graphic, which is a travesty.

            But we align with Jeff’s article — which I identify with strongly — and our diagram echoes his sentiments about parallel processing. We just recommend staying a sprint ahead when you’re working with dev.

            See this page for the diagram. Click on the diagram to get a larger image:

  5. 21

    Interesting article, definitely a subject I was hoping to read on.

    Last week I attended the 2011 Agile 3-day conference in Buenos Aires, which I really enjoyed since I changed from waterfall to agile methods not long ago and I’m eager to learn more and more about this methodology. As a UX/UI designer myself I was surprised that in only one of the speeches they mentioned for just a second our possible role in the team. I find it hard to understand how a software or website be successful without the participation of a designer during its development.

    Looking forward to the next articles of this series.

    • 22

      That is very surprising and frankly, worrying to me. You’re spot on in asking how can experiences be built, collaboratively, without UX in the mix.

      Have those conference organizers reach out to me. I’ll gladly come down and present some of this material.



    • 23

      I agree with you, today I completed my 2 day scrum master training and I was looking for a perfect place for a designer to fit in between this system, my final output of this training was
      1. This is a good system for a project rapid development,
      2. Perfect for many development team to enhance there productivity.

      but what about the designer?
      I think there are still many more things need to be done for this system to be used for a UI development. There is no any proper reason for a designer to adopt this system. In most of the cases we are bypassed by creating a separate scrum team or being part of a one of the scrum team.

      does it matters regarding the productivity of the designer?
      because we all know that UI designing is all about projecting the basic theme of the project so without having the proper idea of the project just taking a chunk of task will it be fear to create a UI for that project?

  6. 24

    This method of “hub and spoke” works with smaller organizations. It does not work, however with large companies. 1 UX team trying to build multiple products at the same time cannot build a staff large enough to fit on all scrum teams. Or if a product is so large that there are 10 scrum teams running at once, the UX team simply can’t be spread that thin and allocate 1 UX team member per scrum team.

    This method also difficult to use on brand new products. The UX team has a ton of discovery work at the beginning of new product development. That work can potentially take months to complete. Once that is done, it has to be sliced into “bite sized” pieces and placed on the backlog and prioritized. Some of those pieces may not make sense if sliced too thin and therefor jeopardize the “definition of done” in the agile world. Sometimes making a deliverable piece of software after every sprint is not achievable if the UX is split between sprints and loses context.

    • 25

      Sorry Mike, completely disagree. I spent 5 years working in an extremely large media corporation that had a UX team consisting of over 150 people. In the last eyar or two UX management decided to go in the opposite diretion to the rest of the industry and tried to introduce the cental agency way of working. It was a total disaster, with product teams viewing UX as a flaky external resource instead of and essential and integral part of the team. The last thing you need is for your colleagues to view you as an unreliable meddling outsider.

      The areas of the business that managed to stay away from that and keep with the spokes system maintained their success.

      If you don’t have enough designers to work on all your products then that’s clearly a staffing issue.

      Read Jason’s reply, that’s exactly how to do it.. the months of discovery work is indeed done at the outset, in conjunction with the months of work that the product owner and business analyst are also carrying out beforehand, and also technical investigation too.. the backlog doesn’t come in until much later in the process. I led UX on an extremely successful new product that was done in exactly this way, it works.

      You / your organisation have also misunderstood the point of something deliverable. It absolutely does not mean a shippable piece of software, it just means something complete and demonstrable, to be able to show to your stakeholders in the sprint review. It’s very rare that you’ll find it impossible to get anything meaningful achieved in the duration of a sprint.. if so then chances are that you’re trying to do some open ended investigation work which should not be in sprints in the first place.

      • 26

        Ian – in an ideal world you have access to quality people to build a staff of 150 on a UX team alone, but there are a lot of companies out there that don’t have the budget or size to do that. They have to live within certain means in order to get the job done. In those cases you have to live and work with smaller teams and get more creative when moving work through the team in order to cover it. Would I love to build a team of 150… you bet; unfortunately it is not in the cards for me or my company. In fact I believe that smaller teams covering more work than they have people is more the norm than the unlimited size and budget scenario you are talking about.

        Also, I don’t misunderstand the point of something deliverable at all. I have worked with in scrum for a long time at 2 different companies… I have also sat in sprint reviews where the overall vision of the UX had to be reduced to fit the scope of the sprint and became fractured to the point of unusable going against the definition of done. This is not anyone’s fault and it is an understandable part of the process – but it does happen sometimes because of the nature of agile development.

        Ideally everything lines up and falls into place and work happens in the right order. The UX discovery is happening out in front of development and everything is delivered on schedule. Realty is deadlines, scope creep, and unforeseen issues that make the UX work run more parallel to development rather than in front of it. Again, I am not saying this is always the case, but it does happen.

        In my experience, the hub and spoke method was not in the cards. All my comment was saying is that hub and spoke is not an absolute for everyone.

        • 27

          This is where capacity planning and iteration planning are important. Designers have to be active in the planning and estimation process. This will add value to the project and product, outside of the value a great UI will provide. And allows UI’ers to better collaborate with product owners, developers, BAs, testers, trainers, etc.

          A decent coder may only be able to burn 20 points per iteration when they’re fully dedicated to a project. Where as a designer may only burn 10 points per iteration because they’re on multiple projects.

          Every project is different, every resource is different, and every organization has its own set of challenges. Agile tenants allow you to lead and self organize. It’s not cookie cutter.

          Designers will have to become familiar with rapid development methods. The same paradigm shift is still occurring with developers accustomed to waterfall. What’s lacking even more in enterprise development projects (at least in my world) is a customer advocate–UX’ers can fill this gap. Too much is left up to developers and product owners.

        • 28

          Of course, the reason for mentioning the 150 is you said it only works for small companies and not big – and that’s not the case. If fact I’d go as far as to say that it’s the other way around. And at the place in question it’s not 150 people working on less than 150 projects either, it’s a big place with an appropriately large number of both products and projects, split across many divisions.

          See my other reply about sharing – ad hock sharing is where you end up with issues. Dedicate staff to the large projects and have them there from way before the sprints start, and increase sharing on the smaller projects, which are also the ones less likely to be agile. But ultimately if you can’t get adequate resources in order to meet A. the amount of work and B. the deadlines then quality has to be sacrificed, and no amount of framework / process wrangling will help.

    • 29

      Faced with that issue in the past, I have forced the organization to pick which project was most important to have my UX skills focused on and left the others to proceed on their own with out UX help. That lets you deliver good design on the most important thing rather than doing a half-assed job on multiple things and burning out.

      The times that I’ve introduced the option, I’ve had good results. Funny that we tend to forget about letting some things go as an option.

  7. 30

    Thanks Bro! really helpful for people looking into the agile way of development. Check the dedicated website for UX developers. I think the UI/UX development area is now need to accept the new model of development like agile

  8. 31

    Great article. I think one note should be that the approach varies by both the size of the organization and the maturity of the UX Team. The hub and spoke model may be ideal, but if there are 7-8 projects running and 2-3 UX Team members — then the sharing will need to vary on a weekly basis.

    I agree strongly though with creating the concept of a ‘team’.

    • 32

      Ad-hoc sharing simply does not work, and defeats the point of having teams. A decent sized product needs at least one dedicated designer. If you really do have small part-time projects then you need to allocate dedicated designers to your larger ones and then share the smaller ones, not just share everyone around on demand.

      Really though it just sounds like you don’t have enough designers for the amount of work you have on.

    • 33

      The biggest challenges with resource sharing is focus and prioritization. The covered teams all have their individual #1’s and #2’s leaving the designer the difficult task of parsing out which is the most important #1.

      In these less than ideal situations, the ux office hours model may work for the smaller projects where ux is “available” for several hours a week for teams to stop by and ask questions. Haven’t tried it myself but heard it used successfuly in larger orgs.


  9. 34

    I’ve been part of several efforts to do UX in agile environments and had differing degrees of success. One challenge is usually that the teams I work with are used to doing all of the design themselves or possibly having a BA on staff to fill a design role. So not only is everyone trying to understand my methods and what they can expect from me, but also how that can fit into the rhythm of the scrum team.

    The stay one sprint ahead approach doesn’t work for 2 reasons. First, you can’t keep up. The pace is exhausting because as much as you try to deliver documentation that answers all the dev questions, you learn things along the way and there will be questions to answer and changes to make. That’s the whole point of going Agile. Imagine that you are trying to do any sort of usability testing and you are not only trying to front load the team with design deliverables, but follow a sprint behind with the testing. Then add on to that design tweaks based on the usability test findings and…whew! You don’t need sleep, right? Mini-waterfall approaches are antithetical to Agile and are bound for failure.

    Second, you are not acting as a member of the team if you are handing the developers and QA the specs. Instead, you have to get out of the mindset of owning the design. You have to work collaboratively with the team to create it together.

    The question that I keep hearing from colleagues is how do you come up with a design if you are only dealing with chunks of it at a time? After some practice, I’ve become pretty comfortable finding my way along the the big picture—narrow focus continuum to create a positive geschalt. But I don’t know how to teach a designer to think that way without just letting them fumble their way through it until they develop the needed skills. I’d love to hear your thoughts on it.

    -Gail @practicallyux

    • 35

      That’s not really true, would you cut up a PSD before the PSD has been made? Design a wireframe before you have any requirements? Save your work before you turn on your computer? Even within agile there is still an order that things have to be done in, ie. mini waterfalls. It’s just done in lot of little chunks instead of all of one thing then all of another.

      You also don’t have to sit there churning out reams of documentation – producing more documentation than is necessary is something that’s definitely antethetical to agile. A cross-discipline conversation with a wireframe or design as a starting point is far more effective than the current vogue for over-abundance of ux ‘deliverables’. What’s important is getting the information across, not the means in which it is communicated.

      It’s also simply not feasible to test effectively on a sprint by sprint basis, even if you’re lucky enough to have dedicated user researchers. recruitment, analysis and so on take time to do properly. What has worked perfectly for us before is testing on a per release/iteration basis instead. This avoids the issues that you’re talking about.

      Again, this has worked perfectly for us, and if you take a look at Autodesk’s PDF that I posted up earlier you’ll see that it has worked perfectly for them too, over many products over many years.

      I agree that it’s difficult to get designers who are used to coming up with a grand vision and then handing it over as a complete and finished thing to change their ways of thinking. It’s not easy and some will never get it. But in my experience the biggest issue that designers have with narrow focus is not feeling like there’s a bigger picture that it has been informed by and is contributing to, and all they’re doing is working on a production line of individual minor things.. so the big picture needs to be continually communicated, stuck up on the wall, etc. That’s half the battle won.

  10. 36

    Not sure how you are categorizing the term ‘designer’. Will you address the front end developers and information architects role in the UX structure, separate from the graphical designer? In some enterprise shops these may be in the UX group doing prep work for the Agile construction iterations as a total UI deliverable.

    • 37

      The visual designers should be working upfront too, working on mood boards and carrying out their own research. Personally I don’t like the term UX applied to specific roles, there’s no sensible definition of UX that doesn’t include almost everyone working on a web product. Better to refer to the entire team as the UX team, and leave what’s often called UXers as real job titles.. user researcher, interaction designer, IA, and visual designer.

    • 38

      I’m striving to have the term designer include all types of designers — IA’s, graphic designers, ux designers, et al. In addition, I’m working on cross-training my team so that these divisions disappear over time. I recognize it won’t be perfect but it helps to make the teams more efficient and productive.


      • 39

        Very glad to hear it, designer is a much more descriptive and accurate catch-all term than user experience. ‘What do you do for a living?’ ‘I design the structure / interaction / visuals of a website’. The only role designer doesn’t cover is user researcher.

        Call me a cynic but the term user experience seems to be often jumped on in order to increase day rates, especially when combined with terms like ‘architect’ ‘engineer’ and ‘consultant’… it can only take so long until people start to realise that UX architects don’t architect anything, UX engineers don’t engineer anything, UX consultants don’t do any consultancy, and that UX doesn’t mean much more than ‘someone involved with a website’.

  11. 40

    What I’ve heard of it being used in this large organisation is pretty disastrous! That approach means you no longer have a team, and that design are seen as an external resource.. and a meddling unreliable one at that.

    The only way that approach can possibly work is with a senior member of staff available for consultancy on a hours basis and still have a junior member 100% dedicated to the project, but even then it’s not the best way of doing it.

  12. 41

    Very insightful article, thanks. I liked the part where you say that we should let developers into the designer’s world to see the benefits as well as making the developers participate in the design activities.

    Can’t wait for the next part…

  13. 42

    Interesting article. This basically describes our agile culture that we have implemented in the last couple of months. I’m the UX/UI person on our team so this was a good read.

  14. 43

    Very Interesting article!

    As a matter of fact I am currently involved in an Agile project as a Interaction designer and at the same time as a Test Engineer. We are using Scrum as the methodology and in my opinion it works great. One approach we used is that the design activities started at iteration zero wich was a three weeks sprint where among other things like wireframes and conceptual design where created with close contact with the customer.

    Within each sprint my focsus is primarily on testing activities like functional and acceptans testing. I am also working, depending on the sprint and actual user stories, on modifying prototypes and planning and performing usability tests.

    • 44

      hi, nice post, i would like to share it but this link does not work : am i doing it wrong ? thknas

  15. 45

    Nice article. I’m interested in the idea of the Centralized UX Team within the hub and spoke model. I would assume that it is comprised of members other than the scrum team designers, such as Design Managers, Creative Director, etc., to a certain degree? That said, would all designers dedicate a certain portion of their time to this effort, or is it exclusively the duties of a select few to maintain this safe haven?

  16. 46

    Thanks for this article, it is very well written and useful. When is Part 2 due to come out?

  17. 47

    One of my esteemed colleague Meaghan Waters from ThoughtWorks Australia posted a similar blog entry on agiledossier, where she speaks about skill set and structure needed for UX teams. In addition to the agency model and the hub spoke model, she speaks of a matrix layout with crisp suggestions on how to consolidate learning from different teams.

    • 48

      on my blog, I want mine to be less geek and more web retproer. That is how I view myself: the web beat. Janet

  18. 49

    There are a number of people mentioning doing the design a sprint ahead of the development but I see that as problematic. I also don’t see where testing is coming into the cycle.

    Why would you move onto another iteration until you had the oportunity to see what works and what doesn’t? Not sure if I’m doing it wrong but I see agile as a series of many small waterfalls. Each sprint being the small waterfall and containing the design, build and test of the app/site in question, from low fidelity, through to the finished article.

    Anyone else do it this way?


↑ Back to top