Geeks With Blogs
The Unstable Mind of a .Net Developer

This post marks the beginning of a series on architecting software solutions/designs.  Understand, this is not an attempt to explain, compare or endorse any of the many patterns and methodologies that already exist.  Nor am I proposing a new pattern or methodology.  I am attempting, however, to shed light on some items I have found over the course of my career to be significant stumbling blocks to the successful implementation and utilization of any software application.   These are items that need to be discussed, addressed, resolved, etc. prior to finalizing any system designs.


Know Your Audience


When architecting a software solution that has a user interface component, perhaps one of the most critical items is “know your audience”.  Are they “dumber than rocks” as I was told at a previous employer?  Or are they internet savvy, reasonably intelligent individuals?  Regardless of which is true, both can have a significant impact on any UI design.  If the targeted users are “dumber than rocks”, it would be necessary to create a simpler UI with fewer data entry fields and a lot more help text on the page versus a more complex UI with less help and more features for intelligent users.

With that in mind, here is a small sampling of questions that should be considered prior to designing a software solution and an idea of some of the design requirements that may apply:

  • Are the targeted users “dumber than rocks”?
    • Simpler UI
    • More point and click entry using specialized controls such as calendars, etc to avoid manual entry, mistakes
    • Fewer data entry fields.  More complex entry may be driven by wizards with extra validations
    • More space dedicated to helps explaining entry points
  • Are the targeted users internet savvy, reasonably intelligent?
    • More complex UI
    • More features such as drag and drop, tabs
    • More data entry fields
    • Less space dedicated to helps, using click to help and mouse over features instead
  • Are the targeted users high volume data entry personnel?
    • A strong keyboard interface
    • Fewer field level validations with delayed feedback
    • More code or value entry (such as entering MO instead of Missouri, 4 instead of Legal Entity)
    • Less fluff (eye candy) on the page
  • Are the targeted users low volume data entry personnel (such as HR, Benefits)?
    • A relatively strong keyboard interface
    • More field level validations with instant feedback
    • More textual entry (selecting Legal Entity or Missouri from a drop down)
    • Less fluff (eye candy) on the page
  • Are the targeted users network/infrastructure personnel or developers?
    • Can be command-line driven interface
    • More complex UI
    • Less fluff (eye candy) on the page
  • Are the targeted users local, regional, national or international?
    • Could affect uptime requirements and offline processing
    • Could require localization of labels/text displayed to the user, date/time or monetary formatting
  • Are the targeted users internal (local to the network) or external (from the internet)?
    • Could affect the way users are authenticated to the application (if at all)
    • Could affect where the application is deployed and where it can be accessed from
      • For instance, an internal application accessed from outside the local network may require a VPN connection or RSA authentication.  Particularly for web applications, this could affect how pages are accessed, external links are presented, etc


Keep in mind that this list is by no means comprehensive.  It should, however, sufficiently illustrate the necessity to “know your audience”, especially as it pertains to user interface design, when architecting a software solution.  If a solution’s user interface is poor or unusable by its targeted users, the solution design is unsuccessful, even if it was flawlessly executed.

Next up in the series, Setting Your Limits.

Ralph Wheaton
Microsoft Certified Technology Specialist
Microsoft Certified Professional Developer

Posted on Monday, September 21, 2009 9:13 AM Application Architecture , Solution Design | Back to top

Comments on this post: Architecting Software Solutions Part I – Know Your Audience

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Ralph Wheaton | Powered by: