User Centered Execution for Mobile UX Designers
•Descargar como PPTX, PDF•
5 recomendaciones•1,415 vistas
The biggest barrier to good experiences (as well as the largest problem for most UX designers) is in getting well-intended, well-designed systems executed as the business owners and design teams intend. I present the problem, and a series of philosophical changes and specific tactics to alleviate this, and to work with implementation teams to get design executed correctly. Slideshow I will present 29 Feb 2012 at 10 am PT as an O'Reilly webcast: http://oreillynet.com/pub/e/2103
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (13)
Similar a User Centered Execution for Mobile UX Designers
Similar a User Centered Execution for Mobile UX Designers (20)
Más de Steven Hoober
Más de Steven Hoober (20)
Último
Último (20)
User Centered Execution for Mobile UX Designers
- 1. User-Centered Execution How UX and development can work better together 1
- 2. Patterns for interaction design 2
- 3. Principle of Most Time: The most elegant and simple solution to any design problem will be the one that requires the most developer effort. 3
- 4. Every product we build is a product we build for ourselves to solve our own problems…making decisions based on real opinions trumps making decisions based on imaginary opinions. 4
- 5. Adapt or succumb? 5
- 6. No one has to loose We need each other, equally. Everyone contributes to the final product. Implementation: User Experience: • Build software, storage, etc. • Define scope • Launch products • Consider whole experience • Maintain forever • Design detailed interactions Delivered to the users, efficiently Create the right solution, the first & reliably. time, with less rework. 6
- 7. No more hand waves 7 77
- 8. Shared principles • Modular • Iterative • Incremental • Patterns and best practices 8
- 9. Modular Implementation: User Experience: Good programming principles We don’t draw every page and (whichever you embrace) state independently, but consider encourage re-use, consistent the design holistically, and draw naming and resource allocation, many items to be used across and using the simplest solution. the product. Re-usable components make work quicker and more efficient, more repeatable, easier to understand for regular teams and easier to improve or fix. 9
- 10. Iterative Implementation: User Experience: Start simple, learn as you go Review designs internally, with from both solutions and needs of user research and by analytics the customer/client, and build when launched. Identify, learn improvements on what you build and improve, on small and large before. timescales. Whether week two or release two, work is never thrown away, but improved on and expanded to become better and more capable. 10
- 11. Incremental Implementation: User Experience: Assigning developers one task Conceive holistically, but design helps focus, and allows the team in easy-to-manage chunks. Split and management to track the work to who can best progress, and further split (or perform the work, and deliver in combine) work as needed. pieces if needed for speed. Resources – both people and time – are limited. Deliberately break up work in an ordered manner for management, and coordination. 11
- 12. Patterns & Best Practices Implementation: User Experience: Apply existing knowledge and re- Speeds work and constrains the use known good solutions, but , problem space with libraries, extend and combine to meet the patterns and stencils. Analyzes system needs and project goals. or researches to find the best solution. All of our work builds on history, knowledge and evidence. But watch out for best vs. common practices. 12
- 13. Your fears are baseless • There’s no time • Process mismatches • Excess documentation • We don’t speak the language 13
- 14. There’s no time • There’s plenty of time • Scale the engagement • It pays off in the end 14
- 15. Process mismatches • Everyone has the same goals • One process is very much like another • Gaps usually interlock • It’s a team effort 15
- 16. Excess documentation • Don’t fear the documentation • We think by drawing • Your team uses documentation… • …and the next one certainly will • Whiteboards work in a pinch 16
- 17. We don’t speak the language • UX is the translator • Know all the people • Know all the needs • Know all the systems • Foster conversation, collaboration 17
- 18. Tactics for success • Don’t walk away • Set goals for everyone • Design and build objects • Practice polymorphism • Project principles 18
- 19. Don’t walk away It’s your project still, so stick with it: • Answer questions. • Check on progress. • Solve problems. The team is the same, regardless of phase. 19
- 20. Set goals for everyone • Turn principles into metrics. Then measure them. • Push for these to be the project level metrics of success. 20
- 21. Design and build objects • Patterns are objects. • Objects are re-usable components, whether in design or code. 21
- 22. Practice polymorphism • Variations of objects are still the same object. • Tell everyone, so variations are built as you designed them. 22
- 23. Project principles • Develop good objectives • Design holistically • Get everyone to buy into it • Own your design 23
- 24. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 24
Notas del editor
- Naturally, O’Reilly is hosting this presentation because I wrote this book for them. But also because I had more to say. One of the things that comes up a lot, and which I spend a lot of time doing when I start a new job, or work with a new client is to talk about process, implementation strategies, and communicating with developers. I am a UX guy now. If I have to give myself a title I prefer “Interaction Designer.” (Or, of course Mobile Interaction Designer). But I have been a web developer, and I’ve even been a DBA of sorts. I have managed teams of technical people, in corporate IT organizations. I’ve been trained in about a dozen different development processes, and completed over 150 Agile projects. Aside from collaboration, and working with developers, I understand the pressures and needs from both sides. Partly for that, and partly as I know many of you are developers looking to improve the design of your products, this presentation (and much of the book) is actually targeted at both designers and developers.
- Let’s start with the typical current state of the world. I’ll avoid naming names, as the sentiments are all too commonly expressed. This is a real quote, from a UX point of view: “Developers ruin everything.” Pretty things are always hard to implement, not due to incompetence, not even because they maliciously try to get in our way, but due to the fundamental nature of the universe.
- This one, from the developer side, has been sadly cut down. It came from an interview, not a neat twitter feed, so I had to edit to get it on the screen.There are two threads going on here. They design for themselves, not for any class of end user at all. And along with that, they reject the entire principle of UX design. See that last word: “Opinions.”There’s a perception, especially among developers, that UX is art, and art is opinion, so whoever yells loudest, or digs their heels in the most, wins. So, don’t let those UX guys pull anything over on you. If you have the power, don’t even let them in the building.
- Of course, this is all non-productive talk, and we need to get over that, and work together.The gist of much of my talking about process, and especially of UX in strict development processes – like Agile – is that we as UX designers are expected to not work /with/ the process, but to become part of it, to adapt ourselves to the other process. The end result being all our processes are discarded when not obviously understandable.
- But that doesn’t really do anyone any good. It’s not just bad for our careers, but bad for the product, and the business. We’re actually all closer than you’d think, and by taking a bit of time to analyze and mesh the processes, no one ends up outside their comfort zone. But it does take time to analyze. You need to not just believe that others have value, but be able to explain -- to others and to yourself -- what you contribute to the effort.
- There are gaps in many processes where “a miracle occurs” and details are not nailed down. Do a serious analysis and you’ll find that you (or someone else) “just does stuff,” and no one knows how. Often, no one knows why, either. Very often, this is because the process is trying to go too far, and another process can fill in the gaps. There are a lot of these gaps, but my biggest example is in creating features (or stories if you wish) within most development processes. Where did all these cards come from? How do we know they are useful, or the most important ones are being done first? I have come in weeks into implementation of a project to fix what was supposed to be a minor issue, and discovered that as many as half the features are duplicates or conflicts. It’s because development is not about /creation/ of ideas. Which is totally fine and we support their lifestyle decision. But others can help. UX has good analytical techniques to find problems, understand user and business needs and develop things which are impossibly similar to feature lists, or stories. And as long as you as a UX designer have a helpful demeanor, doing this sort of stuff doesn’t look like you are intruding. It makes everyone happy with you for embracing the process and being collaborative.Collaboration doesn’t mean /everyone/ does every, single, task. It’s sharing, accepting input and letting people do what they do best.
- At least as I work UX design, there are a lot of principles at the core of our work processes and methodologies that end up being shared with other disciplines. As we’re talking about UX integration with development, let’s look at how these are considered by UX and Dev:
- Whereas development teams embrace the principles of re-use, in an effort to find the simplest suitable solution, UX agrees completely. We have different reasons, considering holistic design and team efficiency vs. optimizing for resource efficiencies such as storage, but philosophically they are very similar. We can all conceive of componentized approaches together, for more efficiency of products and processes.
- Good developers do not build, deliver, then bang their heads against a wall till they forget. There is a process of continuous improvement both within projects and between them. Better solutions are sought, built and installed over (or added to) previously built items. UX, does the same thing. We have a culture of evidence, and so seek to prove successes. And when we find imperfect solutions, use that data to improve the design. We all can collaborate on improvements and conceive of new, better solutions together.
- Development managers assign tasks, sometimes going to far as to tear off pieces of printed documentation, distributing chunks to developers or teams. Processes enforce this, with unit test assuring quality of the piece of work, for example. UX designs holistically, but no matter what we say, we understand work schedules, release plans, and defining key components first in order to understand other pieces, next. Time and manpower limits all work. We must always keep in mind the whole structure, but admit we can only work on one piece at a time.
- Developers do not exist in a vacuum and do not build almost anything from scratch. Not only do they share, and use knowledge resources, but libraries of commonly-needed items are routinely used. Think of what J-query really is.UX lives by the heuristic, and other ways of defining known-good solutions, then borrowing. Much design is with stencils, literally copying the lines or pixels from a previous design or shared-library. Past modular, we all use pattern libraries, borrow from other designs, and understand patterns.Let me take a moment to point out a fallacy of “best practice.” By no means is something commonly encountered a best practice. Commonality makes it a “common practice.” It has to be proven to be the best solution to be a “best practice.” Never make assumptions, and seek out information before setting it on paper or directing it be built.
- So, if we all agree so much in principle, why don’t we work together? Practically, why is it so hard to get UX involved in the process. Well, because UX is slow. It doesn’t get the details of IT process. Who needs extra documentation, and we just don’t think the way IT people do.Well, that’s all demonstrably untrue, but you need to understand how and why in order to talk past it.
- Remember the three legs of a project? IT lives by “quick, cheap or good, pick two.” I hear it weekly, or more.There’s only so much you can do about costs, and our job is about making it good. But speed is the last fear. No one wants to wait an hour, and many developers heard of UX from a very formal point of view. It sounds like it takes months, especially when you talk research. But project processes are inefficient. Between a gleam in someone’s eye and kickoff could be six months. In a Lean environment, in my experience, it’s still two months, minimum. Take that time to build features and explore ideas and ask questions and draw wires. I have done good work between project kickoff and the 10 days it took to get the team up to speed, and engage the offshore resources. There’s always spare time.Of course, what I did in a lot of these was scale the effort to the time, budget and influence I have. This is also collaboration, and negotiation. I always say any UX engagement is better than none. And lastly quality design phases improve deliverables. This reduces time on the back end, in test, and so on. Time spent up front pays off between 8 and 20-fold on the other side. There are studies of this. If that’s not your experience, its because someone skipped a step, didn’t collaborate, ignored recommendations, etc.
- The next issue is that there will be a cultural or process mismatch, and it’ll take time to figure out how to work together. I’ve talked about this already, under the principles. The processes are not that far apart, and as long as everyone tries, and communicates, issues resolve themselves.Process and culture failures arise when management encourages or allows process and culture to be a problem. If everyone is reminded that the project team is the only team that exists, and development, test, design, etc. are not teams, it works fine.
- Especially in some flavors of Agile, some Lean-leaning and startup-wannabe shops, there is an ethos that documentation is a bad thing.At the least, there’s fear that it conflicts with their existing documents.The first two answers here already covered most of this. It doesn’t take time, because documentation is part of the design process, not a step afterwardsWe can make the documentation in any format you want, and integrate with annotation methods, or styles to make it easier to build and testAnd, documentation is always used. Even in “no-document” shops, anything I give people on paper is used and beloved. And with offshoring, the fluidity of teams, etc. someone will need this documented for the next release, whether that’s next week or next year. Lastly, always explain that UX can be flexible. We can do the work on whiteboards and by waving our arms. Doing this a bit (and taping paper documents to the whiteboards), helps alleviate a lot of fears.
- The ongoing conversations about whether designers need to code brings this problem into sharp focus. There are a lot of organizations that think its required and only hire “Designer/Developers” whatever the actual name.There are also a lot that think it’s specifically bad for designers to code. We collaborate, remember? So, that means specialization: get the best person at each job, and work together. By no means does this mean designers only know design. I find the most important job of UX, more than advocating for the user, or designing interactions, is advocating for the project. It’s the ultimate answer to the “should designers code?” question. We should know how to, and know as much about every bit of technology as we can. Just like I know how furniture goes together in a factory (because I did some furniture design in school), or know how printing presses work -- from my graphic design days, for my current jobs I have learned all about not just software, but storage, and networks, and location services, and batteries and much more. I think it’s so important there are giant appendices at the end of the book on topics like this, that are outside of “design” but key to doing your job as a mobile designer. Much is left out, so learn your domain, really well. A key role of UX is to be a bridge, not just between the user or business and development, but between different development teams, such as networks or data storage and software. Know a little about everything, so you can assure the entire project experience is good in every way.
- What we need to solve this are principles of what we can call “user-centric execution.” This is not yet a process, or series of fixed procedures, or a manifesto or anything that well defned. It is possible it may never be. But like the principles, heuristics and patterns of design, the idea should be followed and there are best practices. So, to conclude this, a few principles:
- It’s your project, so stick with it. And this holds true for everyone, so make sure they stay involved through development, test and implementation. As a designer, you need to be ready to stick with the project through development, at least making yourself available for questions, rework, changes and testing.Ideally, become integrated into the team, and attend daily meetings, test planning, and so on.Plan on this from the start so your schedule and budget accounts for it.You may not actuallybe part of the implementation team, but try to become one. Or at least act like it. Go to meetings, etc.At the very least, put your name a contact information on any documents you deliver. It’ll work. You’ll get calls from random developers in Bangalore at 2 am, and be able to give them good information to make sure the project keeps going.After you get more sleep, you’ll be happy this happenedDevelopers, pick up the phone or walk over a grab the designer. If something is unclear, or not specified, or a new problem comes up, ask. The designer ought to be able to come up with a solution, fast.
- Assure goals are for everyoneThe business and user goals you should have developed at the beginning of the project must be translated into actual, measurable metrics.Make sure that the whole organization has these goals as their top drivers, instead of cost savings, efficiency of developers, or other internal measures.While “we’re building for the end user” may not resonate, remind everyone they work for the larger company, not just their department. You may also have to push to include the analytical tools to make sure they get built, not forgotten.
- Use object-oriented principles when discussing and delivering. And make this clear, to the point of putting them on the walls of every pod.The efficiencies and enforcement of consistency that componentized, object-oriented practice emphasizes in design are just as valuable to software developers and development process.Sometimes this is just called “modular re-use,” or other things, as “object oriented” is a larger set of well-defined principles (it all originated in development) and might confuse the implementation team. In fact, half the principles we care around organizing teams and features are the same in procedural development. But I like the sound of “object oriented.”The core concept is the same: Instead of designing every detail for every state, and building by state or building hundreds of items to bolt together, a few dozen modules are built and re-used over and over in common templates.
- Learn big words. Even if you don’t annoy others with them, there are some great concepts out there. This is a subset of the previous one, but is harder for some organizations and designers to grasp, so I broke it out onto it’s own slide. If there are several variations of an on-screen module you design, make sure you express them as variations of each other so these are clear. This is a polymorphic item.Of course, if there is only one variant (omnimorphism) then that should be explicitly stated as well. Always keep in mind efficiency and re-use.
- What makes this work for me is that it’s all the same thing. I’ll admit I came to them from different approaches, but I’ve come to be aware that good principles of design are the same as the principles behind communicating design to implementation teams.Develop good design objectives for the project or product; no one elese’s will do. Design holistically; systems, not pages, not widgets, not buttons. Stick to the principles and get everyone to buy into it.Own your design, all the way through, so you want to improve it when the next release comes out.
- Of course, I also talk about design topics and some of this process, as well as the patterns in the book Designing Mobile Interfaces.Be sure to visit 4ourth.com to read it online, and get updates, especially to the design and test resource lists. And, please add to the discussion if you have other information. This presentation is already up on Slideshare, so you can download it whenever you want. But now, give me a moment to browse the list of questions you may have today…