User Experience as an Organizational Development Tool

1,310 views

Published on

Developers sometimes begin a project by racing to the specification document and an ERD. Wait! Even if you're developing iteratively, there's a huge amount of potential being missed in most projects.

I propose that your projects will be more successful and valuable to your clients if you think of yourself not just as a database developer but as a process consultant. This presentation outlines a few concepts for addressing the human and political aspects of database system development and concludes with an example scenario.

This was presented at a FileMaker training session and is my first public presentation. Thank you for looking!

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

No Downloads
Views
Total views
1,310
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • For example, think about when you are evaluating your solution… how much to do you focus on usability and business impact as opposed to data integrity? (unless they bark at you)
  • David Kachel of Foundation Database Systems, “Are You Taking Notes?” in White Paper for FMP Novices, 12/5/2006, p. 57-60.
  • Intuitive structure represents their mental model
  • Cf Don Levan, Psychology of Effective FileMaker Pro Solution Design in FileMaker Advisor
  • Understandable solutions are good, but great solutions cultivate higher understanding as well.
  • Understandable solutions are good, but great solutions cultivate higher understanding as well.
  • Understandable solutions are good, but great solutions cultivate higher understanding as well.
  • Understandable solutions are good, but great solutions cultivate higher understanding as well. Take more work; but, once you understand how to connect the model of your system to the user’s mental models, it’s easier for you to begin to shape that mental model.
  • From Ancona et al., Managing for the Future, 2005
  • From Ancona et al., Managing for the Future, 2005
  • Add Networked
  • Add Networked
  • Separate into slides
  • Separate into slides
  • Separate into slides
  • Separate into slides
  • Multiple implications
  • Can also be viewed through various aspects
  • Typical concern that probably won’t surface or be dealt with. But, the database can help! Could have political issues. Perhaps they won’t talk to each other unless the system does it for them. This problem relates to the need for being flat and flexible .
  • Could have strategic implications
  • DB now becoming a decision tool
  • That’s a really simple example, but it points to the direction I’m going. When a manager says “I wish…” or “That stupid…” it makes me think of the cultural, political and strategic dynamics involved… now I’m also learning to think about ways in which the users interact with the database are influencing those dynamics.
  • That’s a really simple example, but it points to the direction I’m going. When a manager says “I wish…” or “That stupid…” it makes me think of the cultural, political and strategic dynamics involved… now I’m also learning to think about ways in which the users interact with the database are influencing those dynamics.
  • User Experience as an Organizational Development Tool

    1. 1. The Database as an Organizational Development Tool Development perspectives for the knowledge economy Donovan Chandler December 2007
    2. 2. About Me <ul><li>Name: Donovan Chandler </li></ul><ul><li>Working as a Data Manager and FileMaker developer for Azusa Pacific University </li></ul><ul><li>Been working with FileMaker for < 1 yr </li></ul><ul><li>Studying for MA in Organizational Leadership </li></ul>
    3. 3. What’s the Point? <ul><li>Examine some of our assumptions about development </li></ul><ul><li>Design solutions that are as good for humans as for data </li></ul>
    4. 4. Overview of Presentation <ul><li>How Thought Informs Design </li></ul><ul><li>How Design Informs Thought </li></ul><ul><li>Thoughts That Matter to an Organization </li></ul><ul><li>Practical Example </li></ul><ul><li>Concluding Thoughts </li></ul>
    5. 5. HOW THOUGHT INFORMS DESIGN
    6. 6. The Developer’s Perspective <ul><li>Data </li></ul>Layout Design Logical Structure
    7. 7. Developer Sees… …schema
    8. 8. Developer Organizing Data <ul><li>FMP_8_Checklist_20071023 </li></ul><ul><li>FMP_9_Checklist_20071214 </li></ul><ul><li>Mtg_20070815_Database Requirements </li></ul>
    9. 9. The User’s Perspective <ul><li>Data </li></ul>User Experience Intuitive Structure
    10. 10. User Sees… …interface
    11. 11. User Organizing Data <ul><li>Bob’s list of FileMaker tasks </li></ul><ul><li>Old FileMaker checklist </li></ul><ul><li>Meeting with Mark about FileMaker </li></ul>
    12. 12. The Challenge <ul><li>Developers tend to think in terms of the software’s processes and structures </li></ul><ul><li>Users often operate on other (sometimes mysterious) assumptions entirely </li></ul><ul><li>This is not a problem, it’s an opportunity : the seeming quirks of human logic are what allow us to do jobs that computers cannot </li></ul>
    13. 13. Implications <ul><li>A database must be regarded not only as a repository for data but as a facilitator of human processes </li></ul><ul><li>Therefore, designing a good user interface and experience depends on the context and psychology of the users </li></ul>
    14. 14. Higher Perspective Logical Structure Intuitive Structure Data Layout Structure User Experience
    15. 15. HOW DESIGN INFORMS THOUGHT
    16. 16. Beyond Intuitive Interfaces <ul><li>Understandable = Good </li></ul>
    17. 17. Beyond Intuitive Interfaces <ul><li>Understandable = Good </li></ul><ul><li>But, Great = Understanding </li></ul>
    18. 18. Beyond Intuitive Interfaces <ul><li>Understandable = Good </li></ul><ul><li>But, Great = Understanding </li></ul><ul><li>In a manufacturing economy, storage and retrieval is enough </li></ul>
    19. 19. Beyond Intuitive Interfaces <ul><li>Understandable = Good </li></ul><ul><li>But, Great = Understanding </li></ul><ul><li>In a manufacturing economy, storage and retrieval is enough </li></ul><ul><li>In a knowledge economy, information must be rapidly accessed, analyzed and communicated towards collaborative innovation </li></ul>
    20. 20. In a Nutshell <ul><li>Good user experiences guess how a user thinks </li></ul><ul><li>Great user experiences also guide the way a user thinks </li></ul>
    21. 21. Programming People? <ul><li>Yes! </li></ul><ul><li>For example, Quicksilver or Spotlight </li></ul>
    22. 22. apu/
    23. 23. apu/Applications/
    24. 24. apu/Applications/FileMaker Applications/
    25. 25. apu/Applications/FileMaker Applications/BaseElements/
    26. 26. Ctrl+space
    27. 27. “ base”
    28. 28. “ base” Still remember the old file path route? I don’t! apu/Applications/FileMaker Applications/BaseElements.fp7
    29. 29. THOUGHTS THAT MATTER <ul><li>(From an organizational behavior and development perspective) </li></ul>
    30. 30. Comparing Trends <ul><li>Manufacturing </li></ul><ul><li>Clearly delineated roles and hierarchy </li></ul><ul><li>Standardized procedures </li></ul><ul><li>Information goes up decisions come down </li></ul><ul><li>Homogenous population and behavioral expectations </li></ul>Knowledge
    31. 31. Comparing Trends <ul><li>Manufacturing </li></ul><ul><li>Clearly delineated roles and hierarchy </li></ul><ul><li>Standardized procedures </li></ul><ul><li>Information goes up decisions come down </li></ul><ul><li>Homogenous population and behavioral expectations </li></ul><ul><li>Knowledge </li></ul><ul><li>Teamwork and temporary taskforces </li></ul><ul><li>Flexibility given in favor of creativity </li></ul><ul><li>Information shared vertically and laterally </li></ul><ul><li>Diverse employees, partners and markets </li></ul>
    32. 32. Comparing Values <ul><li>Manufacturing </li></ul><ul><li>Predictability and reliability </li></ul><ul><li>Stable structures </li></ul><ul><li>Impartiality </li></ul><ul><li>Expertise </li></ul><ul><li>Clear lines of control </li></ul>Knowledge
    33. 33. Comparing Values <ul><li>Manufacturing </li></ul><ul><li>Predictability and reliability </li></ul><ul><li>Stable structures </li></ul><ul><li>Impartiality </li></ul><ul><li>Expertise </li></ul><ul><li>Clear lines of control </li></ul><ul><li>Knowledge </li></ul><ul><li>Networked </li></ul><ul><li>Flat structure </li></ul><ul><li>Flexibility </li></ul><ul><li>Diversity </li></ul><ul><li>Global </li></ul>
    34. 34. In Practical Terms <ul><li>Look for the assumptions behind common questions that are being asked </li></ul><ul><li>Take a moment to put yourself in the user’s perspective </li></ul><ul><li>Learn to ask “why” until you’ve drilled down to the root assumptions (without getting too annoying) </li></ul>
    35. 35. Common Questions Revised <ul><li>Who deserves access to the data? </li></ul>
    36. 36. Common Questions Revised <ul><li>Who deserves access to the data? </li></ul><ul><li>Who can possibly leverage this data? </li></ul>
    37. 37. Common Questions Revised <ul><li>Who deserves access to the data? </li></ul><ul><li>Who can possibly leverage this data? </li></ul><ul><li>Which positions own which processes? </li></ul>
    38. 38. Common Questions Revised <ul><li>Who deserves access to the data? </li></ul><ul><li>Who can possibly leverage this data? </li></ul><ul><li>Which positions own which processes? </li></ul><ul><li>How do we enable clear and flexible delineation of roles? </li></ul>
    39. 39. Anatomy of a Business Approach <ul><li>Networked </li></ul><ul><li>Flat </li></ul><ul><li>Flexible </li></ul><ul><li>Diverse </li></ul><ul><li>Global </li></ul>Strategies for excelling in the new environment
    40. 40. Anatomy of a Business Approach <ul><li>Networked </li></ul><ul><li>Flat </li></ul><ul><li>Flexible </li></ul><ul><li>Diverse </li></ul><ul><li>Global </li></ul>Cultural Strategic Political Strategy Aspects to be addressed within each strategy
    41. 41. Whose job are we talking about anyway? <ul><li>If you think of yourself as just a developer, you’re missing the greater picture </li></ul><ul><li>You are also a process consultant </li></ul><ul><li>Organizational development principles may not be necessary for building a database, but they offer a higher level of service </li></ul>
    42. 42. Use These Principles to Avoid… <ul><li>Confusion about the theme/core purpose of the solution </li></ul><ul><li>Being blamed for deficiencies in the workflow your system supports </li></ul><ul><li>Lost potential </li></ul><ul><li>Losing your client to a more adapted service provider </li></ul>
    43. 43. A PRACTICAL EXAMPLE
    44. 44. A Practical Example <ul><li>The School of Education is building a database to track student progress through the various program requirements. </li></ul><ul><li>Let’s look at several perspectives on a use case for tracking student progress through these requirements </li></ul>
    45. 45. Admin. Assistant: “I need a screen to enter requirements into” <ul><li>This is likely your most active user and therefore your most prominent use case </li></ul><ul><li>You probably already have a form designed in your head for this one! </li></ul>
    46. 46. Credential Analyst: “I need a checklist to see which requirements have been met” <ul><li>Another heavy user </li></ul><ul><li>This will get built in right away </li></ul>
    47. 47. Don’t Stop There <ul><li>Some developers may be happy to speak with only those primary users </li></ul><ul><li>What about the sponsors? </li></ul><ul><li>What about the influence of indirect users? </li></ul><ul><li>Why not go a little further to assist with the workflow itself and add a much greater value to your services? </li></ul>
    48. 48. Supervisor: “I wish the assistants and credential analysts knew how to communicate with one another when new exams have been added” <ul><li>This person probably doesn’t even have an account in the database, and thus will never be asked for this information </li></ul><ul><li>Yet, you could present huge value added by resolving this conflict and pleasing a potential sponsor! </li></ul>
    49. 49. Student: “I wish I had a timeline for how far I am in the program” <ul><li>Since the database is an internal system, why ask students for any input? </li></ul><ul><li>Answer: Because they are ultimately the clients being served </li></ul><ul><li>Using this case, you can likely correct a symptom that is being addressed in another (misguided) requirement </li></ul>
    50. 50. Dean: “I wish I knew how many students are completing Track B this term” <ul><li>This person definitely doesn’t have an account, nor much time to speak with you </li></ul><ul><li>Nevertheless, she also probably holds the ultimate power over your project </li></ul><ul><li>At this level, your database is now becoming a decision-making tool </li></ul><ul><li>Now you’re positioned to gain more work and a prominent advocate within the University </li></ul>
    51. 51. SOME FINAL THOUGHTS
    52. 52. Some Final Thoughts <ul><li>Ask the right questions </li></ul><ul><li>Begin with business needs when shaping system requirements </li></ul><ul><li>Become attuned to the cultural, political and strategic dynamics at play </li></ul><ul><li>This requires risking a little more involvement, but also great gains </li></ul>
    53. 53. Some Final Thoughts <ul><li>Ask the right questions </li></ul><ul><li>Look for business needs before system requirements </li></ul><ul><li>Try planning from the other side of the pyramid first - go from UE and UI to structure </li></ul>
    54. 54. References <ul><li>David Kachel of Foundation Database Systems, “Are You Taking Notes?” in White Paper for FMP Novices, 12/5/2006, p. 57-60. </li></ul><ul><li>Ancona et al., Managing for the Future: Organizational Behavior and Processes, 2005 </li></ul>

    ×