Downloaded 23 times
Uploaded bySteven Hoober
Executing for Every Screen: Build, launch and sustain products for your customers and business
The document discusses principles and best practices for designing products and interfaces that work across multiple screens and platforms. It emphasizes starting with principles, designing for user needs rather than specific platforms, building shared features and services first before customizing interfaces, and continuously evolving products based on data and user feedback.
More Related Content
Similar to Executing for Every Screen: Build, launch and sustain products for your customers and business
More from Steven Hoober
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 iswrong. And also, the best thing ever. 2
- 3. Responsive design isnātnew. ā¢ 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-sidesoftware. 5
- 6. RESS isnāt new,either. ā¢ Device detection ā¢ Customized presentation ā¢ Scale and chunk ā¢ More efficient for everyone 6
- 7. Build products forpeople. Not for platforms. 7
- 8.
- 9. Which web? ā¢ Trends ā¢Analytics ā¢ Familiarity 9
- 10. Why do Ineed two of these? 10
- 11.
- 12. Know your market ā¢Buzz is not data ā¢ Extrapolation errors ā¢ Tribalism and fanboys ā¢ Your analytics are probably wrong 12
- 13. You are screwingyourself. ā¢ Wasting time ā¢ Wasting resources ā¢ Missing opportunities 13
- 14.
- 15. Design for every platform,and every screen. 15
- 16.
- 17.
- 18. Avoid DIPs ā¢ Emand percent ā¢ Point ā¢ Inch ā¢ mm ā¢ Twip ā¢ Etc. 18
- 19. Respond to morethan scale. 19
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. Create products, notprojects. 25
- 26. Principles > Patterns > Templates> Pages 26
- 27.
- 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 buyin. Share with everyone. 32
- 33.
- 34.
- 35. Design for everyscreen. 35
- 36. Design for everyscreen. ā¢ 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 foreach screen. 37
- 38. Then design foreach screen. ā¢ What platform? ā¢ What technology? ā¢ Is it feasible? 38
- 39. Design to makedecisions. ā¢ 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 everyscreen 41
- 42. Data and servicesfirst. ā¢ Design, plan. ā¢ Data and services first. ā¢ Then shared interfaces. ā¢ Prioritize major platforms. 42
- 43. Build for thefuture. 43
- 44. Be lazy, andcheap. ā¢ Build things once. ā¢ Fix things once. ā¢ Buy fewer servers. ā¢ Be stingy with data transfer. 44
- 45. Platform teams should borrowand cheat. 45
- 46. Multi-platform plans: ā¢ Serial. ā¢Parallel. ā¢ Staggered. 46
- 47.
- 48. Serial ā¢ Slow. ā¢ Inefficient. ā¢Loss of control. ā¢ Opaque to users. ā¢ Loss of marketing opportunities. 48
- 49.
- 50. Parallel ā¢ Resource strain. ā¢Inefficient test. ā¢ No opportunity for changes. ā¢ Bugs re-appear. ā¢ Blown schedules. 50
- 51.
- 52.
- 53.
- 54. Staggered ā¢ Inherently multi-platform. ā¢Shared features built first. ā¢ Formalizes collaboration. ā¢ Fewer bugs. ā¢ Easily traceable. 54
- 55. Living with yourproduct. 55
- 56. Change happens ā¢ Bugs ā¢Catastrophic success ā¢ Competition ā¢ Leadership direction ā¢ Constant improvement ā¢ Market pressures 56
- 57. Planning your secondrelease. 57
- 58. Planning your secondrelease. ā¢ Bugs ā¢ Catastrophic success ā¢ Competition ā¢ Leadership direction ā¢ Constant improvement ā¢ Market pressures 58
- 59. Stick to yourprinciples ā¢ 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. ā¢ Donot over-react. ā¢ Understand the true scale. ā¢ Plan before committing resources. ā¢ Consider consequences. 61
- 62.
- 63. Plan and launchas you live. 63
- 64. Donāt copy anythingIāve done. 64
- 65.
- 66.
- 67.
- 68. Steven Hoober steven@4ourth.com +1 816210 0455 @shoobe01 shoobe01 on: www.4ourth.com 68
Editor's Notes
- #2Ā 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.
- #3Ā 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.
- #4Ā 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.
- #5Ā 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.
- #6Ā 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.
- #7Ā 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.
- #8Ā 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.
- #9Ā 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.
- #10Ā 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.
- #11Ā 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.
- #12Ā 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/
- #13Ā 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.
- #14Ā 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.
- #15Ā 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.
- #16Ā 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.
- #17Ā 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?
- #18Ā 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)
- #19Ā 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.
- #20Ā The responsive principle is still solid, especially when you use RESS and device detection to load the right content from the server.
- #21Ā 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.
- #22Ā 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.
- #23Ā 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.
- #24Ā 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.
- #25Ā Believe in mobile. It has all these capabilities, this intelligence and contextual awareness. Use these.
- #26Ā But use them only on mobile. Use the right features, on the right platforms. Do different things on desktop, or kiosk, or IVR.
- #27Ā 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.
- #28Ā 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.ā¦
- #29Ā 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?
- #30Ā 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.
- #31Ā 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.
- #32Ā 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.
- #33Ā 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.
- #34Ā 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.
- #35Ā 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.
- #36Ā 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.
- #37Ā 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.
- #38Ā 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.
- #39Ā 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.
- #40Ā 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.
- #41Ā 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.
- #42Ā 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.
- #43Ā 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ā¦
- #44Ā ā¦ 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.
- #45Ā 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.
- #46Ā 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?
- #47Ā 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.
- #48Ā 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.
- #49Ā 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.
- #50Ā 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.
- #51Ā 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.
- #52Ā 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.
- #53Ā 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.
- #54Ā 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.
- #55Ā 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.
- #56Ā 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.
- #57Ā 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.
- #58Ā But letās narrow to something you can plan on, more than mid-stream changes or a whole lifecycle. What causes second releases?
- #59Ā 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?
- #60Ā 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
- #61Ā 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.
- #62Ā 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.
- #63Ā 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.
- #64Ā 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.
- #65Ā When I say that there are no hard and fast rules, I mean it. Donāt copy anything I have done. Well, not exactly.
- #66Ā 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.
- #67Ā 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.
- #68Ā 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.
- #69Ā I hope there are questions. Ideally, very detailed or technical ones.