Executing forEvery ScreenEmbracing everyone’s limits toexpose you project’s strengths@shoobe01   #d2wc                    ...
UX thinks:            Developers think:Principle of Most Time:   Every product we buildThe most elegant and       is a pro...
No more hand waves                     3
Shared principles•   Modular•   Iterative•   Incremental•   Patterns and best practices                                  4
ModularImplementation:                      User Experience:Good programming principles          We don’t draw every page ...
Iterative Implementation:                    User Experience: Start simple, learn as you go      Review designs internally...
IncrementalImplementation:                    User Experience:Assigning developers one task      Conceive holistically, bu...
Patterns & Best Practices Implementation:                    User Experience: Apply existing knowledge and re-   Speeds wo...
Coordinate to collaborate                            9
Planning for multiple platforms                                  10
There’s no time• There’s plenty of time• Scale the engagement• It pays off in the end                           11
Design for every screen• Gather information• Design for users, tasks, and goals• Make n assumptions about single technolog...
Constraints              13
Development scales well                          14
But the core team…                     15
But the holistic team…                         16
Blueprint            17
Branch design to each platform                                 18
Serial         19
Parallel           20
Staggered            21
Operationalize your process                              22
Steven Hoobersteven@4ourth.com+1 816 210 0455@shoobe01shoobe01 on:www.4ourth.com                    23
Upcoming SlideShare
Loading in …5

Execute for Every Screen


Published on

There are several ways that current development processes can miserably fail users and the business when trying to launch your project on multiple platforms. Massive changes, blame, or simply not understanding your missed opportunities, are the usual results. 

The answer is not any of these, and certainly not to try to impose a new process. Instead, encompass all the existing processes to create a new philosophy of implementation. Avoid pitfalls and gaps, and play to the strengths of your team to operationalize a functional design and development processes. 

Steven will talk about methods he's devised and used with business, analysts, and developers that make everyone happy and help assure projects actually launch. 

