Moah Mini Upa2009

1,342 views

Published on

Published in: Technology, Business, Design
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,342
On SlideShare
0
From Embeds
0
Number of Embeds
44
Actions
Shares
0
Downloads
12
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • Click and drag your mouse to scroll vertically or horizontallyHorizontally – it behaves as regular scrollingVertically – the shelf jumps up and down by one like you are clicking up or down arrowsThere is the vertical tab on the left which also lets you navigate to each sectionAnd there is also up and down arrows icon that you can click to navigateAnd finally, the two little rectangles you see – they are paginationsIt seems like someone has this brilliant idea to represent the editor pick’s section as visual book shelf and added every possible cool navigation they can think of.
  • Moah Mini Upa2009

    1. 1. What User Interface Designers can Learn from Architecture Aye Moah User Experience Engineer Choicestream Twitter: @ayemoah Email: ayemoah@gmail.com Blog: http://thinkstick.net
    2. 2. Why Architecture? • Design
    3. 3. Why Architecture? • Design • Solving human problems
    4. 4. Why Architecture? • Design • Solving human problems • Working within constraints
    5. 5. Why Architecture? • Design • Solving human problems • Working within constraints • Evoke emotional response
    6. 6. Balancing Act
    7. 7. Notable Quotes “Beauty and brains, pleasure and usability, they should go hand in hand.” Donald Norman, 2003 “Form follows function - that has been misunderstood. Form and function should be one, joined in a spiritual union.” Frank Lloyd Wright
    8. 8. Architecture is an old profession. • Actually… It’s quite ANCIENT! Relatively speaking. 4000 years ago vs. 40 years ago
    9. 9. Certificate from the Stonemasons Guild of Strasbourg. Engraving 1771.
    10. 10. 4 Things 1. Be the hub 2. Claim the role of architects 3. Don’t be afraid to throw away good ideas 4. Don’t break paradigm
    11. 11. 1. Be the hub. Structural Engineers Electricians Contractors Architect Building Mechanical Code Engineers Consultants
    12. 12. 1. Be the hub. Engineers Customer Product Support Management You QA Project Engineers Management
    13. 13. Talking to Engineers 1. Present the root cause of Engineers an issue as a problem to Customer Product Management be solved. Support You QA Project Engineers Management
    14. 14. Talking to Engineers 2. Speak with numbers. Engineers Customer Product Support Management You QA Project Engineers Management
    15. 15. Detour: Good numbers to know • Working Memory Capacity *1 – 7+/- 2 information chunks – Retention time : ~ 7 sec • Reading Capacity – Average reading speed : 250 wpm for college educated – Optimal font size : 12 point *2 – Luminosity contrast ratio : 10:1 *3
    16. 16. Talking to Engineers 3. Keep up with current Engineers technology Customer Product Support Management You • Frank Lloyd Wright / Cantilever / Falling QA Engineers Project Management Water (1935) • Type ahead filtering in web applications/AJAX
    17. 17. Talking to Product Management • Help them with Engineers Competitive Analysis Customer Support Product Management • Get involved from the You beginning QA Project Engineers Management • Usability should be part of the priorities that a product manager juggles
    18. 18. Talking to Project Management • Understand software Engineers development methodologies – Waterfall Customer Support Product Management – Spiral You – Agile (Scrum, XP) • Don’t forget Mythical Man- QA Engineers Project Management Month • Books – Getting Real – Peopleware – Business of Software
    19. 19. Talking to QA Engineers • QA Engineers think in Engineers terms of test cases Customer Support Product Management – Positive You – Negative QA Project Engineers Management – Edge and Exceptions
    20. 20. Talking to Customer Support • Customer Support Engineers knows customers better Customer Support Product Management than the customers You know themselves QA Project Engineers Management • # of users calling to ask how to use software is a pretty accurate assessment of usability
    21. 21. 4 Things 1. Be the hub 2. Claim the role of an architect 3. Don’t be afraid to throw away good ideas 4. Don’t break paradigm
    22. 22. 2. Claim the role of an architect • Architect vs. Interior Designer “Space planning with decoration applied to “dress it up” is not architecture. Architecture resides in the DNA of a building, in an embedded sensibility that infuses its whole.” • Architect vs. Engineer “Engineers tend to be concerned with physical things in and of themselves. Architects are more directly concerned with the human interface with physical things.”
    23. 23. 2. Claim the role of an architect • Earn the right to influence how a software is built by – Learning basic computer science principles – Understanding System Architecture Diagrams, Object Model Diagrams • Be deserving of Virtual Tiara • Danger of bozo bit
    24. 24. Detour : Tiara Story a programmer asks Joel Spolsky to intervene in some debate he is having with a program manager. Joel : “Who is going to write the code?” Programmer : “I am…” Joel : “OK, who checks things into source control?” Programmer : “Me, I guess, …” Joel : “So what’s the problem, exactly? You have absolute control over the state of each and every bit in the final product. What else do you need? A tiara?”
    25. 25. 4 Things 1. Be the hub 2. Claim the role of an architect 3. Don’t be afraid to throw away good ideas 4. Don’t break paradigm
    26. 26. 3. Don’t be afraid to throw away good ideas • Not every idea a creator conjures up belongs in the work at hand • The cliché “Just because you can doesn’t mean you should” is relevant • Jamming up all cool interface components != best design for your product • Be wary of suggestions and make conscious decisions of what fits
    27. 27. 3. Don’t be afraid to throw away good ideas “Beauty is due more to harmonious relationships among the elements of a composition rather than to the elements themselves.” Page 28 - 101 Things I Learned in Architecture School, Matthew Frederick, 2007
    28. 28. 4 Things 1. Be the hub 2. Claim the role of an architect 3. Don’t be afraid to throw away good ideas 4. Don’t break paradigms
    29. 29. 4. Don’t break paradigms • Users are accustomed to them • The time it takes to do a task decreases with practice *1 Tn = T1*n-α Tn: Time it takes to do a task for the nthtime α : ranges from 0.2 to 0.6 • First time : 3 seconds 10th time : 0.75 seconds
    30. 30. 4. Don’t break paradigms • Paradigms tend to be well researched • Microsoft has collected 1.3 Billion sessions on Office 2003.*5 • No need to reinvent a wheel researched a million times over
    31. 31. Unless that’s your core feature • Google Maps – Click and drag to navigate within the map – Continuous display of map data
    32. 32. Unless that’s your core feature • iPhone – No physical keyboard – Direct manipulation of interface with touch screen
    33. 33. Open Debate • They have – a name “Architect” (officially, Registered Architect) – well defined responsibilities and requirements – education, experience and examination required to become a licensed architect – Architect Registration Examination (ARE) • So what about us?
    34. 34. Poll questions • Current Title • Current Responsibilities • What should it be? – User Interface Designer – User Experience Engineer – Interaction Designer – Information Architect … • What regulations and standards do you think we need?
    35. 35. References 1. MIT OCW Lecture Notes from User Interface Design and Implementation Class http://ocw.mit.edu/NR/rdonlyres/Electrical-Engineering-and-Computer- Science/6-831Fall-2004/0A79F491-80BA-4E19-885C-1E7E481FA2A3/0/L4.pdf 2. Software Usability Research Laboratory Wichita State University http://psychology.wichita.edu/surl/usabilitynews/41/onlinetext.asp 3. Web Accessibility Tools Consortium http://www.wat-c.org/tools/CCA/1.1/#what 4. 101 Things I Learned in Architecture School by Matthew Frederick, 2007 5. Inside Deep Thought (Why the UI, Part 6 by Jensen Harris, Lead Program Manager of Office http://blogs.msdn.com/jensenh/archive/2005/10/31/487247.aspx

    ×