Wilson Mar bio photo

Wilson Mar


Email me Calendar Skype call

LinkedIn Twitter Gitter Instagram Youtube

Github Stackoverflow Pinterest

You are who you are when

US (English)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Cyrillic Russian   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean



User stories begin with “As a user …”.

Examples of different actors are:

  • End-user (customer)
  • End-user supervisor (who manages user access)
  • End-user manager (who views exceptions and status metrics)

  • Customer support
  • Developers
  • System Administrator (Sysadmin)
  • Database Administrator (DBA)
  • Network Administrator (NetAdmin)
  • Site Reliability Engineer

Each of these roles have different needs:

  • Different permissions to get into data (system logs)
  • Different metrics
  • Different sorting
  • Different filtering criteria
  • Different time-out settings
  • Different tools to operate on data


Personas go beyond the usual demographics:

  • age
  • gender
  • marital status
  • ethnicity
  • family status

  • educational attainment
  • job title (profession)
  • employer
  • current place of residence
  • location of youth

Personas are much more aligned with the psychographics of different groups of users.

  • Liklihood to buy
  • Impatience to reading, pop-ups, and delays
  • Expected use of short-cuts
  • Willingness to learn
  • etc.

These provide a way of thinking about features to offer each group, to evaluate the benefits of new features.

  • motiviations
  • expectations

Mort, Elvis, or Einstein

Eric White’s blog from 2006 identifies 3 types of “developers”:

  • A “Mort” is someone who doesn’t consider programming their main job. Maybe they are a statistician, biologist, or construction estimator, who also knows quite a bit about programming. They are oportunistic, using whatever tool comes to hand that will get the job done.

  • An “Elvis” is a professional programmer. I would consider an Elvis to be a journeyman developer. You can scope out a job and give it to them, and the job will get done. In general, Morts don’t become Elvises. Morts want to do their main job; they don’t WANT to become a professional developer. Elvises go to school and get CS degrees.

  • An “Einstein” is a smart Elvis who has been around the block a dozen times. They have seen many projects, some that failed, and some that succeeded. They have seen a large variety of technologies. I also consider that an Einstein is someone who can see the big picture. An Einstein often is in a position of responsibility, choosing technologies and designing large software systems.

The characteristics of an Einstein developer is someone who, for instance, is concerned with architectural purity. For instance, they study type systems, and how type systems relate to various styles of programming languages. They study n-tier systems, and the various ways to break a system into tiers, and the advantages of each of the ways. Then, they are in a good position to design a large system, and coach a set of journeymen developers so that the system is successful. While there are exceptions to this rule, I think that most new CS graduates don’t have enough experience to do this. There is so much in the development world that is communicated verbally between developers that I think that until someone has been exposed to a number of projects from beginning to end, they don’t see all of the ways that projects can go wrong.

The implications:

A library that makes explicit use of parsers and abstract expression trees may be targeted to an “Einstein”.

A forms library that allows developers to set properties to connect to database tables may be targeted to an “Elvis”.

A set of Excel macros that enable construction estimating my be targeted to a “Mort” construction estimator. A library written in Fortran that models fluid dynamics may be targeted to a “Mort” aerospace engineer.


  • https://www.wikiwand.com/en/Persona_(user_experience)

  • http://www.usability.gov/how-to-and-tools/methods/personas.html