Out of the silos and into the farm
•Download as PPTX, PDF•
2 likes•1,122 views
Whether you’re a one-man team, or a member of a large team, collaboration can be difficult. We all know silos aren’t the answer, so how do you work together without stepping on toes or forcing the whole team to wait at each step of the process? In this talk, we’ll take a look at methodologies that ease the design process, and learn how a group can truly function as a team.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to Out of the silos and into the farm
Similar to Out of the silos and into the farm (20)
More from Marli Mesibov
More from Marli Mesibov (20)
Recently uploaded
Recently uploaded (20)
Out of the silos and into the farm
- 1. Marli Mesibov June 19, 2014 Out of the Silos and Into the Farm
- 2. Boston-based content strategist Marli Mesibov @marsinthestars UX specialist What does collaboration do for us?
- 3. @marsinthestars Successful projects are run by effective, collaborative teams.
- 6. Your design doesn’t fit my content. Your content doesn’t fit my design! Development didn’t consider us at all!! It must be his fault. Let’s go get him!
- 7. The customer experience conveyor belt Research Functionality Content Visualdesign Development
- 8. @marsinthestars A conveyor belt process results in a fragmented UX.
- 9. The triangle of success collaboration
- 10. Agile
- 11. Week 1 Week 2 Week 3 Week 4 Waterfall methodology Agile methodology functionality content design development Iterations: 1 2 3 4 5
- 12. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more -The Agile Manifesto
- 13. The 12 Agile Principles 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- 14. The 12 Agile Principles 3. Deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project.
- 15. The 12 Agile Principles 5. Build projects around motivated individuals; give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 16. The 12 Agile Principles 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 17. The 12 Agile Principles 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity – the art of maximizing the amount of work not done – is essential.
- 18. The 12 Agile Principles 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- 19. Collaboration
- 20. Collaboration in 3 easy steps 1. Keep your eye on the prize 2. Set expectations 3. Magic words: “I don’t know”
- 21. Keep your eye on the prize
- 22. “Different people like to work in different ways. To get the most out of your team, you have to respect and value that diversity.” – Deborah Holstein, Marketing Profs
- 23. Set expectations
- 24. Plan for success: Set a plan in advance Touch base often Write down what is said “Being busy does not always mean real work.” – Thomas Edison
- 25. Magic words: “I don’t know”
- 26. What makes someone a valuable team member? Experience Knowledge Creativity Subject-area expertise
- 27. UX
- 28. “The best UX design seems to be coming from designers implementing a ‘release early, release often’ mind set… It favors responsiveness and nimbleness… and for most enterprises [is] incredibly difficult to do.” - Jon Lax
- 29. @marsinthestars 44% of B2B marketers are implementing content strategies.
- 30. We will build intuitive user experiences. We will develop usable guidelines and strategies. We will adapt to agile methodology. We will increase cross-team collaboration. -my content strategy manifesto
- 31. The 5 Content Strategy Principles 1. Conduct research before the first sprint begins. 2. Create a minimum viable content strategy. Prioritize the most effective and valuable elements.
- 32. The 5 Content Strategy Principles 3. Prepare for spontaneity. 4. Take advantage of iterations to try new things. 5. Try out pair programming.
- 33. “When you decided to become a designer, you accepted the role of gatekeeper with it. You are responsible for what you put into the world, and for its effects upon that world.” - Michael Montiero
Editor's Notes
- My name is Marli Mesibov, and I’m a content strategist based out of Boston, MA. I’ve become fascinated lately with understanding how projects are run, and what makes them run efficiently. It’s probably not surprising. I first learned about content strategy and the user experience while working as a project manager in a user experience agency, so understanding what makes a project run efficiently was my job.
- What I have found, time and time again, is that projects run smoothly when teams are working together smoothly. Honestly, it reminds me of high school.
- When I was in 10th grade, I spent every lunch period and most study halls in the music room, with my music friends. We’d play string quartet music, or just sit and talk, and I loved it – except when they started picking on the “dumb jocks.” I always struggled with their view of the athletes, because after school every day I went to cross-country practice. I loved cross-country, where my other running friends and I would log miles and share stories. But it always stung when they bitched about the “nerdy, weird” debate kids because… you guessed it. I spent two evenings a week practicing oral interpretation and Lincoln-Douglass style debating. Do you know what my Speech and Debate friends whined about? They were fun people, and they were mostly laid back. But they hated the stuck up jerks in the music program.
- As a copywriter turned project manager turned UX consultant turned content strategist, I get that same queasy feeling in my stomach when I hear my people insulting others who are also my people. It makes me want to sit in a content strategy silo, where I’ll only need to talk to other content strategists, and we’ll be able to work in complete isolation, with no push back from anyone who doesn’t understand us.
- But there’s no way around it. The silos are coming down – and with good reason. Imagine a company where a software product is created, but the designers are on one floor, the developers are on another floor, and the content team is in another. Rather than send emails, they upload their completed work to a server, where it is passed along to the next person. But one day, the UX designer looks at the completed application that’s been created, and asks “who put that video in this screen? It looks terrible!” The UX designer storms into the content office, and says “why did you put the video there?” and the content strategist says, “well, I needed to put it somewhere. Why didn’t you design a place for the video?” So they redo a bunch of design work, and send it along to the developer. The developer takes one look at the beautifully redesigned application and says “I don’t have nearly enough time to develop a customized element for this video or this redesign. The scope I drew up assumed we were following a strict pre-designed template.
- I didn’t make this company up. I actually interviewed with them a few years ago. When they gave me a tour of the content floor I felt a little uncomfortable, seeing all of these content creators sitting in cubicles, silently putting information into templates. That’s not the world we live in. I felt even worse when they showed me some sample products they had created – the products accurately reflected the lack of collaboration. Designs felt out of date, and content awkwardly sat in hastily-developed chunks.
- You may have worked at this company, or one of the many enterprises like it. This morning, Noz told us that silos are breakdowns in communication. I think silos are also where we go to when we want to specialize. We dig in, we build up, and we end up with walls separating us. But when we talk about silos, we’re talking about teams or team members working in isolation, passing a product along as though on a conveyor belt, without communicating. Now it’s time for the silos to come down and designers, developers, and content strategists to all work together to create scopes and design our processes and applications.
- Today we’re going to connect 3 points to make a triangle: Agile, Collaboration, and UX. We’re going to connect those three points, and at the center we’ll find better strategies for our projects.
- 3. Deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project.
- 5. Build projects around motivated individuals; give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential.
- 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. These are the 12 principles of agile methodology, but they are also all elements of any successful team. Working at a sustainable pace, paying attention to quality, working flexibly and communicating with one another and with clients… these are things we all need to do. These are beautiful principles. But when I work with clients, I tend to break things out. We start with a mission (agile has one). Then we break the mission down into goals, or principles (agile has 12). Next we need to break the goals down into components. How are we going to accomplish each of these goals? That brings us to the second part of the triangle.
- Principles and theories are the foundations upon which we build our products. But when it comes to putting theories into practice, we need to talk about specifics. How will we agree on a minimum viable product? What constitutes “continuous attention” to detail? When should software be considered “working”? These are areas where teams need to find agreement, in order to be able to accomplish anything. So now I want to get into those nitty gritty questions and determine how, exactly, your team will be able to uphold their own mission statement and principles.
- The worst part about fighting with someone else on your team is that feeling that they are preventing you from doing your job, and from finishing the project. Which is bizarre, given that they are supposed to be helping. Sometimes, sure, they’re just being a pain, but there are things we can keep in mind as well.
- Here’s the thing. I like my job, and generally, I like my clients. I’m guessing you do too. Our projects are often really enjoyable, and even when they’re stressful, we take great pride in doing our work well and having a fantastic finished project. So when the user researcher on my project says that he already planned on doing all of the ethnographic interviews, yeah, I had been planning on doing them myself. But it’s not worth fighting about, because our goal is the same: we want to learn about our users. As long as I keep that goal in mind, and I remember that the project will go more smoothly if we work together, I’ll more likely just ask the user researcher if I can sit in and listen to the interviews. It’s unlikely he’ll say no, and if it turns out he really isn’t any good at his job, and asks terrible questions, then I can pass him notes adding questions of my own.
- Dean Barker, from Blend Interactive started complaining to me at a conference party about content strategists. “Do you know what your problem is?” he asked me. “Your problem is, you guys think that we mess everything up. You come in with these totally unreasonable ideas for governance or how a CMS should be structured, and then I just screw everything up for you by expecting something I can work with.” “Well, what can you work with?” I asked him. He said, “I don’t know yet.” I thought for a minute, and then I said, “It sounds like you’re saying you need me to come up with something – anything, so that you can look at it and pick out what will work, and what won’t work. Maybe I could give you my ideal strategy, and then you can let me know what’s possible, and what I need to rework?” And he agreed.
- Now, what that means is that after telling me content strategists have “unreasonable ideas,” he approved me as a hypothetical content strategist for his company, to come up with as many unreasonable ideas as I wanted. But we both knew the expectations, so that reality wouldn’t be a mean kick on the ball of our dreams. Instead, I would walk into the first meeting assuming this work would be thrown away in favor of something once I knew the guidelines. And Dean would know, walking into the meeting, that I was not bringing a finished product – in fact, I wasn’t even bringing in a started product. I was just bringing in something for him to reference, to get him started explaining what he needed.
- Content strategists struggle to work with marketers because many of us were told, or seem to think that content strategy is just a better version of marketing, and anything they’re doing we can do better. About a year ago I walked into a meeting where everyone in the room was at least ten years older than me. I was responsible for presenting a content strategy to the team, but not two sentences in, someone from the marketing department interrupted me. I was frustrated, and I wanted to interrupt right back and prove my point, but I figured, here’s a man who has been working in marketing and the whole web world for at least ten years longer than I have. He must know a lot that I don’t. Then I realized that there were aspects on content strategy that he hadn’t heard of, but I was still learning so much about marketing from him. I hope that if I’m still working in content strategy twenty years from now, I hope I still remember that we all come from different backgrounds, and we all know different things that are helpful to one another.
- On the other hand, we can’t become so dependent on other peoples’ knowledge that we forget our compassion. Developers, for example, frequently seem to come from Jupiter, or some other planet where everything we do here on Earth is backwards, and yet they can’t tell us how or why everything is different where they come from. When my father is baffled by someone’s lack of knowledge, for example if he meets someone who doesn’t know about the names of every member of the New York Mets, he says “he wasn’t born with that knowledge in his diaper.” It was his way of remembering that even the most “obvious” things are new to someone, and for me, it helps me remember that developers don’t necessarily know things that seem obvious to content strategists. In fact, a developer has had a totally different set of training than a content strategist. It’s up to us to be patient. It’s up to them too, but nothing has ever been solved by waiting for someone else to take the first step. So when things don’t make sense, I’ve found the best questions to ask are not “why” but “what.” “What have you seen in the past?” “What types of situations are you expecting?” and most of all, “What can I do to get you what you need?”
- This brings us to part 3: UX. Agile work, and collaborative work, are two points of the triangle, and using just agile strategies and suggestions for better collaboration may be enough to improve your projects. But UX is the third piece and it’s just as important. Many people actually consider UX to be more important then collaboration, but it’s my opinion that the experience will suffer if we can’t work collaboratively on it. User experience is, quite literally, the experience someone has when using your product, your website, your application.
- Creating a positive user experience means focusing on people over process. Jon Lax, in an article called “Shipping an Empty Box” said: “Modern UX design is favoring a model of constant improvement… The best UX design seems to be coming from designers implementing a release early, release often mind set. People like Jason Fried at 37Signals preach a sermon of simplicity and getting real. Build it, release it, watch it, refine. It is a good methodology I think it yields over time a good UX. It favors responsiveness and nimbleness… and for most enterprises incredibly difficult to do.” Jon Lax, “Shipping an Empty Box” Sound familiar? “release early, release often?” It should. That’s agile methodology. UX and agile were meant to work together. I believe that content strategists need to employ user experience techniques every day. Everything we do is based in understanding the user, speaking with the user’s voice, walking in the user’s place – understanding what content the user will need, and when.
- In many ways, working in content already required the flexibility that UX and agile together require. At one time, content strategists were seen as so unimportant that we were forced to follow whatever schedule the designers or developers wanted. If that meant we had pages of content due with only a day’s warning, and then no work for weeks, then so it was. But we rebelled. We shouted “content is king!” and they heard us. We are part of the user experience process. We are now understood to be a key part. 44% of b2b marketers use content strategies – that’s huge! If we demanded it, in many companies we would be given a silo where we could develop our governance tactics and editorial guidelines and editorial calendars and brand guidelines and SEO guidelines and voice and tone. But we don’t want a silo. We want to take the elements of agile methodology and collaboration and make a manifesto that will result in intuitive, delightful products.
- With this in mind, I’ve developed a manifesto of sorts, to specify what we as content strategists do on behalf of UX. - Our mission is to Build Intuitive user experiences. Our goals, or principles are to develop guidelines and strategies, to adapt to Agile methodology, and to increase cross-team collaboration. What are the components?
- By and large, they’re the same components I listed for collaboration. But there are a few additional components, specific to getting our work done. 1. Before the first sprint, comes the research. While the user researchers are gathering their information, we need to be simultaneously gathering any other materials already exist. Are we working on a project that already has an established brand? Great. If not, now’s the time to identify others that are similar. It won’t make for perfect content in the first sprint, but that’s ok! We have multiple iterations coming up. 2. Prioritize. Liz Bennett and Rachel Lovinger had side-by-side experiences with agile, and wrote about it back in 2011 in an article called “Can Agile Work for Content.” One of their biggest takeaways was the necessity to move fast. “In an ideal world,” they wrote, “Liz would have done a complete content inventory and gap analysis up front, but there was no time.” Knowing that there won’t be time for everything, prioritize the most effective research, the most necessary governance tactics.
- 3. Prepare for spontaneity. When we do get into the first iteration, we need to log and categorize every single piece of copy, every image, every bit of help text, every error message. Essentially, create a content audit as you go, so that three iterations down the road, there’s something to reference. 4. Take advantage of iterations! Try one tone in the 2nd iteration and another one in the 3rd. Set up usability tests towards the end of each sprint, to learn what’s working and what isn’t. 5. Try pair programming. For developers, this means two developers sitting side by side working on something, and then swapping to check over work or help with difficult areas. For content strategists, try sitting by a designer. You start on one wireframe while he or she works on another – then swap. See how the flow comes together with some pages content-first and others design-first. I also find that designers are great for bouncing around ideas. (Because they know things that I don’t!)
- Earlier today, Mike Atherton quoted a line from one of my favorite quotes. Mike Montiero, in his talk “How Designers Destroyed the World” – which I highly recommend, it won the Net Award for talk of the year, and in it he says: “When you decided to become a designer, you accepted the role of gatekeeper with it. You are responsible for what you put into the world, and for its effects upon that world.” I love this quote. I believe that we have accepted the role of gatekeeper as well. We, content strategists, are responsible for what we put into the world, and for its effects upon that world, and we can do that all the better when we are working with and not against our colleagues.