Mobile Design: Adding Mobile to Your Learning Ecosystem
•Descargar como PPTX, PDF•
0 recomendaciones•1,795 vistas
Presented at DevLearn 2013, 24 October 2013, Las Vegas Every platform offers unique challenges and opportunities. As mobile becomes the preferred platform, you have to address what makes it work well to assure success, satisfaction, and maybe delight. And it’s a lot more than size and touch. Mobile and desktop are very different in their principles and in the way people use them. Learn about the pitfalls and fallacies of designing for mobile and multi-platform, multi-user experiences.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Similar a Mobile Design: Adding Mobile to Your Learning Ecosystem
Similar a Mobile Design: Adding Mobile to Your Learning Ecosystem (20)
Más de Steven Hoober
Más de Steven Hoober (20)
Último
Último (20)
Mobile Design: Adding Mobile to Your Learning Ecosystem
- 1. Mobile Design Adding Mobile to Your Learning Ecosystem @shoobe01 @DevLearn 1
- 2. Mobile is not the next big thing. 2
- 3. More mobiles that people. 3
- 4. 75%. 4
- 5. Local… 5
- 7. 5 billion SMS users. 7
- 9. Ask yourself: • What is your audience? • What are their goals? • What are they using now to solve this need? 9
- 10. Nothing. 10
- 11. PHOTO OF GROUND STRAP NOT IN PLACE? 11
- 12. Don’t design for yourself. 12
- 13. An app is not a mobile strategy. 13
- 14. “I'm as interested in "channels" as a thing when designing ecosystems as I am in pages when reading a book.” – Andrea Resmini @resmini 14
- 15. “Sadly, no decision about architecture is a decision, one that will determine your success or failure as a company.” – ??? @??? 15
- 19. Look over your shoulder. 19
- 23. Know what the audience uses. 23
- 24. Know how your audience works. 24
- 25. Don’t forget the browser. 25
- 26. Think about the ecosystem. 26
- 28. Thing 28
- 30. 30
- 31. “…inequality is where the opportunities/challenges for design really are.” – Andrea Resmini @resmini 31
- 32. Every platform is a unique and special snowflake. 32
- 33. 33
- 34. 34
- 35. 35
- 36. 36
- 39. Systems all the way down. 39
- 43. “Error is viewed, therefore, not as an extraneous and misdirected or misdirecting accident, but as an essential part of the process under consideration.” – John VonNeuman 43
- 45. PHOTO. REG CODES ON CEREAL BOXES. 45
- 47. • Assume the unknown. • Think systematically. • Use and make patterns and guidelines. • Analyze and focus. 47
- 50. Use and make patterns and guidelines. 50
- 53. 53
- 54. Agile? Lean? 54
- 55. None are right. None are wrong. 55
- 56. Wrap your arms around a module. 56
- 57. Look over your shoulder. 57
- 60. Is it ecosystem friendly? 60
- 63. Context is more important than working code. 63
- 65. One on one. 65
- 66. Ask them, don’t tell them. 66
- 67. Your memory is terrible. 67
- 70. Bringing mobile back home. • • • • • • • Know the market. Know your users. An app is not a strategy. Systems first. Design for failure, and resiliency. Look over your shoulder. Show it to users. 70
- 72. Ask for help. 72
- 73. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 045 @shoobe01 shoobe01 on: www.4ourth.com 73
Notas del editor
- You are all, I presume, already providing learning information of some sort through a digital channel. That probably means the web. And you might have come to this session, or this whole Mobile track because you hear it’s getting to be big. One problem: That was 5 years ago.
- There are more mobile subscriptions than people on earth. That includes babies, and people in comas, so accounts for a decent number with multiple subscriptions, and trucks with cellular connections, and so on. And it’s paid subscriptions to mobile networks only. There are a lot more devices when you count the WiFi only iPods, all the tablets, and start getting into the other devices like connected TVs… Did you ever notice that portable game consoles like the DS have a browser? They do. And they are used.
- Sure, it’sinteresting that there are all those billions of phones. But it’s more interesting, what is world-changing, is that 75% of people mostly or only access the internet from their mobile device. IN NORTH AMERICA. In other parts of the world, and for specific populations in the US, it’s over 90%. It’s no longer worth thinking of as “a phone.” If your site doesn’t have majority mobile use I am comfortable telling you that it’s because it doesn’t work well on mobiles, and you are driving people away. Availability is the big thing. Forgot about device ubiquity. Use is what is really important, and interesting.
- Many U.S. companies assume or extrapolate their experiences onto the rest of the world. Not only is the rest of the world different, parts of it are radically different. I worked in San Francisco for a year, and it is not the US, so is sort of terrible that this is where everything is supposed to come from. Less than 20% of smartphones in use worldwide are iPhones.Blackberry continues to sell actually rather well, and is trendy (beating Apple and Google) in parts of the Middle East and North Africa. Until earlier this year, mostsmartphones in use today are still Nokia S60s, none of which are even being made. It will take a few more years to get rid of all those. Well over 3 in every 4 smartphones sold are Androids.This chart is smartphone OS penetration by region. The legend hardly matters (but is obvious for some… Android is green, iOS is white), but instead look at the wild variations between regions. Local variations, by region, or by type of user within a region, are radically different.
- Don’t forget the poor, neglected featurephone. Way too many call them “dumbphones” now, but that’s something else. Very few people have dumbphones. A featurephone can install apps, has a browser, has a camera and MMS. And even in the West, even in the US, more than half the population has featurephones still. Providing them access can pay off. If you tell them, and provide good services, they will get online with even these devices. There are 200 MILLION regular users of facebook on featurephones, and that’s growing still. I find that poor adoption on any one platform is a result of not building a service targeted to them. Make a website that works on these phones, and tell your learners about it, and they will use it.
- An astonishing 1.8 billion people regularly use the mobile internet. Mostly, that means web browsing, But look at this.There are 7 billion humans on earth. Remember, that’s everyone who is alive. So, essentially everyone who can feed and clothe themselves uses SMS. FIVE BILLION users. If you think Facebook is the killer app of the internet, that’s SIX TIMES bigger. And SMS is a great engagement engine, with ten times the response rate and 100 times the response speed of reliable things like email. Oh, and nowhere near that many people actually have an email address. More people subscribe to SMS news alerts than get a newspaper. Does re-engagement mean SMS? Yes, probably.
- But you can find out. The first thing you need to do is know what you are doing, and why. You deserve to get turned down for funding or approval to proceed if you have terrible plans, or huge gaps in them. Just add to those some key user-centric insights. Ask…
- What is your audience?What are their goals?What are they using now to solve this need?The last one is going to surprise you. It’s very unlikely to be whatever your existing formal answer is, whether it’s desktop computer training, videos in the classroom, or hands on demonstrations.
- The point of mobile is not to allow that existing stuff to be on cheaper and more popular platforms, but to address more emergent needs and fill the gaps. If you really look into how people get and need knowledge you are going to find:Nothing. The first answer is very likely to be that they don’t engage, or re-engage. At all.Ad hoc methods. Asking co-workers, or just doing what they see everyone else do. Or not do. Printouts. And other ways to make the current stuff portable. Sometimes, shared informally.Do you still provide DVDs for learners to take and watch on their own time? Yeah…Hacks. Using the existing system (poorly) on their own devices, or just using other information sources which might not be approved or even accurate. It could be just individuals finding info online, or it could be well-intentioned, with departments making their own training notebook.
- Don’t stop them from doing this. I mean, unless it’s dangerous, or illegal. Your focus needs to be on solving the core issue. People don’t follow rules, and ignore signs (PHOTO). Not because they are malicious, but because we forget things, and counter-intuitive stuff is required. We need to be reminded. We need technical enforcement, or to be forced to comply as it’s automatic or easier than not complying. And by finding that people are circumventing your information sources, or just finding how they don’t follow the training plans, you can try to determine how to improve your materials, and most important for mobile, the availability and engagement they have with the information.
- Your audience is not you, it’s not your developers, and not the same users you had for the desktop or classroom. Most of all, they don’t work in the same way they did on desktop. Learning in the breakroom is not the same as the classroom. Don’t make assumptions about use, platforms, needs. Mobile offers the ability to use information in such ways you need to consider that this is the first time you have met your users.
- A website is not a digital strategy, and digital learning is not a learning strategy. You know this. We all know this. Though with the number of people confusing the ACA with the website fiasco, I wonder sometimes. But anyway, how do we get to a mobile strategy. How do we find the right answer for you and your organization?
- First, think in terms of systems, and of data, and set aside platforms.
- Thinking of systems means thinking about how information works agnostic of channels. It means thinking of Information Architecture, data architecture, even storage technologies and what’s in the API, first. Think about some really successful products. Twitter, which is SMS based, but you use as a Website, as an app on your computer or handset, or tablet… Or take Evernote. Who used some competing tool to keep track of stuff like that a few years ago? Well, most of those disappeared. Why? They were websites. Or apps. But Evernote is a platform, more than anything. Their platform even has a name (Trunk) and teams work on that as a product in and of itself. Thinking of their product as a service meant they could move into new platforms immediately, without re-thinking their business model, or re-architecting their systems.
- Remember when I asked what your audience uses now to solve the problem your product will fix? Well, that might not be a competing website, but a book, catalog, pair of scissors, or Post-It note. Think about all the systems we use every day, maybe by stopping and just observing how much you yourself email, IM, SMS and just walk over and talk to people. A website is not a digital product, and an app is not a mobile strategy. You have to consider the whole ecosystem, and design the password reset emails, make it easy for customers to send links to their friends and family, and make sure the mailed out laminated sign uses the same terminology as the training video.
- This is what user experience is in many ways. Not interface design, but ecosystem design. Mobile learning, due to the way it’s carried about and intrudes into lives, makes this truth more evident. Designing for people, goals, tasks, and making systems to address this immediately rolls back into how people use multiple devices, and different devices for their context and needs.
- My kids routinely do what all children do: they don’t clean their room, they leave the bathmat wet on the floor, they leave the cereal box out. The typical excuse is “oh, I forgot…” to do whatever. Lately, that thought process has struck me. Their expectation seems to be that following the rules is about memorizing, and complying with, a long checklist of appropriate behaviors. I remind them instead that I don’t remember anything, either. I actually have a sort of terrible memory for processes and steps and procedures. I made most of this deck by pulling my best practices from my Wiki where I write everything important down so I don’t forget and you all can use it.
- So what I do is turn around and look over my shoulder. Just like you look before crossing the street, you should make sure the bathroom looks neat before you leave it after taking a shower. We as humans actually become pretty good at doing this; when we take a moment to step out of our normal, rushed lives we notice what is wrong, broken, or out of place. Yes, I’m talking about this in our professional lives also. How bad is your current product on mobile? How good is the competition, or that vendor product? Well, you should find out.
- And expert reviews, or heuristic evaluations, work very well to find the vast bulk of issues. Without getting into the whys too much, or addressing what heuristics I use, here are some basic guidelines for evaluating existing work, the competition, or that vendor suggested solution. I won’t talk about the specific heuristics you test to, as that’s way too long as list for me to read. I have some articles about this on the wiki, so just ask if you can’t find it later when you need it for your work. But in principle…
- The project will have limits of engagement. Even if answers below are different, and your users actually have lots of featurephone use of the Web, if the business has decided to only address how it works on iPhone 4 and above, there's no point in logging issues on Android or Blackberry much less featurephones. It's not ideal, but it's how the world works. Argue that in a different document and discussion.
- We talked about this, but you are an office worker. 25% of us remote work, so it's irrelevant if your office is the park, your back yard or Starbucks. You are therefore probably not who most of your users are. Try to emulate how they work. What do they expect, what do they use on their device right now and how often and the environment. Loud factory? You might be clever enough to realize sound won’t work, but did you know the frequency of many machines makes it hard to detect vibration also?
- Within the limits above, find out what devices and browsers your users employ. Ideally, you have specific research and maybe even analytics from the first launch or similar products. Otherwise, use basic knowledge of the industry and regions.
- Just last week I kept going outside to check on the readability and legibility of an interface, both as I designed it and as it was built. Because this information is to be consumed by mechanics who might be in repair shops, truck cabs or even outside. It has to work everywhere. Ideally, I'd account for dirty fingers also, and within the limits I have (I don't make phones) I did by making targets even bigger than usual for the basic functions. Editing the equipment name? That's a small target, because you do that when there's time to stop and think.
- (Only for Web) In some markets, the default browser is not used, or is no longer the default browser due to language or other regional needs. Know this, and check in the correct browser, or in several.
- How do people discover this? For apps, check the store screenshots and descriptions, pay atttention to icons and app names. For the Web, do NOT assume everyone starts at the home page. Simulate entry points from Google searches, shared links, or whatever is the really likely way they will enter the site. Check on sent emails, sms and make sure the links to the camera or maps all work.
- Make a chart of what you are going to test, both process and platforms, and mark it off as you go. Some of these can take all day. Or two days. You will forget what you did or where you left off at lunchtime.
- Tactically, what this means is that you have to get the devices your users will use, or maybe just a whole bunch of them to represent the range of devices, and see if it works. If this looks complex compared to the desktop web, you probably have just been ignoring a bunch of users on other platforms or other browsers already. Fragmentation isn’t a bad word, it’s just about supporting user choice, and well-designed, well-built products don’t have as many issues as you might expect. If it looks expensive, there are shortcuts. Device Anywhere is worth writing down, as a way to not have to buy a big pile of devices, and even to automate some of the testing.
- A note about fragmentation before we continue. Fragmentation is not a bad word so stop thinking it is so. I think it’s a bit of fanboyism really, and also find it to not be as true if you follow good design principles and stick to OS standards. But mostly, it’s something you cannot avoid if you actually profess to care about users. It’s about choice, or sometimes the actual different needs of our users. Any time you want to argue with your boss about not supporting the “fragmented” world, replace the word with “diversity.” Imagine saying you don’t support diversity, and see how far that will go.
- Every device is different, and every device is good in its own way. This photo is about scale, size hardly even matters in many cases. Angular resolution and viewing distance cause a lot of this to disappear. And if you gripe about hand size for the large screens, you are also wrong. Phablets are the majority of the market in Korea, so that works for them. And in the US, when I did my field research, the largest devices are all carried by women. Small hands. Purses, I gather, instead of pockets.
- Device differences tend to disappear in the end, not inthe sense of merge, but because the capabilities and interactions are matched to the way they are used. Embrace these differences.
- Now, differences in device /capabilities/are fairly large. This is stuff that gets me excited! Mobiles are in no way like desktop computers. And they are not like cars. And your smart thermostat, or watch are not like each other or anything else.
- In a lot more ways more than the size of the screen. Or the input method. Most of all due to connectivity and sensors. Many devices are taking the mobile cue of being very aware of their environment, and their user. And also, critically, more seamless access to the features most computers have like connectivity. Data entry, for example, can be made trivial:by removing it. Since the device is reliably connected, and full of sensors, it canalready knowwhat the user wants.
- I know this isn’t a mobile phone, but it’s a great example that’s easy to see and understand, it’s a good way to talk about how no-interface and pre-emptive tasking is probably the future anyway, and a lot easier to understand than the shiny Nest devices we can’t afford anyway. It’s a hand-washing station. You press a button for water, then a button for soap, then a button for water, then a button for air, then dry your hands on your shirt. They each come out different places, so you move your hands to different positions. Which is not enough to turn it you. You really do have to press a button. Wet, soapy, etc. In this day and age. Unsanitary? Mostly, un-necessary. Sensors are (seriously) cheaper than buttons and can make the experience a LOT better.
- We have to design, each platform, every platform, to take advantage of the features inherent to it, and the unique environment, and user expectations.There are sexier items like location, but sharing is my favorite example of mobile vs. web. Not the concept, but the implementation where you just press “Share” is brilliantly good stuff. It appeals to the way people cognitively address tasks like this. If you are building email forms into your desktop website, that’s correct. That’s the standard. But for mobile web and apps, that’s wrong. You link to installed applications because that’s the expectation and method of operation of mobiles.
- Do whatever is right for whatever system you and your users work with.TV, and kiosks and telematics and so on will all have their good points. And these are ALL here. Millions of Smart TV downloads have already been sold. You’ve all seen you can now develop for cars. Mobile handsets and tablets are, relatively, easy to understand. Be sure you -- and your team, and your leadership --stop thinking of mobiles as tiny, crippled desktops, with weird touch interfaces that mean you can’t use hover states. You need to embrace the network connectivity, the portability, the presence, the sensors, the intelligence, the integration, the personalization.
- There are many pressures put on design and implementation teams. A lot of them are specific to industries, organizations, or projects. Often, when I come into an organization to consult, I find that many elements that are assumed to be constraints are actually variables, or at least arguable.I’d stipulate that the real constraints are…
- That most systems are so complex that they cannot be modeled with pencil and paper (or whiteboard, or flowchart, or wireframe) in sufficient detail to execute design.
- The complex application or website is embedded into a much more complex OS, in a differently-complex device, running on a vastly complex network, carried by a person with their own needs and behaviors, living in a world of other people and really complex systems. You cannot predict what might happen to these variables and how they will affect your little part of the world.
- Everything is connected now, but traditional network models fail us. Instead, we have built a giant, distributed supercomputer that we all carry windows into in our pockets. Our devices, apps, and websites just delay and interfere with access to this information, to varying degrees. Anything that reduces delay is good. Anything that gets in the way or exposes edges of the network is bad.
- Right now, technical systems (software, data) fundamentally expect perfect information and absolute precision in computation. They are intolerant of imprecision, missing data, and failures to connect unless that behavior is also precisely designed.
- While people are great at estimating, fudging, and getting by, they don’t like to use tools that break or cause them to work harder. Very simple gaps in “look and feel” can induce familiarity discomfort similar to the uncanny valley of anthropomorphized representations. At the very least, you will encounter reduced satisfaction and trust. Often, that means users will give up and use a competitor’s product or service.
- In 1952, computing pioneer John Von Neumann called computational errors “an essential part of the process” of computing. This was almost forgotten for decades with the advent of the high-reliability computers we work on today. But increasing amounts of data and the need for power conservation are creating a need for unique solutions that leverage probabilistic design and ignore unused data or let small errors occur in computing.
- This is surprisingly not new even to visual and graphic design. The technical methods of printing machinery have inherent inaccuracies and behaviors that make certain apparently possible designs insufficiently reliable for mass production. Print design has to account for ink being placed in the slightly wrong place, for overlaps on adjacent layers, and for slight errors in binding, folding or trimming.
- In print (and package design) these are all considered tolerances, or normal variations, not errors. Accounting for overlaps and inaccuracies in ink placement is a whole (very specialized) practice area called trapping. I have books on my shelf dedicated just to trapping.It’s baked into the entire process of print, from design through QA. These little things are registration marks, allowing the printers to line up the inks, and allowing inspectors to check that it was done well, and consistently. (As an aside, in print it’s the head designer who signs off on whether the print run was done correctly. If the designer isn’t happy, you keep printing till it’s right.)
- For us all to account for tolerances and normal variation instead of lamenting fragmentation, complexity, and error means letting go of perfect solutions to create better, more robust systems and solutions. We need to embrace the messiness and complexity of systems—and of real life. To apply these approaches to interaction design, information architecture, database design, or software development, with all the additional complexities, really doesn’t call for anything new. We already do many of these things, but need to switch from considering them as discrete tasks to seeing them as principles that are applied regularly and repeatedly throughout the process of designing any project.
- I suggest that we all follow these four guidelines…
- No matter how many questions you ask or how much research you do, there will be behaviors you cannot predict or understand. This will keep happening. A minor change or a shift in trends will cause use of your system to change.
- All the data we gather on personas and the concepts we use to develop storyboards are not inputs to the design process, they ARE the design process. In every phase of the project, explicitly discuss the user, your expectations of their behaviors and needs, and how those are met in every way.
- Art and science both evolve by building on what has come before. Use existing patterns by understanding how they apply to your work. Create patterns for your product instead of screens, pages and comps for everything.
- Admit you do not know a lot about the pressures, behaviors, and inputs of the user and customer. But don’t just throw your hands in the air and design for those you do know or are comfortable with.
- … Remember all those complex, interconnected systems? It is mathematically impractical to address every use case. When considering the available combinations of choices a user could make on many systems, combinatorial variations are in the billions.
- I did some rough math on one project and determined the documentation and analysis would take longer than the history of the universe to that time to complete. No, really. This one isn’t that bad, but is a real example of all the inter-relations of a not-very-complex website I worked on. The whiteboard is 10 feet tall. This is the sort of work that made me reconsider the whole premise.
- The current, state-of-the-art processes for addressing these concerns involves various iterative methodologies, such as Agile. These are mostly development methodologiesapplied (or forced) onto design disciplines, and focus on breaking work up into smaller chunks. In principle, each deliverable is something that can be analyzed or designed, and complexity emerges over time in a controlled manner as iterations add to it. In practice, many of these methodologies become simply incremental processes, which means the same work as always is now done in phases with essentially more paperwork.Lean methods build on these with principles of doing the most important work first, and allowing products to evolve organically. Practically, these approaches end up disregarding design and, seeking speed over quality, don’t really move us forward from a UX point of view.
- In principle, any of these can deliver robust, future-proof, error-free products. It’s not any one process which will get us there, but accepting the principles above into your life and methodology.
- Sometimes, this does mean a little change. For example: Design modularly. Remember how it’s impossible to adequately analyze your whole system? Easy. Don’t do that. Instead, design a series of modular components. You will re-use them, which means it also takes less development time. Then, robustly analyze every state each of those can be in. It’s rarely more than about 3-4. That’s easy.
- This can be tied to the concept of heuristics I outlined above. You can add some of these basic principles to your work plan. Maybe a bit like unit test even, so after each feature is completed, or every few days as you would do an integration test, walk through the whole product like an end user would. Try to make no assumptions based on what you know about the system.
- First, does the information architecture (the visible structure of the site or app, and arrangement of items on the page) make sense?
- What about errors? Can the user get out of them? Can you eliminate errors (or at least error-messages) from the process?
- Disregard the happy path. What if, instead of the home page, users pop into a random page from a Google search or shared link? Does it even work? Does it make sense?
- Does the structure or language obscure the true organization, data, or structure of the system or process? How many of your sites today have simple three step processes that are 15 pages long? Don’t lie to your users. They will notice.
- … I am starting to see lots of small, fast, nimble startups show their ideas and alpha products to actual people. Yes, usability testing just like big, serious UX groups have been doing for decades.That’s great and if you aren’t going to make a UX hire your next task, you should at least do this. But, there’s very little guidance on how to do it, especially for mobile, so even if you are experienced in usability you might be testing the wrong thing, the wrong way. Working with a real set of experts in this is truly beneficial, but basic usability testing doesn’t need a masters degree, a lab and a staff. Just try to follow a few basic guidelines…
- You can get good results by sketching ideas on a bit of paper and letting users interact with the “system” (have another developer be “the computer”). But try to do it in their office, or at a desk like they would use. If mobile, tape it to a bit of wood, or an old phone and have them carry it while you follow them around.
- Find people with jobs similar to your real audience, and especially avoid anyone involved in the project. I went to my neighborhood auto repair shop recently to test out an auto parts finder on actual mechanics. Try to remove yourself a step and use friends of friends, if you have to recruit like that. Don’t use anyone at your company, or anyone in development or design unless that’s your audience.
- Do not do focus groups. Just trust me, it’s the wrong thing to do. Get one user, and one moderator at a time and run then through the process. Make sure they talk about what they expect, and what they think they are looking at. Reassure them you are testing the product, not them; say “there are no wrong answers” in the intro. And lie if you need to, that you are just testing, but didn’t build it. They will be more honest if they don’t worry about hurting your feelings.
- Don’t lead the test participants. Be careful what you say when writing a test plan, and let them fail for a bit before you assume they won’t get it. Don’t tell people to click on a link, but give them goals, then listen and watch how they try to get there. Only correct them after recording their actions, and if they have to go down a particular path to complete the test.
- Record, or write everything down. Confirmation bias is real. You will remember only what reinforces your pre-conceptions of how you expected the tested interface to work. Ideally, bring someone else along who can just take notes, or film the test on their phone.
- You will find a lot of complaints and failures. Look closely at the notes. No matter how badly one person does, it’s just one person and you can ignore it. Even without real statistical analysis, you can look at the raw numbers and find that only a relatively few problems are shared by most participants.
- Go back through the steps above, and think about ecosystems, structures and bigger solutions to fix your problems before changing anything. Separate users’ preference from their performance: generally you can ignore what people think the system should be like (suggestions to move things and change labels), and find better answers to the deeper issue instead.
- … So you don’t have to remember everything I said, here’s a nice little summary to bring home. This is all out on Slideshare already, so you don’t have to take photos unless you really want to. Know the market, and the technology. Go get the devices your users carry, and live with them.Apply normal methods to discover what your users want, and need, but don’t make any assumptions or get led astray. Don’t convert your website, or embrace Mobile First, but design the system and consider the ecosystem most of all.Embrace complexity and uncertainty, design for the unknown, for failure and for error. Regularly, or constantly, review to make sure design is suitable for the platform, and the users. Validate formally, with ethnographic usability testing with real people.
- In case you haven’t picked up on that, or I accidentally implied any of the things I said are a new process, or steps in your existing process, they aren’t. You should use almost all of these during your design process, but routinely. If not hourly, then check for resilience and consider platform specifics daily. Eventually, you can do this automatically. It becomes second nature. To me, I am serious when I say this is developing a philosophy of design.
- Ask for Help –Lastly, there is a lot of information, scads of research, good guidelines, and a lot more mobile consulting out there than you might think. If you can’t hire an expert full time, try to get one in to help for a bit at those key junctures, and as early as possible. Assign existing people jobs to find information, and share it with the organization so you raise the level of knowledge in the new domain. You people: go back home and tell everyone what you learned here. Now, what didn’t I answer for you? What specific problems do you have with your organization, environment or users? GIVE AWAY BOOKS TO FIRST FEW WHO ASK QUESTIONS.
- So, whose confused, disagrees or doesn’t see how it applies to them?