Presented at D2WC in Kansas City on 17 March 2012

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • I have talked a lot before about the principle of making sure that what you get built is what you intended. And I don’tjustmeanfrommy point of view, the dreamydream of the UX Designer types, but what the user needs to make sure the business succeeds.I like to call this things like "user centered execution" to remind us all that there are user and business goals behind all the pretty pictures and clever code.
  • To get to this point, everyone needs to work together.This is not just a pithy little statement about collaboration, and getting along. No, I mean that our processes often go together a lot better than you'd think. Take UX and Development individually: We aren't at odds except by tradition. Check out these quotes:UX people (but not me!) think: “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.Developers (all too often) design for themselves, not for any class of end user at all. And along with that, they reject the entire principle of UX design, or any design, as opinion.
  • But this is all based on false assumptions that other teams are malicious or irrelevant. Once you take time to look at them, philosophies, practices and processes can actually mesh quite nicely. Gaps or weaknesses in practice area are almost always strengths in the other.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. A simple example is to ask “Where did all these cards come from?” How do we know the features of a project useful, or the most important ones are being done first? 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. Collaboration doesn’t mean /everyone/ does every, single, task. It’s sharing, accepting input and letting people do what they do best.
  • And this works well, because 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 Design and Implementation organizations.
  • 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 efficient 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 individual components 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. We build designs component by component, review, and move to the next component; we can even split large projects among a team of designers by assigning components.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, and re-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 re-usable components.(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.)
  • Very simply, we can coordinate these similarities in our processes to collaborate on the work more deeply than you might be used to. Collaboration starts at home. Don’t wait for someone to say you have to work together, or have meetings about how to work together. Start putting drawings, concepts and principles on the wall. Invite everyone who might possibly care – from business to execution – to come see and comment. If possible, actually perform workshops and formally gather feedback. Include process diagrams and schedules. It makes you look serious about execution, and even if someone disagrees it starts the conversation.
  • So, let’s skip a bunch of steps, and for today assume you are lucky, and your business or client is somewhat with the times. Your project or product is totally going to be on multiple platforms. Say, mobile web and two or three apps. And, you have at least a little time to perform design tasks, can talk to the development team (or at least, with the onshore representatives for the developers) so you can coordinate processes and get a baseline built and agreed upon.Actually, let’s stop there for a minute.
  • Remember the three legs of a project? IT and PMs live 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 (secretly) 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.
  • - Whatever you call it, whether you take the time or are given it, I find the best way to get good outcomes is to perform some level of holistic, system-wide design before too much work is done on planning and estimation, not to even mention development. - I call this "Design for Every Screen," and actually do design for everything at once. By designing for nothing at all. - Understand the problem, the business, the goals, and the users and their goals. - Design the process. Even if out of scope for now, consider the whole system, including data structures, and cardboard boxes and bits of paper at call centers. - Do not design for any one device, or technology, but DO design for all of them. If your scope includes desktop web and call centers and mobile, then you can design so customers contact via email with attachments, voice and SMS as they see fit. - THEN, when the system-wide flow makes sense, start specifying specific interfaces and interactions.
  • As I have already mentioned, we are always beset by limitations and constraints on time, budget, manpower, and vision. If you only work for internet startups, good for you. But most of the world is adding or updating the technology for business that have been around more than 6 months. And then you need to work with legacy technical systems, training, advertising and marketing… when the company has bought 5 million in advertising on Superbowl Sunday, for example, you better make the launch date. Okay, I have even worked for internet startups. And you know what? They all become boring old companies with call centers and legacy systems. To monetize, they often end up integrating with other services, maybe even really sad ones, like Fax or /email/. But today lets assume that everyone agrees in principle, and wants to make the product for every platform your users actually employ.Then your biggest constraints end up being time and manpower. And maybe not in the way you'd expect.
  • Implementation resources can scale nicely for this. Whether hired, onsite or totally outsourced, you can get qualified developers relatively easily. Sure, there are constraints on scaling /ONE/ implementation team. I totally believe that it takes from 1 to maybe 5 developers to build any single software product. And adding resources can be disruptive. Adding more, is more disruptive, until you get to the point zero work is done. But for multiple platforms, scaling to multiple teams is a great solution. Each team builds a platform.And even for a single platforms… you are fooling yourself. There is no single platform, at least for network connected tools. Data storage, middleware, connectivity. These are not the same as the software development team, which MAY not be the same as the presentation development team. Don’t let bottlenecks emerge in implementation that don’t have to; explore the real needs and processes of implementation.
  • A lot of businesses call the rest of the project organization the “Core Team.” This is not my preferred term, as it implies things that aren’t helpful, and fails to imply what they really do. I might call it the “Holistic Team.”
  • This is UX of course, but also all the business representatives, and any platform agnostic I.T. people, like the data architects I was just discussing, development managers if you can get them, and so on.Alimited number of people can hold these roles, attend all the meetings, hold the whole project info in their heads all the time. Because everyone else has to be free to do the implementation work. Though I won’t talk about that too much today, not /everyone/ on the business or design side is on the holistic team; Aside from scads of SMEs pulled in occasionally, there are production staff as well, who have to be allowed to go off and draw or type or coordinate or review. Anyway, if these people hold the project in their head, and meet all day about it with each other and the production or implementation teams, it also means they can only do so many tasks in a day.
  • So, combining these concepts, thiswhole team works at the holistic, system-wide level first. For UX, I call this this first real design document a Blueprint;We make a diagram like an IA (and some example UI, and explore some interactions, etc.) but with a focus on everything. We consider the series of tasks for the whole system, before we get to specifics. The entire team is engaged on this to assure it’s right for users, the business, the timeline and the budget. And, you don’t need to wait on this to be done. Once some stuff is defined, the architect (or dev managers) are specifying and designing datastores, services and other components needed on the back end, and /shared by all presentation layers/. See, not only is it not-insane to design for every screen, it's needed to assure you have the right requirements for the estimation and technical design.
  • But then, before development begins on any one interface, we branch the design -- both the UI and any software design – to make it specific to the needs of the individual platforms.Dev builds software, linkages and presentations to these design.The core team monitors this build, clarifies and approves as development proceeds.
  • But this is a key gap I’ve been increasingly discovering, and working for. HOW does development engage? And I don’t mean development process. These ideas are all process-agnostic. I have seen the good and bad happen in “waterfall,” spiral, Rational, Agile and several others. Note in fact that in these diagrams,the UX and other design/specification phases are pretty short. Need a design and in a week or two? Well, we justhave to bang it out. So, while working on the best way to use those constrained resources, I’ve determined there are three basic ways to engage everyone on a multi-platform product. The first is Serial. You do all the stuff I said already about collaborating on the concept and blueprint level design. Meanwhile, development starts specifying then building core services. ANIMATEThe first platform documentation is finished, and dev is sent out to build it. You accept it, fix bugs, launch it, see how everyone liked it, then decide that maybe another platform would be good, so go hire another developer (as the first guys are really, really iOS guys) and the new guy fights with the old developers, and so much time passes you really want new features, so have to do more design work, and… Well, maybe someone buys you for a billion dollars. But mostly, you miss opportunities for more users, and get lost in the weeds as the years pass you by.
  • The parallel path is the typical alternative response. And the standard way to react when the business insists a product has to be released at a specific time. “All hands on deck” and so on. Usually, after a bad release or two, I can successfully argue for the “delay” you see here where we actually take time to plan. This is better covered in some of my other process presentations, like how to integrate Agile and UX. Briefly: it’s the same thing I am saying here. There’s no argument if you back up and look at it, as there’s already planning time, so just do actual codified planning and design work in that timeframe. Anyway, jumping forward, you see that the UX design, business monitoring and (if you are so lucky) usability research are on each and every track. This all leads to two possible outcomes: The core team tries to cover all the bases, totally can’t, and development gets by with approval-by-Powerpoint. Even if not literal, anything shiny is approved, and actual problems are masked. Development makes all tactical decisions as problems come up, mostly with the intent of making them good enough to pass review. To solve this, maybe for the next release, the Core Team assigns subordinate product owners, UX people and so on to each track. But then there are too many subordinates, and they spend so much time solving the problems of their track they make individualized decisions, and the platforms deviate. Either way, the deviation from plan is often Very Bad. Not just in UI consistency, but in a technical sense. Everything gets built as needed, very often to the point that middleware starts having custom variations per platform. Or, each platform has it’s own datastore, and you are lucky if they synch. Oh, and if that’s not convincing, it’s still massively inefficient. Everyone has to discover the same pitfalls and solutions themselves as there is no time or simple way to share findings. You will end up launching products that are not well-customized to the platform UI, have bugs, and expose gaps in expected functionality.
  • The one I’ve been proposing for a while, is the Staggered approach. Apparently this is shockingly unique, as I keep finding development managers who have never seen anything like it. Resources, software design, business oversight, and UX work hand in hand, both from process and resource availability points of view. You generally still engage a team per platform (though sometimes you can recycle part or all of a team if that’s your way), but staggered starts mean there are efficiencies, as every subsequent team can learn from the mistakes already made, and re-use work already done. Note that I like to consider backend functionality (or as I call it more broadly here, “Shared Services”) as it’s own platform, with it’s own earlier start. It has a team, and must be started first to set the baseline environments. Treat it like the core of your product, as it is. The highest priority platforms go first, and the risk of them finding errors is entirely counter-balanced by the much, much longer QA time. User research and longer acceptance testing can also be implemented in the first platform or two, and the general learnings applied to the others. Overall, later platforms should be much easier to implement on, even if they are 100% new presentational codebases, as the software, architecture, algorithms, content, and much other work is entirely done.
  • You might have been taking notes or twittering about this as "tactics" to bake design into the development process. But it's not tactics. Organizational planning goes Strategy > Operations > Tactics. And this is at the Operational level. Operational plans are detailed, but repeated, and flexible. While not a perfect analogy, patterns are operational, templates are tactical. Here on the board, we’re planning the detailed design (and some implementation) work for [a product]…The line items, boxes and little arrows are all tactical-level tasks. After this, we went through and attached dates…But the the big columns I wrote up top, and the siloes the items live in, are the operational plan we decided up front to hew to. And, it is very much this sort of plan I outlined today:Make sure we have the vision for the product.Get the highest level process flow in place, so we have data in and out of the system, and between platforms.Start defining the widgets to build for each platform. Figure out when we can get prototypes built to test the first versionAnd so on… Operational level understanding is not just the right wayto think about it, but implies that it is process-oriented, and becomes something that can be done repeatedly, that improves over time, and which fits into your other processes. Whether you use any of the process or methodologies I just outlined, or just take the concept of rethinking your approach to integrating the team, and working multiple-platform projects as single efforts, please at least consider that any changes need to be organizational and operational, so everyone uses them, and improves on them over time.
  • I hope there are questions. Ideally, very detailed ones on your process.
  • Execute for Every Screen

    1. 1. Executing forEvery ScreenEmbracing everyone’s limits toexpose you project’s strengths@shoobe01 #d2wc 1
    2. 2. UX thinks: Developers think:Principle of Most Time: Every product we buildThe most elegant and is a product we buildsimple solution to any for ourselves to solvedesign problem will be our own the one that requires problems…making the most developer decisions based on effort. real opinions trumps making decisions based on imaginary opinions. 2
    3. 3. No more hand waves 3
    4. 4. Shared principles• Modular• Iterative• Incremental• Patterns and best practices 4
    5. 5. ModularImplementation: User Experience:Good programming principles We don’t draw every page and(whichever you embrace) state independently, but considerencourage re-use, consistent the design holistically, and drawnaming and resource many items to be used acrossallocation, and using the simplest the product.solution.Re-usable components make work quicker and more efficient, morerepeatable, easier to understand for regular teams and easier toimprove or fix. 5
    6. 6. 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, butimproved on and expanded to become better and more capable. 6
    7. 7. IncrementalImplementation: User Experience:Assigning developers one task Conceive holistically, but designhelps focus, and allows the team in easy-to-manage chunks. Splitand management to track the work to who can bestprogress, and further split (or perform the work, and deliver incombine) work as needed. pieces if needed for speed.Resources – both people and time – are limited. Deliberately breakup work in an ordered manner for management, and coordination. 7
    8. 8. Patterns & Best Practices Implementation: User Experience: Apply existing knowledge and re- Speeds work and constrains the use known good solutions, but problem space with , extend and combine to meet libraries, patterns and stencils. the system needs and project Analyzes or researches to find goals. the best solution.All of our work builds on history, knowledge and evidence.But watch out for best vs. common practices. 8
    9. 9. Coordinate to collaborate 9
    10. 10. Planning for multiple platforms 10
    11. 11. There’s no time• There’s plenty of time• Scale the engagement• It pays off in the end 11
    12. 12. Design for every screen• Gather information• Design for users, tasks, and goals• Make n assumptions about single technologies, interfaces or platforms• Create a blueprint of the whole service… then branch out• Design to target (end goal) experiences 12
    13. 13. Constraints 13
    14. 14. Development scales well 14
    15. 15. But the core team… 15
    16. 16. But the holistic team… 16
    17. 17. Blueprint 17
    18. 18. Branch design to each platform 18
    19. 19. Serial 19
    20. 20. Parallel 20
    21. 21. Staggered 21
    22. 22. Operationalize your process 22
    23. 23. Steven Hoobersteven@4ourth.com+1 816 210 0455@shoobe01shoobe01 on:www.4ourth.com 23