Mobile UX London Conference Talk - PETER SZABO, User Experience Map – why should every mobile app start with one?
•Als PPTX, PDF herunterladen•
1 gefällt mir•9,918 views
Mobile User Experience Conference in London 2016 (http://mobileuxlondon.com) - PETER SZABO, Senior Manager UX/UI. User Experience Mapping is an easy technique that will change how you tackle today’s complex mobile user experience challenges. In his interactive talk, Peter will share his passion for User Experience maps and cats. He thinks, that while it’s entirely possible to create a mobile app without a cat, having a UX Map is essential. From the very beginning of the ideation phase experience maps are critical communication and strategy tools. They help to solve the problems you have and get closer to understanding your users. Through a fun and easy-to-follow case-study, you will see how UXM helps you save time and money while building better mobile experiences.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (7)
Ähnlich wie Mobile UX London Conference Talk - PETER SZABO, User Experience Map – why should every mobile app start with one?
Ähnlich wie Mobile UX London Conference Talk - PETER SZABO, User Experience Map – why should every mobile app start with one? (20)
Mehr von Naveed R
Mehr von Naveed R (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Mobile UX London Conference Talk - PETER SZABO, User Experience Map – why should every mobile app start with one?
- 1. @wszp User Experience Mapping Why should every mobile app start with one?
- 2. How do we change the world? User-centric Mobile App Development in a TEAM = communication
- 3. the requirements document is a terrible idea
- 5. 1. Dysfunctional communication, lack of collaboration and understanding. The emphasis is often put on negotiation. 2. The requirements documents are intimidating.
- 6. 3. Documents usually don’t break down projects into tiny functionality bits, and some functionality can be lost among thousands of lines of text. 4. Such document places our process above people. 5. Rigid documentations and plan-following mindsets will make responding to change very hard.
- 7. 6.Even the best ideas will need continuous improvement, to stay competitive. 7.People want to work on making the world better, not spend time creating or understanding a long documentation.
- 8. Most problems can and will be solved with improved communication.
- 9. The goal is to achieve shared understanding. The best communication method for shared understanding is drawing a map.
- 12. Your map should be based on real user research.
- 13. Fashion retailer Mobile UX Case Study
- 15. “To build better User Experiences we need to understand people’s behaviour. Insight helps us understand.” Lee Duddell
- 16. Shut up & listen to users. Jakob Nielsen
- 21. Your maps are not final!
- 22. Linked Wireframes are the best tools for UX & developer communication
- 23. Instead of this
- 24. Try this:
- 26. User Experience Mapping is a set of techniques which helps you to understand the users, gain strategic insights and improve communication within the team and with stakeholders.
- 27. map + conversation = solution to UX issues
- 29. Questions & Answers You can also ask them on Twitter: @wszp Follow my UX blog kaizen-ux.com
Hinweis der Redaktion
- Communication is hard!
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.
- In my experience companies who still work based on burdensome requirements documentation have more “firefighting jobs”, as in very urgent jobs for consultants. On a Sunday afternoon, the IT director of a well-known Hungarian web shop called me. The summary of the call was that they created a new responsive website with new design and information architecture. Now it’s been live for two weeks, and our sales plummeted. Especially on mobile. That was very odd because the site was not responsive before. Why the call on Sunday? Because the solution he presented on Monday was to review the documentation, especially the user experience bits, to find out which parts were not followed. For this, he needed an unbiased 3rd party. I got the documentation and opened the site. In the documentation, there was a sitemap, a bit hard to read, as it continued across many pages, but suggested a fairly well thought out information architecture. Some subcategories appeared under multiple categories, and individual products could be found in one or more categories or subcategories. In the footer of the website, there was a link titled “Sitemap”. While the other link titles there were in Hungarian, this one was in English. The link led to the sitemap.xml file. The file contained everything from the documentation’s relevant chapter, nicely prepared for Googlebot, but very far from ideal for humans. It just looks gibberish. The desktop navigation contained unique icons for the categories with the category name next to it. On the other hand, the mobile menu was just nine big icons, visible after tapping the burger icon (three parallel lines, often found in the top left or right corner of a mobile site or app), with small hard to read labels under them. Category names were long, and the designer made sure they will not ruin his nice design. The documentation was followed to the letter but, the developers and whoever created the information architecture had a different idea on what to do with the sitemap chapter.