Process is often shaped by how teams are organized.

In the context of designing for the multi-device web, the high level of iteration and communication required to build a modern website is rendering the assembly line approach obsolete and reorganization necessary. However, if a process is changed without rethinking the network of talent, resources, and management that support it, friction and inefficiency can arise.

Let’s assume that an assembly line process has 3 key phases: planning, design, and code, where each phase determines the next, and a project transitions primarily from strategy to execution.

fig1

Within this approach, teams are often structured to mirror the process. Planners (stakeholders, content strategists, management) define objectives and direction. Then, designers take the handoff to add form, hierarchy, and aesthetic. Finally, coders (front & back-end developers) execute the plan.

fig2

I think that this skill-based compartmentalization is one shortcoming of the assembly line. Locking developers and/or designers into a 100% execution role is a missed opportunity; ideally, every role contributes to strategy. Things like device compatibility and technical debt (typically in the realm of developers and often overlooked until the latter part of the project) should be a core part of strategic planning.

Teams compartmentalized in this fashion can have a difficult time iterating and exploring at a reasonable pace. For example, if developers need to schedule a meeting with designers and planners every time a layout change/breakpoint is needed during the coding phase, the iteration loop may extend from a few minutes to a few days. Traversing these compartmentalized phases and roles becomes cumbersome and time consuming, ultimately diminishing the potential for the final product.

If a process calls for multiple builds and rapid iteration, why not structure teams accordingly? I like the idea of smaller, tactical teams that are capable of executing multiple rounds of planning, design, and code quickly and independently.

fig3

The size, structure, and number of teams can be tailored to the organization, but the idea is to assemble teams with complementary roles in a truly collaborative way. Members are available to each other regularly, and the chain of command is not isolated to each division/skill (e.g. designers reporting to a creative director). The teams are ultimately responsible for what they build and how it performs.

Within this structure meetings become quick chats, ideas become prototypes, and the overall process becomes more efficient. For example, think about how much effort is involved when a Photoshop comp is polished, then all the color, sizing, and spacing values get harvested and reproduced in code form by developers. It’s duplicate work. With a collaborative team all the polish effort would be directed at the browser. Sophie Shepherd outlines these benefits in her work with Happy Cog:

By jumping right into the template phase before design was finished, we were able to make all design decisions in the medium they were meant to be in. We could do QA and device testing as we worked. With the help of SASS, it was easy to make changes and incorporate feedback directly in the browser—infinitely faster than it would have been in Photoshop.

When various skill sets are combined in this way, people learn from each other. Rather than creating to-do lists filled with nudges and site tweaks for developers, designers could learn CSS and edit designs in the browser alongside more intensive development. Developers could hone their design sensibilities and contribute by making enhancements such as gestures, geolocation, and performance a part of the design process.

Because the things we build rarely take one shape these days, it’s key to keep in mind that our processes and teams probably shouldn’t either. The time of neatly organized process charts and workflows is behind us. Building for the web has become a journey with infinite potential for forks and bumps in the road. Let’s make sure that our process and organization ready us for what lies ahead.

Ads by Fusion

28 Responses

