Out of the silos and into the farm (NEPHP 2014)
•Télécharger en tant que PPTX, PDF•
7 j'aime•1,098 vues
A presentation about collaboration across UX teams from NEPHP 2014.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Out of the silos and into the farm (NEPHP 2014)
Similaire à Out of the silos and into the farm (NEPHP 2014) (20)
Plus de Marli Mesibov
Plus de Marli Mesibov (20)
Dernier
Dernier (18)
Out of the silos and into the farm (NEPHP 2014)
- 1. Out of the Silos and Into the Farm Marli Mesibov September 7, 2014
- 2. Boston-based content strategist Marli Mesibov @marsinthestars UX specialist What does collaboration do for us?
- 3. Successful projects are run by effective, collaborative teams. @marsinthestars
- 4. Getting through school classes art mathletes choir speech and debate studying track and field
- 5. Driving the customer experience development UX marketing SEO visual design interaction UI design
- 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 Development Visual design Content Functionality Research
- 8. A conveyor belt process results in a fragmented UX. @marsinthestars
- 9. The triangle of success collaboration
- 10. Agile
- 11. Waterfall methodology functionality content design development Week 1 Week 2 Week 3 Week 4 Agile methodology 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. 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 UX manifesto
- 30. 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.
- 31. The 5 Content Strategy Principles 3. Prepare for spontaneity. 4. Take advantage of iterations to try new things. 5. Try out pair programming.
- 32. “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
Notes de l'éditeur
- 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. Silos are often referred to as 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.
- Most people in the design realm are very familiar with a waterfall methodology. Waterfall was not intended for silo-work, but it’s fairly easy to see how people could do the work for their section completely independently of their colleagues. Agile methodology challenges this.
- It suggests to us that our time can be better spent, and rather than spending one week on business analysis, one week on content, one week on wireframes, one week on design, and one week on development, we should divide those 5 weeks into 5 revisions. Week one, everyone spends 1 day looking at business analysis, and then together they put together a very rough draft of their product. Week two they repeat the process, improving the ideas each time. If it sounds complicated, that’s because it is. Agile methodology was built for front and back-end developers, not full teams of content strategists, designers, and developers. They didn’t need to worry about collaborating or communicating between teams. We are complicating it by adding in these additional pieces. But I believe it can be done. Let’s look at a few key elements of agile methodology to better understand how it can help our processes.
- The Agile Manifesto: We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: 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. It sounds good, doesn’t it? It sounds idealistic – to say we value individuals over processes. So what happens when two individuals – let’s say a developer and a content strategist, disagree, with no structured process to fall back on?
- The 12 Principles behind the manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This gets at the purpose behind iterations. You can’t show customers a working product until the end of the process in waterfall, which can be frustrating. In agile we can show the customer something – not perfect, not complete, but working – early on. 2. Welcome changing requirements, even late in development. That’s not something we can do in waterfall. If something changes we have to go back to the beginning and start new designs. But because of those iterations in agile, because we’re constantly building new pieces, a change in requirements can be more easily handled.
- 3. Deliver working software frequently, from a couple of weeks to a couple of months with a preference to the shorter timescale. Now remember – this is a guideline, a principle, not a rule. Keeping it in mind helps us to stick to a minimum viable product, which most design projects are trying to stick to, but struggle with. Because in agile we’re delivering working software so quickly, it makes the minimum viable product imperative. 4. Business people and developers must work together daily throughout the project. This collaboration is something we’ll get more into in a bit – and it’s one of the key reasons I believe we need to make use of agile for design work.
- 5. Build projects around motivated individuals; give them the environment and support they need, and trust them to get the job done. This is something that most designers say they want, but how to make that happen is tough. Again, this is a situation where agile methodology provides a guideline – something to keep in mind while working. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. This doesn’t mean we can’t work remotely, and it doesn’t mean we can’t email. But it is one way to save time – remembering that in the midst of all of our screens and phone options, we can and should also go speak to people.
- 7. Working software is the primary measure of progress. Many user experience folk are trying to get out of the deliverables business. I support this, but ultimately we do always have a deliverable. I believe that focusing on that one deliverable (working software) will actually help us to take the pressure off creating deliverables for every other step, such as research and brainstorming. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. This means that for all that we say working software and quick turnarounds are important, we have a safeguard – no developers or designers should ever be working 60 hour weeks. That’s not sustainable.
- 9. Continuous attention to technical excellence and good design enhances agility. I think we can all agree on that – and I think this also gets at one way we can work well together – by focusing on the product itself. 10. Simplicity--the art of maximizing the amount of work not done--is essential. Again, this brings us to getting away from deliverables and constant documentation. Some documentation is necessary, but it it’s not then why are we doing the extra work?
- 11. The best architectures, requirements, and designs emerge from self-organizing teams. This plays hand in hand with ensuring we are asking for sustainable amounts of work. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. And that’s what I want us to today – I want us to reflect on how we each work. 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 angle in our 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.
- Collaboration isn’t tough when it’s easy. It’s tough when you’re fighting with someone else on your team and 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. It’s hard to keep in mind that developers, who know so much that I don’t know, don’t have my specializations as well. So when they’ve been explaining complicated things to me all day, it’s easy for me to get frustrated when they put a parentheses on the wrong side of a period, or make a strategic error that seems so obvious to me. 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 – as a content strategist, I need to understand what content the user will need, and when.
- With this in mind, I’ve developed a manifesto of sorts, to specify what we as content strategists do on behalf of UX. I think it would be an interesting exercise for you all to consider what your manifestos are - 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!)
- 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 in the user experience field 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.