Executing for Every Screen: Build, launch and sustain products for your customers and business
•Als PPTX, PDF herunterladen•
2 gefällt mir•901 views
For the O'Reilly Webcast presented 10 July 2012 http://www.oreillynet.com/pub/e/2318
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Executing for Every Screen: Build, launch and sustain products for your customers and business
Ähnlich wie Executing for Every Screen: Build, launch and sustain products for your customers and business (20)
Mehr von Steven Hoober
Mehr von Steven Hoober (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Executing for Every Screen: Build, launch and sustain products for your customers and business
- 1. Executing for Every Screen Build, launch and sustain products for your customers and business @shoobe01 #float2012 1
- 2. Responsive design is wrong. And also, the best thing ever. 2
- 3. Responsive design isn’t new. • Fluid, liquid, elastic • Media queries • CSS • Percents and points 3
- 4. But that’s okay. • Buzzwords work • Design, plan, execute for multiple screens • Principles are sound 4
- 5. Device detection and server-side software. 5
- 6. RESS isn’t new, either. • Device detection • Customized presentation • Scale and chunk • More efficient for everyone 6
- 7. Build products for people. Not for platforms. 7
- 9. Which web? • Trends • Analytics • Familiarity 9
- 10. Why do I need two of these? 10
- 12. Know your market • Buzz is not data • Extrapolation errors • Tribalism and fanboys • Your analytics are probably wrong 12
- 13. You are screwing yourself. • Wasting time • Wasting resources • Missing opportunities 13
- 14. Fragmentation is great. 14
- 15. Design for every platform, and every screen. 15
- 16. 16
- 17. Design beyond pixels. 17
- 18. Avoid DIPs • Em and percent • Point • Inch • mm • Twip • Etc. 18
- 19. Respond to more than scale. 19
- 20. 20
- 21. Simpler: Link to email. 21
- 22. User choice. Contextually. 22
- 23. 23
- 24. Use device capabilities. 24
- 25. Create products, not projects. 25
- 26. Principles > Patterns > Templates > Pages 26
- 27. 27
- 28. 28
- 29. Features != pages • Features are features • States, views • Context and conditionality 29
- 30. First, ask questions. • What is the product? • What is the one main feature? • What problem does it solve? • Who will use it? 30
- 31. I don’t ask: • What platform? • What technology? • Is it feasible? 31
- 32. Get principles. Get buy in. Share with everyone. 32
- 35. Design for every screen. 35
- 36. Design for every screen. • Gather – Collect info • Define – Personas, objectives • List – All possible features • Filter – Keep only what you need • Group – Cluster and establish dependencies 36 • Prioritize – Earlier and higher, in
- 37. Then design for each screen. 37
- 38. Then design for each screen. • What platform? • What technology? • Is it feasible? 38
- 39. Design to make decisions. • Platforms and technologies. • Business rules. • Storage and transport. • Access and security. • Interoperability and legacy systems. 39
- 40. Customize each platform. • Do not degrade. • Do not enhance. • Never exclude or simplify. 40
- 41. Execute for every screen 41
- 42. Data and services first. • Design, plan. • Data and services first. • Then shared interfaces. • Prioritize major platforms. 42
- 43. Build for the future. 43
- 44. Be lazy, and cheap. • Build things once. • Fix things once. • Buy fewer servers. • Be stingy with data transfer. 44
- 45. Platform teams should borrow and cheat. 45
- 46. Multi-platform plans: • Serial. • Parallel. • Staggered. 46
- 47. 47
- 48. Serial • Slow. • Inefficient. • Loss of control. • Opaque to users. • Loss of marketing opportunities. 48
- 49. 49
- 50. Parallel • Resource strain. • Inefficient test. • No opportunity for changes. • Bugs re-appear. • Blown schedules. 50
- 51. 51
- 52. 52
- 53. 53
- 54. Staggered • Inherently multi-platform. • Shared features built first. • Formalizes collaboration. • Fewer bugs. • Easily traceable. 54
- 55. Living with your product. 55
- 56. Change happens • Bugs • Catastrophic success • Competition • Leadership direction • Constant improvement • Market pressures 56
- 57. Planning your second release. 57
- 58. Planning your second release. • Bugs • Catastrophic success • Competition • Leadership direction • Constant improvement • Market pressures 58
- 59. Stick to your principles • Enterprise principles. • Financial or sales targets. • Satisfaction, recognition, referral. • User needs. • Design objectives. 59
- 60. Listen. • Usability research • Analytics • Marketing research • Ratings • Reviews • Forums 60
- 61. Move carefully. • Do not over-react. • Understand the true scale. • Plan before committing resources. • Consider consequences. 61
- 62. Change your principles. 62
- 63. Plan and launch as you live. 63
- 64. Don’t copy anything I’ve done. 64
- 68. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 68
Hinweis der Redaktion
- Today I’d like to talk about a whole bunch of tactics, how some are good, some are bad, and seek to get to core principles. Then, we’ll use those principles across the whole scope of a project, from conception to maintenance, to get better outcomes, faster, cheaper and with fewer bugs.
- The first thing I want to talk about is Responsive Design, and tell you how you are probably doing it wrong. But also that it’s a terrific idea, and if you believe in it you are probably halfway to being really effective.
- First, it’s critical to know where things come from. Responsive design is just a term invented recently by Ethan Marcotte, to encompass some current trends. It reminded me right away of Fluid design from a few years back.But then I cast my mind back, and remember thinking the same thing in that era -- when CSS ZenGarden became big; that this was cool stuff, but not conceptually different than what we’d been doing for years. We did percentage tables, and framesets (god help us) from around 1997, in ways that are very, very similar to what is going on today with multi-screen design. As soon as CSS came around, we changed to scaling type, and used background images in weird ways to account for very, very different screen sizes on just desktop (and early laptop) computers. Hell, I applied for a patent on a funny button made of tables and styles, so we could feed it from datastores, and it would resize depending on the content and interface. It wasn’t granted, but we were able to do great work, under the same conceptual framework, long before CSS Media Queries.
- I do get a little annoyed by those who promote any of these trends as brand new thinking. But even when it’s an over-hyped trend, many of these do a service to the community.Trends in design, development, and processes, sometimes communicate good principles. RWD is very good in this sense, as long as it gets everyone away from one-size, pixel-perfect designs. Which… isn’t /quite/ happening yet. The new Dreamweaver, for example, has this very rigid framework where you pick a few sizes to be responsive to. Ennnnh. Not right, but okay. Better than it was. We’re getting there.The biggest tactical problem, is that this is so very focused on the client side.
- Especially for mobile, this is awful. You cannot send giant images and scads of javacript over to make it physically fit a featurephone screen. It won’t even bother to render. I can go on and on, but just take my word: for people who live outside of lower Manhattan, or downtown San Francisco, data connections matter, and HALF of them carry featurephones. If you use device detection, a tool like WURFL, and let it send the right content to the client, this solves everything, with much the same principles of design. Your same device classes can even work, you just push the intelligence back a layer, and make it more reliable.
- Wait, that sounds familiar. Yes, RESS is this concept, also with a new name. Buzzwords do their job. Trying to explain device detection was a total uphill battle until quite recently. RESS is one of those buzzwords that’s starting to work. It’s being treated a bit like early Ajax, where everyone is trying to copy the implementation. But eventually we’ll get to principles, and one of the principles to me is that it’s not just about the web. Many applications, and all webservices, are about connected data access. The same principles apply here, and smart companies are using platform-agnostic content strategies very successfully right now.
- They are doing it because they looked at their business, their competitors, saw the problems, and reacted to them. Not because they wanted to implement the best new technology, but because they wanted to remain relevant in their business, remain competitive and become more efficient and nimble. To be successful in this multi-platform world, you have to (briefly) ignore the platforms, and build products for your business, and your customers.
- When you sit down and decide to start building for mobile, the first thing you probably say is stuff like, “which platform do I launch on first?”I have to give this answer quite a bit, in some detail. I’ll skip most of the detail for now, but the short answer usually is: A website. For mobile AND desktop.Briefly: because it offers universal access; As method of discovery, and linking it provide a gateway to other products; There’s no barrier to publishing updates, so you can fix and revise easily; And most important to me, analytics. You get great data on who is using the site, and how.
- Even that leaves you some questions, or assumptions. What platform am I targeting on the web? And from experience and analysis I say that you choose from trends, maybe analytics, and familiarity. But this is all too often, terrible. Because statistics lie.
- These are both perfectly functional iPod Touches. I use them for test a lot. Why do I have two? Because this one only runs iOS 3.2. No better. TWO MAJOR VERSIONS behind the current, and three behind what a lot of us have.I had to buy the newer one because developers and marketing managers get bad info, and build for only the newest version of iOS.
- People choose easy paths, even if that is a lie. We can see from all the buzz, the marketing and the occasional stats like this chart, all iOS devices are the same. And that damned Android is /confusing/, what what the “fragmentation.” Lies and “statistical truth” (that distort the reality of a situation) about say, how fragmented Android OS adoption is compared to iOS, do not help. Not just in a journalistic integrity manner, but they make you believe lies about the world which make you take unproductive courses of action. http://androidandme.com/2011/10/news/new-chart-visualizes-android-fragmentation/
- I work in a lot of monocultures. The most common is the 100% iOS shop. Not just designers, but developers. Zero devices other than an iPhone, and usually the very latest model. And everyone reads the same tech blogs, and everyone sees the data. But their samples are wrong. Their shop is not representative of the city. Their city is not representative of the country, and the US is not the world. We all get blind spots for the competition; you walk through an airport and see only iPhones? I took a survey for a few weeks while traveling and encountered the normal regional penetration rates of all devices by just looking around. And my favorite is that even if you look at analytics, they are probably wrong. Look closer at the raw data. See that 37% that’s “no data” which your analytics team discards? That’s mobile devices that disregard your scripts or pixels and are not being recorded. If you see ANY figures that are massively out of whack with regional trends, you are wrong. 100% of the time I have encountered figures like the chart a couple pages ago, where 85% of the visitors are from one mobile platform, it’s an error. Maybe an insidious one, but you should be able to look at the data and know there’s no chance this is true.
- Of the last dozen or so apps I have worked on, for tech startups, or big corporations, exactly 1 has been targeted first to iOS. Not because the team all carries Android, and wanted to be contrarian, but because they looked at the actual stats. They look at good, well-run analytics from the existing products, or specifically launch their mobile product on the web first. They check market share in the region and for the audience they are launching in. And, let me be clear, this is out there: almost never do I have to push for this. Business owners are starting to get the idea of serving the customer, and making informed decisions based on real evidence. Platforms like Android and Windows Phone (of all things) are growing in development-manager mindshare. If you design based on perception, love, religion, or hear-say… if you build for one platform then expect to just sort of stretch to fit others, you are just missing opportunities.
- And, let’s be clear about why this matters. Even setting aside rates of use of alternative OSs today: I won’t even mention that half the smartphones in the world still run Symbian. Or that Blackberry still sells well in many markets. Or that more people subscribe to SMS news alerts, on their smartphones, than there are TVs in the whole world. No, instead, I’ll ask: Who thinks ubiquitous computing is more or less here? Essentially everyone in the world, in the next decade or two – everyone in the WORLD – is going to have access to a network connected device. Forget the question of whether it’ll be an iPhone. Will it even be a handset sized device? Will it be touch? Will it be /portable/? The iPhone is not yet 6 years old. We can’t predict 18 months from now, much less 5 years. Do you want to be playing catch up?I have been working this past week on a product related to smartphone users in Africa – they don’t have many now, so it’s early and we’re working on the future. One platform we’re building for: desktop PCs. As the continent becomes more connected, some of the people with smartphone purchasing power will be information workers. They will start having computers at their desks.Probably.
- But I don’t much care if I am wrong. Because I am using things like connected TVs, kids with connected portable game consoles, or even just desktops for the developing world’s new information workers, as stakes in the ground. Something to gather the ideas and get basic behaviors.The design itself of any product has to start at a much higher level. More WHY it is needed than HOW. You have to get to the user tasks, agnostic of technology, much less platforms. When you consider interfaces, you have to include voice, and sms, and posters and what is outside the system, so gets written on Post-Its.
- So, we’re going to design to lots of different sizes. This is real. Just the new Android devices from the first quarter of this year or something. With no repeats. This is not pixel dimensions, but actual sizes. Note the different aspect ratios. And double this, as they all flip to landscape. Quadruple it when you get to TVs, and add in a few more OSs.Wait, did I just say screen size? What about the resolution?
- Who cares? Your finger cannot be measured in pixels. I have no rulers graduated in pixels. My eyeballs, much to your surprise, see photons, not pixels. Once you get past the wonderment of your sharp display, it doesn’t matter. What matters is physical size, and distance from the device. For viewing. For touch, just size. This is so important, I have stopped carrying random rulers, and recently made up a tool just for measuring things like touch targets on mobiles. >>> (Buy the template I am referring to here http://4ourth.com/wiki/4ourth%20Mobile%20Touch%20Template)
- Device independent pixels, are /okay/, but just okay. It’s, conceptually, philosophically, a cheat for the reality-challenged. And, there are serious pitfalls with inconsistent use and (for the web) communication of scale ratios. And in one that annoys me, Apple calls their DIPs “points.” But a point is a real, and useful unit of measuring type (text). Apple’s “point” is nowhere near this size. This makes just promulgating standards a bear. Previously, every OS I’ve worked on supports physical measurement sizes at some level. Even if you have to do the tedious math to convert to iOS’s DIPs-only thing (Android totally supports other measures), do make common specifications in real sizes, based on users, and their needs. Ems are great (“you say it “e m” but it’s “em”). The baseline size is 16 pt, but you can change that. Use any other physical sizes if you want specific sizes as well. Skip the cheats and prayers for automatic scaling. As much as you can, start designing for the real world.
- The responsive principle is still solid, especially when you use RESS and device detection to load the right content from the server.
- But now, you also need to design your features for the way people use, and expect to use, their products. This is a pretty typical chunk of an IA document. The way a user flows from one screen to another through a system. There’s a requirement for email in the mobile app, so we put in an email page. And a confirmation page. And so on. Easy.
- But smartphones have email. Sure, desktops do to, but they are stupid. They forget who you are, launch the wrong email client. Forget context and cannot pass much info. Mobile users expect this behavior instead.
- Mobiles are mostly pretty smart. They remember you. They pass this state between services. You don’t even always have to code in what the action is precisely, email or sms. You can just put a “share” icon into your app. Sometimes, into your website. And so users expect some variant of this, now. The user gets to pick, sometimes, depending on the platform, what they want to do with the information.
- So, you can meet that same feature, with a lot less code, a lot less to test and go wrong, and you can better meet the expectations of the end users. Hell, you can drop maps and directions, and local weather, and offer links to other products on the appstore and… lots of things.
- Believe in mobile. It has all these capabilities, this intelligence and contextual awareness. Use these.
- But use them only on mobile. Use the right features, on the right platforms. Do different things on desktop, or kiosk, or IVR.
- I think that you can break down the concept of a design in this order. Principles at the highest level, from which you can derive applicable patterns, from which you make templates specific to your product, and then build pages (or screens, or views or states) with the actual data and interfaces. Thestate of responsive design (and all the related concepts)today is at the page or template level. Maybe, if lucky at patterns.We need to move the discussion to principles; to design architectural solutions for each platform. Because we need to extend these principles to items that are not just served up at the moment, but to the way we design and build packaged products: applications.
- But I am sure every project you have been on declares there’s no time. Or, doesn’t even have the time to declare anything, and just shortcuts process by default.Someone dreams up a few requirements, someone else expands on them with the goal of making it, as fast as possible. And so is born a project, based on those comfortable assumptions of platforms. And each requirement becomes a feature. And each feature becomes a line in a spreadsheet, or a card on a wall.…
- And you end up with hundreds of requirements, even for simple, one-off projects .If anyone is happy with this state of affairs, I’d be surprised. How do we solve this?
- Well, step back from your regular process for just a minuteWeb design made us all lazy, and states don’t exist anymore. It’s all pages. To the point that it’s hard to find a quick-and-easy prototype tool that supports something as simple as a popup, or accordion. And so… apps get developed that are nothing but pages swiping to other pages.
- For starters, you cannot start like this. First, ask questions. Ask your project team. As the UX guy, I am often brought in quite early, and have an almost built in chance of success. But if you are a development manager, or BA or technica architect, and you get a vague, one-line project description, just go find the product owner and ask what they mean. I have a formal questionnaire, and ideally do these workshops for at least half a day, but can get by with SurveyMonkey, or even email. You’ll also notice that the root questions I am asking, the principles behind them, are not dissimilar from concepts of Product Development, or Service Design, or any number of other fields. I find this to be a nice proof of the principle that principles are easily shared, so everyone on the project can work well together, and should agree we need this information.
- Note, I didn’t ask what platform they use, or how we’ll build it, or anything along the lines of technical feasibility. In fact, we don’t get to that decision point at all. Yet.
- From this what we do get is principles, and measureable goals and objectives. Don’t forget to build in the analytics or whatever other tools you need to prove the goals are met, by the way.Don’t keep these objectives secret. Collaborate on development, share with the team, get everyone to sign off, and then keep sharing. Include in the front of documents, stick them on the wall of team rooms. As new team members arrive, they have a chance to know /why/ this project exists, and won’t write code in a vacuum. This can be a great way to be agile (with a small “a” at least). When a designer sketches a solution, or a gap is discovered, the developer has a much better chance of understanding, and coming up with a solution that fits the rest of the product on their own.
- Because what we’re going to do, is design. And we’re going to design a systems solution. Not a project, but a system, which will touch whichever interfaces it needs to.
- Design gets a lot of people hung up. In the general world, “design” without context means “interior decorator” more than anything. To too many technology folks, it means a job more or less like mine appears to be. The presentation layer. But it’s not. Look at what a good software team does before they get to work. Or, what a good DBA spends 90% of his time doing. It’s design. Sometimes, explicitly called that, and I think it should be called “design” a lot more.
- Okay, now that’s out of the way, once you have principles, you should start design. Which, clearly, I mean with the whole project team. My ideal again is to sit down in a room with everyone, and bring up the principles, the original concept and talk about what can be done. This freaks out a LOT of development teams. Most, I’d say. Much more often than not, so much so they don’t even know what I mean, and refuse to entertain the process. “You give me the design, and I’ll estimate.” The problem is an assumption, not just that they cannot make decisions out of the blue, but that everything is very ordered. That we have a platform; usually a default like the desktop web. So, all you do is take the requirements, and make pages that meet those requirements. Then development tells you how hard it is.But that’s wrong. It’s, in fact, backwards. Instead, we need to take the principles, objectives and the dreamy ideas for the product, and just put it all out there. If it’s a likely feature, and technically possible ON ANY PLATFORM, put it up. Yes, maybe on the wall of a hundred cards. You are designing not a website, but a technical product, so think about the services, the underlying systems, the touchpoints. Then perform EVALUATION PROCESSES to determine what features are needed, and draw out processes where the user walks through the system, to determine the relationship between features, across ALL platforms.
- I like to call the process and output off this whole phase a Blueprint. Like a building has a blueprint as a stack of drawings about the whole thing, plumbing, electrical, mechanical, structural, etc. We design with increasing specificity, but start by being platform independent.
- When you start to branch the design to platforms, interesting things happen. And they aren’t all about reducing the content for mobile. They are about using the capabilities I just discussed a few minutes ago. It’s common to say that mobile is limited, compared to desktop, because it’s smaller, harder to type on, and so on. I like to say mobile is better, because of the sensors, and some general focus on the user and identity and network connectivity. But let’s say instead: every platform has it’s strengths.
- At this phase you are making wireframes, and other design specifications, and functional requirements documents. Design re-Filters – to decide what cannot, and should not be in a particular platform.Branch – to make an executable architecture or flow document.and Optimize – the interaction, and interfaces for the platform. Development is planning, to decide for each platform what is feasible, how it will be built, and how long it will take.
- But how do you decide big issues, like what platforms are first? It might not be such a simple decision as “web, then OS-that-visits-the-most.” This is, often, an “organic” decision. The design itself should lead you. I am working on a project right now that’s a very simple example. It’s got no web interface. Because it’s about being used places like down a mineshaft. Seriously. Network connection at the moment of use doesn’t matter, so local storage rules the day. So, it’s a CD, a paper catalog, a desktop website (for use back in the office), and a mobile app. Only. And as it turns out, we can’t make these decisions without some design. We can’t do them at the corporate planning team level, at the finance level, at the steering committee. The ITPM, and technical architects can’t make it. If you need to build products for your company, and your users, the driving force has to be making it useful for them.
- As you do this, some of the buzzword-worthy principles I haven’t mentioned yet will fall by the wayside. You cannot consider graceful degradation, or progressive enhancement to be true. Except in very specific domains. Does it support /this particular javascript function/?You cannot cut down features for the mobile, for example. If it’s needed, it’s needed, and there’s no step where you say “well, what goes on this screen /because it is small/.” Decisions on features and behaviors are so much higher level, you can avoid these pitfalls. When you are considering how to fulfill the features needed on each platform, in their most native way, it’s hard to say one is better, or worse. Or that one is a degraded experience. You can not enhance progressively, moving up the platform chain, but provide the best experience for each platform in turn.
- Implementation is a key part of this whole process, and not just because it is how the product gets to the end users. I mean here, including implementation considerations and implementation team members in the design and evaluation steps.Note that I hesitate to say "development." It's best to raise that up a level, and discuss how the product will be built, hosted, released and maintained in the same breath as how it is designed, marketed, sold and paid for.This might seem like the same argument I have been making about designing the whole product, then designing individual parts. Because it is.
- So, how do you implement this for multiple platforms if they are so customized? Well, the same way we did the design. From the top down. First, design. Plan, if that works better. Ideally, you’ve been performing software and storage design all along. If not, do it before coding. Then, you build core functions first. Long before you build UI. Practice layered development, and build the datastores, backend software, business rules and methods to access these.The first interfaces, ideally, will be shared items like email…
- … which will work with every platform. If you have even a glimmer in your eye (much less actual plans as I’ve been discussing) that this product will expand to other platforms, you cannot bake the software into the first platform’s presentation layer, or build one-off calls to the datastore. You have to build for the future, so each platform can use it.Even platforms you haven’t considered. And, if you do this remotely correctly, you don’t need to predict the future as well.
- And if the philosophical underpinnings, or hope for the future won’t work for your management, how about the efficiency? Absolutely, more efficient use of development resources. If we don’t have to touch each bit of code with every bug, with every platform team, with every release, that’s great. But think more broadly. How about hardware and configuration efficiency: there should be one datastore, not synching, and one service call that everyone shares. Build it once.And even more, data transfer efficiency: Put as much processing on the back end. Put intelligence next to the data sources, or at least on cheap, high-speed pipes instead of sending them over the radio. You just send to the device what is needed. Remind anyone of some principles I talked about earlier? Anyone of sufficient scale can easily save MILLIONS of dollars by reducing the data transfer. Of course then the app should be faster, and there is less of a security risk on the client side, and so on.
- Anyway then are ready to build the presentation of individual platform codebases. These will take advantage of not just the UI and interaction differences, but the common service and data framework, and the available tools and processes of the client platform. Whenever possible, inherit features, or use default functions. I’ve seen ugly but running complex products built in a day. But it took weeks of software development before this. Individual platforms you say? How many of you launch, at more or less the same time, your product on several platforms? You do the web, iOS, Android, Blackberry even… So, doesn’t juggling all this get all out of hand in a big hurry?
- Well, if you don’t plan well. The next step in designing a customized experience for the whole product, and each platform, is making sure your /process/ is designed equally well to take advantage of the unique needs of the product, and capabilities of the team. 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. 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.
- Serial is the default non-process. When an organization fails to specify the platform, because everyone knows it’s the web, and then makes a special project 3 months later to build an iPhone app, that’s really just the product continuing with a willy-nilly lack of process and is where you see these confusingly slow and irregular multi-channel products come from. I think there is a way to make it work well, but the way business runs, the delays between individual projects or phases seem to always blow the plan.
- 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 core issue with this is of resource strain. The biggest is on the core team members, the designers, product owners, and lead technical personnel (like BA) who try to provide oversight. But even line developers can be overloaded. Not just for the pressure to meet deadlines, but as they or the management starts to see slips and gaps they try to fix by coordinating with the other teams. Which is irregular, takes lots of time, and results in more slips to the original plan. Overall, you end up with less than you wanted to launch, late, and full of bugs. You will tend to fall back to Serial mode, platform by platform, as you try to fix things.
- The one I’ve been pushing 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 the first platform is indeed “Shared Services.” 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. They happen very early in the overall implementation cycle, 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 on the earlier platforms. And if bugs appear, they are on lower-priority, lower-use platforms that can be held, or where the bugs can just be lived with.
- This meets your larger goals of fewer bugs, and more output for fewer resources. Tactical implementations are left for each of you to consider in your organization.This works, as it’s inherently multi-platform. You are no longer fighting anyone on the team, or the inherent nature of multi-platform development. It becomes at least passive, and maybe an asset and a way to prime communications and collaboration between the platform implementation teams.
- After you launch, you have to live with your products. At least for months, and if not you then someone is going to have to live with it for years. So, one of the best questions I’ve had in a presentation over process is how you plan for subsequent releases.
- It’s good, because it’s another of those core principle things, where the answer is complex. Because it’s not just about deliberate second releases, but bugfixes, people changing their minds, or even the general concept of continuously improving your product.Not to mention that the technical landscape is always changing, so you need to be updating regularly to make the most of new technologies, new platforms and new user expectations.
- But let’s narrow to something you can plan on, more than mid-stream changes or a whole lifecycle. What causes second releases?
- Well, the same pressures as all these others. Unpredictability and product pressures. We can’t predict everything, so make guesses and compromises to meet some reasonable expectation of a date. Then launch. We’re left with a pile of features, but that is not what gets launched as the competitive landscape changes. Or user feedback is different. Or some executive has another good idea. How do we solve for those?
- The same way. Stick to your principles. When I talk in detail about the design process I call Design for Every Screen, a key feature is that the Blueprint is a “target design.” Meaning, a vision for a perfect, fully-featured product. Which none of us expect to get any time soon. We will get some subvariant of that, and work towards the rest. Story backlogs (and other such future feature lists) are a less-holistic version of the same concept. So first, go back to the list, and start filling in what makes the most sense
- Then add to these, by listening to your users. Don’t let anything be over-weighted, and try to use good science to tell what is really happening. If you get a bad review, don’t worry about it, unless analytics bear it out, and user research explains clearly /why/ it’s a problem.If you get all 1 star reviews, for a key missing feature, or that it’s very slow, that’s your new priority.
- But do not panic. Just like you stop for a minute when first building the product to decide what it should do, here take no reactionary moves. Analyze. If it’s not clear, get more data. Consider tangential solutions, as when originally designing: if the surge of protest turns out to be a disaffected 1%, the solution may be more about marketing than product changes. Develop plans. Don’t let executives push you in random directions without understanding why. Consider the consequences of change. Satisfying 1% or 10% may be wrong if it alienates 80%. This does not mean to react slowly. In fact, all this process can be faster than rushing all the time, as you move CAREFULLY. Your actions are measured, and efficient.
- So, what if the executives come down with a new mandate? Not “make it blue” but “now it has to sell online.” Or the customers all demand that they be able to comment, but your strategic goal was to integrate with Facebook. These disagree with your goals, or design principles. What to do? Change your principles. This can even happen during the original launch, and most of the time they are much smaller changes. Remember how I said you reach platform and technology decisions organically, by designing? Well, the same happens here. Sometimes, the concept seems good, but details change it. Don’t get a bigger hammer or sweep the gaps under the rug. Address them, and if everyone agrees then change the principles as needed. Then, distribute the changes, and take a new look at the whole product in this light. Does adding a “comment” link at the bottom of the article page meet the true user goal, or would a “Comments” section, and sidebar, be more the right speed? Yes, very often these are fairly serious redesigns. But don’t let that scare you, as you are going to make the right product.
- Process-wise, I’ve been asked if the staggered approach still works. I tend to say “yes.” Because the principle is solid. Not the development efficiency principles, though those work, but the product-centric, platform agnostic principles. If you fix up one, but not the others (barring bugs unique to a platform) then you are admitting that they can deviate in features. Is this what you want? Do you want to explain to your mom why your phone does something, but hers doesn’t? Think about the longer-term lifecycle. If you chose to launch everything together at first, then you are considering the whole product as one. How does an update of the iPad app that leaves behind all handsets and the Android tablets serve the single-product vision? It depends. It’s not a strict rule. Your needs, and your internal goals and objectives will tell you. But you MUST have one /plan/ and not let it get out of control, or be driven by technology needs entirely.
- When I say that there are no hard and fast rules, I mean it. Don’t copy anything I have done. Well, not exactly.
- Design… makes choices based on good principles,…develops or uses patterns based on user needs and business goals,…and builds solutions based on schedules and business or technology limits.
- Your processes should, likewise, correspond to your organizational culture – or that of your clients, your needs as a project team, and the technical or business-process limits of how it’s integrated into the rest of the organization. Design and implementation processes should always be improving. Not just following trends blindly, but picking up the nugget of a good idea, and applying that when it works for your organization, your process and your project.
- So, since I keep saying “principles” here’s the best I can do to narrow them down to pocket-sized:Be RESPONSIVE –> Actually multi-platform. And from the server level, not just the presentation layer. Be NATIVE - > Use device capabilities, way past reacting to size. Build for PHYSICAL use - > Design to the user’s scale, using real world sizes and real-world interactions. Design BUILDABLE products - > Implement the way you design, and design in ways that can be implemented. Execute in EXENSIBLE ways - > The core of your product is probably data, so design and build generalized, reusable components and services.
- I hope there are questions. Ideally, very detailed or technical ones.