Leave a comment or contact me via Twitter @TrentWalton

  • Simon Foster

    I’ve been having the same thoughts on my recent projects Trent, moving right away from an “assembly line” approach is a lot harder for clients who aren’t so used to the new way we all work, but we’re getting there :)

  • Ted Goas

    Nice to hear such a nice explanation of this kind of workflow. The diagrams help too!

    My team operates like this and I can vouch for it in a corporate setting. Without compartmentalized separation, back-and-forths are quick.

  • michael matyus

    I liken this process to interlocking the four flaps of a cardboard box, you can’t really fold one flap in at a time: at first you’re kind of nudging along and getting the flaps positioned and then it all comes together.

  • Sophie Shepherd

    I loved this article, Trent.

    At Happy Cog, we’ve been utilizing this small team approach for the last six months or so. An added benefit has been that every person is involved in the process from the very beginning. So, for example, our back-end developer is involved in the prototyping/HTML wireframes. By the their work begins, they have a good understanding of why each and every decision up to that point has been made, and a lot less gets lost in translation. All around, it makes for a stronger finished product.

  • Terry Acker

    Concise! Holistic perspective! I like it!

    These thoughts are coming in handy as I am ramping up for a next project. Thanks Trent!

    TA

  • Ryan Merrill

    Great write-up, Trent. The question I often face with this type of setup is how best to breakup teams. For example, each discipline isn’t always going to be busy or “on” all the time. There might be moments of slowness for the copywriter or the designer when the developer is busy. So instead of having the writer and designer twiddle their thumbs, it makes productive sense to move them onto another project to keep up office productivity. But by doing so you risk breaking up the team and losing any benefit you describe above.

    So, what should the other team members do in their downtime on a given project? Continue to iterate on their work and help out in any way possible with the others’ work?

  • Trent

    @Ryan Merrill:

    So, what should the other team members do in their downtime on a given project? Continue to iterate on their work and help out in any way possible with the others’ work?

    That makes sense to me. I bet that if the overall intent is to be collaborative (and the organization supports that), workload or project fluctuations won’t break things. On a small scale, Dave, Reagan, and I are working on separate mini-projects today but we’re checking in and helping each other throughout. I think being available is one of the most important parts.

  • Ced Funches

    Great points on collaboration. We use chat rooms to constantly stay in tune with product features, tasks. The main thing I try to do is keep a visionary planner in the mix to continually keep the project on track and align with global objectives.

  • James

    I completely agree with the notion of having teams work together in this way, but (unfortunately) I believe it falls victim to being to idealistic when executed. Mainly because you are missing one part of the team that goes into creating a project: The Client.

    In a perfect world where there is no client, this non-assembly line ideal works quite well. Planning, design, and strategy can work together, shifting certain parts of the project as they go to suit the myriad of devices and obstacles that an ever changing internet might present. The picture of the end product is something that comes into focus as you work rather than at the beginning stages of planning and strategy. Like you’ve said above, this helps keep the dev and design teams from being isolated or locked into ideas that came from senior strategists above but might not work as well in practice. It also saves time by letting integrated teams iterate quickly on ideas.

    In reality however, when there is a client involved, this ideal falls short because you are asking the person (or company) to buy off on an end product that doesn’t exist until it’s finished. Clients want to see that polished photoshop file so that they know what they are buying. In most cases, a project won’t even get off the ground unless you have some polished comps to sell a client so that they know what they are getting.

  • Trent

    @James: You raise some great points.

    you are missing one part of the team that goes into creating a project: The Client.

    I’d count them as planners. Maybe you don’t share office space, but they can be pretty closely involved though Basecamp, phones, and staging servers if they want to.

    In a perfect world where there is no client, this non-assembly line ideal works quite well.

    I think there are quite a few situations where organizations have their own design/dev/web departments—big business, universities, newspapers, etc.

    when there is a client involved, this ideal falls short because you are asking the person (or company) to buy off on an end product that doesn’t exist until it’s finished. Clients want to see that polished photoshop file so that they know what they are buying

    But does a polished photoshop file fully convey to a client what they are buying? We definitely have situations where rough comps are helpful, but this probably gets into how we work and communicate with our clients. Dan Mall has a great post on expectations that addresses a lot of that. It’s okay with me if I need to create an extra comp, but I’ll also talk about the importance of getting to code quickly so we can test feel… how the site handles things like touch, orientation change, gestures, etc.

  • Ben Callahan

    This is spot on. I’ve been privledged over the past year to act as more of a consultant helping larger internal teams begin to implement their own responsive projects. Hands down, the biggest and most consistent challenge I see is the discipline-based team structure. This is often even further aggravated by the divide between Communications (or Marketing) and IT who each own a subset of the web workers needed. Many times it’s difficult even to get these two silos in the same room, let alone ask them to collaborate intently in this fashion.

    It’s time to break these walls down, to set the expectation that collaboration is necessary to do great work. We can solve the technical problems, let’s address the organizational ones.

  • Caleb Mellas

    Good post Trent! Yes our workflow definitely needs to be refined and made more “responsive” to better fit our projects. Designing out of Photoshop can be hard, but it definitely beats designing everything twice.

    My workflow consists of a hybrid approach of switching between sketching, Photoshop and the browser.

  • Stefano

    Great post! I think we are talking about the Agile method

  • Steve Fisher

    Good post Trent.

    Interdisciplinary teams are essential to a successful project. I think RWD has made that more obvious, but it has always been true. This is what I’ve been loving about RWD and RWD process in particular over the last couple of years, it is forcing our industry to really deal with its shit. Good stuff!

  • Jorge Pinon

    Good post. Having moved from a larger company to a small start-up that *is* essentially one of the small teams you’re describing, I can tell you that efficiency is much better when we’re all focused on one goal.

    Stefano is right, this sounds a lot like Agile.

  • Dennis Gaebel

    Always a positive for everyone involved to witness the evolution of a project straight out of the gate. This way we as developers can pause the visual designers who wanna spend their entire performance budget on a 1.2MB hero image just because it looks good in the static PSD mockup.

    Of course, the visual designers can help to push the developers and the backend developers can help to explain what’s actually possible —instead of the “planning committee” presenting false expectations to the client.

    Yin and Yang as they say.

  • Paul

    @michael matyus: right on -- great way to put it!

  • Ian May

    Can I ask where you see the Web Project Manager fitting into this way of working? Maybe I just missed that bit...
    I have to say that coming from an Agency environment I can see what James is saying about clients not quite being ready for working like this. A lot of organisations we work with essentially have fixed budgets and don’t have the time to collaborate with us effectively.

  • Trent

    @Steve Fisher: Thanks! This was one of the most obvious recurring themes in all the SXSW panels on RWD we had going on.

    @Ian May: I wear that PM hat a lot. I think it’s planning.

  • Steve Fisher

    @Trent:
    Definitely. I’ve been thinking about this a lot before and after your post and decided it was time to write about my take on some of this. http://www.republicofquality.com/working-together

  • Bobby George

    A Montessori approach!

  • Nathaniel Deal

    Great post Trent! And also Steve! Thanks, you’ve inspired me to write this. http://nathanieldeal.tumblr.com/post/48782713373/death-to-the-waterfall Let me know your thoughts.

  • Jacques Letesson

    Inspiring post, thank you Trent. On a daily basis, I work closely with designers (with a print-making background) who are more and more solicited to conceptualize and mock-up responsive websites and applications. We try as much as we can to educate them to RWD best-practices but sometimes the very linear workflow and constraints they have been using are very difficult to overcome... The emergence of early (low-fidelity) prototypes during the design process gives us the tools we need to help them understand how they can improve their layouts in term of user experience. Regarding this matter, the post of Dennis Kardys (@dkardys) - A more flexible workflow - is very interesting as well : http://tinyurl.com/chh325v

  • apanag

    I couldn’t agree more with that approach. To my belief, if every team member has the willingness to learn new things that aren’t directly in his/her field, for example a developer to learn design things, then the team will be able to handle, with ease, the most advanced project and predict any difficulties before they even appear.

  • Tyler Schuett

    Having contributed in various different environments ranging small to massive, I agree and disagree.

    A team comprised of members who are T-shaped (broad understanding in a lot of disciplines, and extreme deep knowledge in one or two) lends itself to much better results. I think that when you’re a small to medium company it’s almost crucial to operate the way you’ve prescribed here.

    When you break into the 1,000+ person mark though, operating this way can become messy. 50 designers doing their own thing can become chaotic. Even with a standardized design architecture, bringing continuity across a massive organization with no structure sounds impossible to me; Especially when a company has hundreds of different products or services it’s offering.

    I say this as I sit in a room with my team of engineers and PM’s focused on building our own features and innovations... and I wouldn’t have it any other way. We just have a centralized design team to which I answer to, and I think it makes a lot of sense at this scale (60,000 plus employees).

  • Eric

    Great article, but the images you use are incredible. What is the meaning of the birds (on the top image)?

    Regards

  • Trent

    @Eric: I was thinking of how birds arrange themselves during flight/migration for efficiency sort of like this.

  • Isaac Gray

    I’ve been trying to adapt my workflow along these lines lately. As a freelancer this can be a challenge when coming up against these traditional organizational structures and ingrained patterns of behaviour. Great post Trent!

Leave a Reply