Background on Personas
I joined the Developer Division User Experience Group on January
13, 2003. At that time, the three, now famous Mort, Elvis and Einstein, personas
had just been developed by the team. I benefited from the wealth of research
the team had done with developers and had a shorthand way to quickly come up
to speed about our developer audience.
The first public reference I can find of the developer
personas is “Who
are you? Mort, Elvis or Einstein” on September 25, 2003. Unfortunately, the
author describes the personas from his memory of reading the profiles “a
long-time ago” and intuition. The characterizations are wrong, but it seems
many people believed them.
a fellow researcher on the DevDiv Ux Team, has accurately and succinctly described the three
Systematic programmers tend to follow a defensive coding style.
They do not make assumptions about the code they are writing, the platform it
runs on, the class libraries that they are using etc. For example, they do not
assume that a class library will behave as advertised. Instead, systematic
programmers will test the library in a safe environment, inspect the library
source code etc before using it in a production environment. Systematic
programmers desire programming languages and APIs that give them full control
over the execution of their code and that do not hide important details from
them, even if it means they have to write more code and take more time to
understand how the code works. They value being able to get under the covers
and tinker with components or even replace them.
Pragmatic programmers tend to be less defensive than
systematic programmers. In many cases, they are comfortable trading off control
for productivity as long as they are aware of the existence of the trade off.
Rather than spend the time understanding the full working details of an API,
they will prefer to learn as they go, building up an understanding of the API,
programming language etc in the context of the work that they are doing. They
value being able to get under the covers and tinker with components should they
need to, but will prefer not having to do so.
productivity features in a language, API and IDE very highly, often higher than
anything else. Unlike systematic programmers, they place less value on having
complete control over their code, since for opportunistic programmers, the cost
of control is added development time. They particularly value 3rd party
controls and APIs that allow them to concentrate on the business problem that
they are trying to solve, rather than on configuring the control or
specialising the API so that it meets their requirements. They don't really
value being able to get under the covers and tinker with components - they
would rather look for some other API or control that met their needs instead of
modifying controls or APIs that they already have.
summary of the three is:
THE SYSTEMATIC DEVELOPER: Writes code defensively.
Does everything he or she can to protect code from unstable and untrustworthy
processes running in parallel with their code. Develops a deep understanding of
a technology before using it. Prides himself or herself on building elegant
THE PRAGMATIC DEVELOPER: Writes code methodically.
Develops sufficient understanding of a technology to enable competent use of
it. Prides himself or herself on building robust applications.
THE OPPORTUNISTIC DEVELOPER: Writes code in an
exploratory fashion. Develops a sufficient understanding of a technology to
understand how it can solve a business problem. Prides himself/herself on
solving business problems.
The first thing that should be noted is that the names don’t really matter and that there's no reference to programming language. While each of these corresponds
to a name, it’s really about the work styles and behaviors of the
developer. The names are just shorthand
to make communication easy. However, the
shorthand can’t be used if everyone isn’t on the same page about the work style. The second thing to note is these are not full descriptions of the personas. There is a lot more to them than these quick summaries.
Over the years, there has been a lot of controversy over
these three personas. I speculate that one of the main reasons is that people don't fully understand the personas and the depth that is available about each one. They just get this quick snapshot, hear a few things from others, and form a weird and inaccurate view of each persona. However, it’s interesting to see it unfold in blogs
and the media. It's even more interesting that these personas are so famous they even have their own Wikipedia page. Who knew that an internal tool would be so powerful (and so misunderstood) outside the Microsoft
The Power of a Name
While I stated above that names don't really matter, it's sort of a lie. The names are meant to be memorable and offer a way to talk about developers in a personal way. The developer personas are some of the few widely known personas across Microsoft... because of the names. Even if people in other divisions don't know what work styles they stand for, they do remember Mort, Elvis and Einstein and bring them up. I haven't seen any other name stick like these. As a little quiz, do you know who Abby, Ichiro, Frank, Anna and Miles are? What groups use them and who do they represent?
Although there is controversy around personas; if used correctly, they still remain a very
Evolution of Personas
While we still have our three famous developer personas described above, we
also have additional personas. Ellen is an example of the first persona added after
the famous three and we dub her the “vigilant tester”. In fact, we have 19
different personas in use in the Developer Division today.
Another big change that has happened with our persona work
is how we have expanded our thinking. Our drive is now what “People in Context”
are doing. As many observers have noted over the years, depending on the
context in which they are working, they may have a very different work style.
While this is hinted at all over the place in the blogosphere, there’s no
reference to how this applies to personas directly and how we use it to design
products. "People in Context" does just that.
“People in Context” gets more complicated than just the old
personas, so I’m going to spend the next few blog posts breaking it down.
Interesting reading on our Developer Personas:
change and developer personas by Steven Clarke
effective use of personas in design by Steven Clarke
profile users and not tasks? By Steven Clarke
by David Williamson
personas by Nikhil Kothari