Merge pull request #137 from kyyberi/feature/day72

Done

_posts/2019-09-25-72.md

@@ -0,0 +1,82 @@
+---
+layout: post
+comments: true
+title: "#72 - Living, Breathing and Communicating Developer Persona"
+date: 2019-09-25 03:32:44
+image: '/assets/img/day72/blog.png'
+description: "End of clinical personas"
+handles: "" 
+tags:
+- DX 
+- 100DaysDX
+- Persona
+- Empathy
+- Teija
+- Slack
+- Zapier
+- Github
+- Issue
+- Wish
+
+categories:
+- DX
+- 100DaysDX
+twitter_text: "#72 - Living, Breathing and Communicating Developer Personaa"
+---
+
+How to make person alive? I mean alive in our daily life so that persona is not just another result of clinical process; a paper or file in documentation; something that is done once and then forgotten? Those have been the questions in my head lately. 
+
+## Empathy is the key
+
+The  software development  focuses on  users'  needs  and emotions  while  interacting  with  the  product  is  critical  for  the software product success. The  field  of  User  Experience  (UX)  explores  these  needs  and their fulfillment, it gains in importance against the background of the wish for human-oriented products and services. In order to develop usable systems is necessary to understand the users that will interact with the system. ([Sproll et al, 2010](https://www.researchgate.net/publication/221248250_From_product_concept_to_user_experience_exploring_UX_potentials_at_early_product_stages)) 
+
+I can see and hear empathy to play a crucial role in the above. While discovering the "empathy" topic for the purpose I discovered **Empathy Map** (EM). The EM is a method that helps designing business models  based  on  the  client perspectives .  The  EM  template has  a  visual  organization.  This  organization  simplifies  the template   implementation.   Furthermore,   the   EM   has   guide questions.  This  guide  questions  aid  the  designers  during creation of personas, making this process more systematically. You should take a look at [what EM is](https://www.nngroup.com/articles/empathy-mapping/). Below is an example of filled EM regarding "buying a tv". 
+
+<img itemprop="image" src="/assets/img/day72/tv.png" alt="{{site.name}}"/>
+
+## Empathy towards the personas
+
+We discussed the livelyness of our personas with the DX/UX team today at the office and we all agreed that personas must be really alive. We can't meet the customes of the platform. We can see only a few of them occasionally. **Customers don't become "real" to us, but stay more or less distant to us.** We need to have a different method than meeting customers all the time to feel empathy towards them and their needs. **We need to humanize the personas. Our developer personas must become surrogates.** 
+
+We just don't know yet how to do that exactly. Three things has arised in the discussions: 
+
+1. Personas must be data driven
+2. They must be present in our digital environments
+3. They must be present in our physical environments
+
+## Personas must be data driven
+
+In psychological therapy, which is what UX / DX design occasionally feels like, "_empathy must involve understanding the current feelings of a patient, not his feelings of yesterday or the day before_". ([What Is Empathy?](http://www.jstor.org/stable/3422614)). If this applied to empathy in DX related persona development, then we must have uptodate data about the customers as well. Not the data from past month or something we got 6 months ago when we crafted the personas. 
+
+I want to have live persona. Like I mentioned before the persona must be alive in our internal discussion and feel as part of the team. Same applies to persona which is measured and is based on "realtime" data of the customer base. Of course in the beginning we make a guestimate of the personas, but soon gathering of information about the real platform users begins. Then we need to analyse their behaviour in the platform and even outside it to have accurate "picture of our developers". Outside the platform refers to Github activity and preferences and social media activity. Of course some developers give us more information than others. 
+
+But **drawing an accurate picture of the personas must be data driven.** Otherwise we end up doing surveys and quarterly updates to personas. That is waste of time and we could use the time for something more useful like improving the API documentation or getting started guides. We don't analyse the API usage or behaviour manually either. Why should the personas be any different? This is not a small thing to do, but nevertheless something we have to do over time. 
+
+
+## Customer wishes are posted to Slack by developer persona
+
+One thing is to make the persona act in our Slack. We can beging with baby steps. Our customer provide wishes in Github as issues. One option is to use Zapier to push new wishes to wanted channels and name the bot as "Teija". Teija Tekkistäkki (could be translate to "Dorothy Techstack") is one of our developer personas at Platform of Trust. I did a little test and an example how "Teija" could talk to us in Slack via "wishes" is below:
+
+<img itemprop="image" src="/assets/img/day72/slack.png" alt="{{site.name}}"/>
+
+The process to end up in that is simple:
+
+1. Developer is at [Platform of Trust API Docs](https://docs.oftrust.net) and clicks link "Did we miss something? Make a wish!"
+2. Link takes the developers to custom issue template which takes the labels as url parameters
+3. Developer fills in the "wish" which is just normal issue with label "Wish"
+4. Zapier notices new issue and filters to react only to issues with "Wish" label
+5. Zapier posts the issue title with link to issue as "Teija" to wanted channel. 
+
+Now Teija is alive in out Slack. Does that make us feel more empathy towards the customers? Do we feel more empathy towards Teija? Perhaps to some extend. I'm pretty sure that the level of empathy is better compared to noticing issues posted by some github-bot. This little thing alone is not enough, but it's yet another small feature to feel empathy towards our developer persona Teija and eventually towards the real developer customers. 
+
+You might think now that we are loosing the information about real users. Why to hide the real user behind a persona? **To us it really does not matter what is the name of the actual user submitting the wish**. We can see the account from Github if needed. That knowledge should not affect processing of the wish in anyway. All wishes are equally important and thus it's ok for us to look at the wishes as "Teija's" wishes. 
+
+I still need to figure out how to automate the posts to Slack to come from different personas depending of are the "wishes" data integration related or application development related. Those to are the main categories for the developer personas. 
+
+## Lifesize Cardboard Cutouts
+
+If Teija is just digital persona, she is not alive enough for us. **We need her in the office as well!** I'm really obsessed with ordering a cardboard figure to the office. I mean real human size Teija cartboard figure! I want her to be there an remind us every day when we arrive to office to whom we are building and that the customer is the center of our universe. Their (developer) experience matters the most. People might freak a little when they would enter our office and see cardboard figures, but that might even be a nice ice breaker :) I could not actually care less if those increase the empathy towards Teija among the team members.  
+
+<img itemprop="image" src="/assets/img/day72/figures.jpg" alt="{{site.name}}"/>
+
+