A quick note: this article is targeted at both UX’ers and Haskellers, so different parts may seem elementary to different reads.
Personas and UX
In User Experience a persona is a snapshot of a “typical” user. There are different ways to group “typical”:
- Some personas are driven by demographic (e.g. consider Facebook, who might separate out the posting habbits teenage high-school boys vs middle aged mums)
- Others are driven by consumer groups (e.g. in university an undergraduate vs postgraduate)
- Others by behaviour (e.g. an e-commerce site distinguishing browsers from buyers)
Most of the time we try to create a realistic sounding person; we give them a name, a background, goals & motivations and then describe the problem they have that we are trying to solve. This allows us to consider the user journey from their first encounter with us to when they leave.
Personas are a staple of the UX industry and one that I’m generally not a fan of. The reason is simple – the design insights you get from a persona could have been reached from the research you did to develop the persona. That’s not a universally true statement but in my experience is true enough.
They do however serve another person – and that is to inform stakeholders of other points of view. It might be obvious that not all users behave the same but it’s not always immediately obvious the ways in which they are different.
My preferred persona approach is behavioural. Take some core attribute of a group of users and anthropomorphise that attribute into a character. From there we can start to consider how such a character may behave.
Researching personas
This being a side project – away from my full time job (and other side projects) – meant that I didn’t have the luxury of time normally allotted to this sort of work. The ideal method is to use a mix of qualitative and quantitative research, identify behavioural traits and then interview or otherwise observe users.
From interviews we can start to notice patterns of behaviours, motivations and goals. We then group these into archetypes or typical behaviours. Ideally we would include actual statements and quotations from real users that embody those personas.
My methodology
I had the initial advantage of already being a Haskell user. So at least one persona could be defined on me. Of course, being only one type of user I had to explore the other ways that people used Haskell. Reading the Haskell subreddit and mailing list provided some general insights as well.
I also ran some data analysis on the “What do Haskellers want?” survey conducted by FP Complete.
*Math warning for the next paragraph*
I cleaned the data and then did what many consider a faux pas and turned discrete values into a continuous scale. Each response was then given a value from -1 to 1. I then picked a set of questions I thought covered a good cross-section of opinions and performed a Principal Component Analysis. This created a series of eigenvectors which reduced the dimensionality of the data to 8. From these 8 I was able to observe correlations in the data which accounted for a significant portion of the variance.
This revealed some interesting if not obvious correlations:
- Web development and high-performance code were not strongly related
- The desire for IDE support and the writing of code for data science/machine learning were inversely correlated
- Scalability, profiling, deployment and integration were highly correlated. This also correlated with the perception of Haskell in the industry and by business
A separate piece of UX research I ran was specifically to address usability issues in Hackage. A separate post on that is coming later. In the survey I conducted there was a pretty big disparity between people who were interested in the academic side and those who were not.
When I showed Gershom my summary of the data he pointed out that there seemed to be two dimensions to user opinions. One was about the kind of code that they tend to write while the other was on their approach to writing the code. That is definitely and interesting consideration and one becomes apparent when you look at the personas I developed.
At this point we leave the realm of data analysis and science. From here constructing personas becomes a bit of an art – based on personal experience as much as data.
The 6 types of Haskell user
Like most personas, these 6 try to encompass a wide variety of behaviour into somewhat contrived observations. And like most users, people will drift between different personas over time (sometimes even in a single day).
They can help us understand that not everyone who writes Haskell code thinks the same way. They don’t write the same kind of code. They aren’t interested in the same kinds of features from the platform. When we consider any design decisions, it should be couched in this understanding.
Considering the audience (developers) I save the usual narrative driven approach to personas. Instead I simply describe the facts as I understand them about our users:
The Haskell-in-the-large developer
Much more likely to be experienced with Haskell. The perception of Haskell, information available about success stories and availability of Haskell developers in the Market are a concern that tends not to be shared with the other groups.
On the technical front they are also concerned about installation, package management, debugging & profiling and deployment. They are more likely than other groups to be concerned about interoperability with other languages and systems.
They have additional concerns around documentation and reusable design patterns and templates.
The Haskell-in-the-small developer
This kind of Haskeller eschews IDEs and advanced editors. The kind of code they typically write rarely exceeds a single module. For them, no problem is too small to warrant a Haskell solution. Need an import script? Haskell. A browser extension? Haskell. A Twitter bot? Haskell.
They are much more likely to be interested in data science and machine learning. This is a problem domain whose solutions rarely exceed one module (especially if the right libraries are available).
Interestingly, if they work professional their company is incredibly likely to already use Haskell. If they could it’s possible then that they would make more use of it where currently languages like Python and R dominate.
They care about writing high performance code, scalable code. And while they are likely to be professionals, business concerns around Haskell are a less pressing issue for them.
The Haskell-for-the-web developer
A good portion are professional developers, though by no means exclusively. Those whose concern is more oriented with front-end development are more likely to be hobbyists or Haskell enthusiasts. If they are a professional, their company is much less likely to use Haskell internally, suggesting that there are possibly a large amount of web-based hobby projects in Haskell.
Interestingly, this group has much less concern about the need for writing high-performance code. This suggests they are interested in developing more feature rich web environments over the high performance demands of their business and data science counterparts.
Some of them even found Haskell purely by looking at web frameworks like Yesod. They appreciate the type safety and abstraction in Haskell but are far less interested in mathematical correctness or low level optimisation.
The systems Haskell developer
A subset of Haskellers are more focused on these core issues compared to the other groups:
- Deployment
- Debugging and profiling
- Ease of writing high performance code
- Writing scalable code (e.g. distributed scalability like Spark/Hadoop)
- Documentation and learning resources
While many Haskellers shared an interest in these same issues, this group was much more likely to value these factors above others. Largely professional developers, their focus on writing and shipping robust production ready code.
The theorist
Without this group we wouldn’t have the robust language that is Haskell. Their blog posts read like academic papers. They value the correctness of the language above all else. Pick a random word in their writing and it’s like to start with “co-” or end in “-morphism”. They were the first Haskellers and they are the ones that continue to push the language to its theoretical limits.
While some Haskellers will publish highly practical modules for niche purposes, they are hesitant to release modules at all. They focus on making things as abstract and general as possible, that type classes have laws and that equational reasoning can be used to reason about to their code.
The enthusiast
Also the hobbyist and the student. The enthusiast is learning Haskell for various reasons – pick up a new language, make a game, write a Scheme or simply finish their degree. They may not even be professional programmers – but they’ve heard if you want to write solid, abstract code, Haskell is the way to go.
They may have learned Haskell years ago and are picking it up again. They may tinker with it a few times a year. They may even have a personal project that they’ve been using Haskell on for years.
One day they find themselves reading computer science papers (mostly reluctantly) and actually understanding what they say. Sometimes they even pick up some category theory and type theory along the way.
And another thing
The newbie
There is a 7th type of Haskell User that’s worth considering in the general scheme of things. The newbie could become any of the above and they arrive at Haskell from many roads. Like all of us, their path hits stumbling blocks at the usual places: Monads, Transformers, Pipes/Conduit and Lens.
Proud of their newly acquired knowledge, they go out and write a blog post to finally explain Monads to all the other newbies. They worry their questions are too dumb to ask on StackOverflow or IRC. And regularly they reach a point where the next thing to learn is so much more complicated than the things they already understand.
Whether or not to make special considerations for the newbie is an age-old question. For those who have used the language a long time any newbie specific angle crowds out information that could be useful for more seasoned users. But we all started somewhere.