How to conduct a User Persona Workshop/How to create user personas

"The customer is not an idiot. The customer is your wife." - David Oglivy. 

To me, this quote is the most powerful lesson in creating user personas. 

I have always used this as the starting line in User Persona workshops, and immediately, the user becomes a real person. A stereotype, ridden with the disadvantage of a single story, but a real, living person.  nonetheless. 

Step 1 

Think of the user. Visualise them in your head. Is it a male or a female? How old are they? How tall? Are the eyes deepset or wide apart? Is the brow furrowed? What do they wear? Where do they shop for groceries? How educated are they? Do they carry themselves with confidence or diffidence? Large family or small? Are they single, committed, married? Do they have children? How many? 

Step 2 

What drives them? What motivates them? What are they indifferent to? What do they loathe? 

Step 3 

Why are they connecting with your product? What's in it for them? Are they being: 

Employed? 

Promoted? 

Reduced in importance? 

Role eliminated? 

because of your product? 

What is this product doing for them? 

What will this product do to them?

Step 4 

How do they like to interact with technology? When they have to see the time, do they look at their wrist or reach for their phone? When they need some information, do they use ChatGPT or Google? When they have to jump from field to field, do they use the tab button on the keypad, or do they use their mouse? 

(If you have real observation data here, that is great. Otherwise, make reasonable assumptions) 

Step 5 

If they were in a jam, what would they do? Would they run away from the situation? Would they try to break the queue and do whatever it takes? Would they wait and comply? Would they be resilient or escapist? 

Note: This is an important question. This tells us the level of security we need to build in the system Even though most apps today are ZTA, ingeniously unethical users think of each security measure as a challenge in Takeshi's castle. So, it is important to know what our users would do if they had a work situation that the system does not address. 

Step 6 

What should you absolutely NOT do with this person? What kind of behaviour would they just not be ok with? 

Note: Keep this in the chart. We reuse this during user evangelisation / training in addition to using this during system workflow and screen design. 

How to conduct the workshop 

1. This workshop is facilitated by the consultant but all inputs are from the users. The closer to the ground it is, the better. 

2. Ask the questions in order. Give people time to respond. Imagine. Discuss. Visualise. Describe. 

3. Create a chart at the end of each user type and then move on to the next. If you can, insert a simple ritual like water break between two persona discussions. This is like smelling the coffee between sampling two perfumes - a natural break that prevents the spillover bias. 

The case for NO REMINDERS

At TCP, the news articles are written by teenagers. 

They send in content whenever they can. 

We are, and always have been, a no-reminder culture. 

You get no reminders. If you don't send in your work on time, it does not get published, that's all. 

At Esha, we are a no reminders place. If you are a summer volunteer and don't send in your work by Friday 1700 hours IST, you are rolled over to the next week. 

At both places, one is expected to note and manage their calendar and deadlines. 

Why did we decide to do this? 

Because I believe that reminders have crippled our ability to manage our own calendars. 

Also, because reminders are irritating. 

So, we decided to do away with them. 

How has that worked out? 

Phenomenally well. 

The reminder to send a reminder was weighing us down too. 

Now, there is total peace. We trust that the person will send what they have to send before the deadline. So, there are no last hour palpitations at all. 

If they don't come, we just merrily go on. 

Its all very well in non-critical roles. But what about critical roles? 

As a PM for more than a decade, I have never given reminders to any member of the team. Their deadlines were always their responsibility. 

And it worked very well. Half the stress of my team was gone. By the way, our on schedule record was over 90%. My teams rarely ran late on deliverables. There were multiple factors responsible for that (perhaps another post for that), but this also, I think, led to massive reduction in stress all around. 

That is why, when setting the culture of TCP, we started with NO REMINDERS. 

Try it. I can assure you, its very productive. 

Did You Know...

 

Designing Rewards and Recognition - A Case Study

 #DesigningRewardsAndRecognition

One of our clients was trying to implement a rewards and recognition framework for almost two years.

When we were called in, the mood in the room was not optimistic.

We took the project and did design to rollout in 40 calendar days.

Step One: Brainstorm and Design

Sharing with you the interview guide we used to help the client clarify their thoughts.

1. What do you want to reward.

2. Why do you want to reward it.

3. At what frequency.

4. What is the budget.

5. What are the keywords associated with this award. A person who wins this will be ____.

6. This will be valued by employees because __.

7. Who will decide the winner and on what criteria.

The thing with RnR is, that for every winner in a universe of N people, there are N-1 losers. So, every reward's criteria have to be 100% transparent to establish the credibility of the process.

Keeping this in mind, we worked with the client at every stage, asking supporting questions until the process was absolutely clear.

Step Two: Rationalise and Prepare for Rollout

The next step was to rationalise the list and arrive at a schedule of implementation. 

Obviously, through brainstorming, we would have arrived at a list that is at least 2x the intended number of awards being planned. 

So, the awards were rationalised and the list pruned. 

The most challenging aspect at this stage was reminding the client that the budget of the award is not just the trophy/cash component but also the cost of administration, selection, communication. 

We also needed to connect the process to other HR portfolio items like career planning, Upskilling, Performance Management, Payroll, etc. at the design stage itself, so that the rollout is seamless. 

#WordOfCaution

Even if the leadership is very enthusiastic, creating awards that exceed a sustainable budget means that someone will find a valid spanner and succeed in reducing or removing at least a few awards - but taking away the trust on the entire mechanism. So, we had to tell the client to stick within the budget, even when they were ok to "go above and beyond a little bit." 

Step Three: Communication and Rollout 

The next step was to plan the communication preceding and during the rollout for each recognition. 

Once this was done, the rollout of the selected RnR elements was done on a single day. 

During the rollout, the entire focus was on the recipients - what would they be like, how might this help them in their learning/career journey. The entire speech was about the employees and their growth. 

The rollout was a success. 

*Some elements of the process have been disguised/modified to ensure client confidentiality. 

How to Manage Client Scope Creep

This post is the result of a good conversation with Abhishek at a recent event. 

He asked how we managed to ensure that there was no scope creep. My projects have usually been on track and within budget, and as Abhishek mentioned, client scope creep is one of the major reasons why large IT projects go out of budget or schedule. 

So, if you are a budding project manager responsible for client management, here is the secret to building great client solution and even better client relationships. 

Most client scope creep comes from 2 areas: 

A. Complex Workflows, where more approval levels are added. 

B. Reports 

The first thing you have to remember when dealing with client scope creep is that they are not trying to trouble you. Their intention is not the squeeze the juice out of you. Their intention is to do the best that they can for their company at the least possible price. 

Surprise! That is your intention too! 

Most vendor PMs do not understand this intention and objective synergy. But when you do, you realise that you and the client PM are on the same side, trying to do the same thing. 

The only thing is, we are using two different approaches to do it. 

So, Step One:

Establish Commonality of Purpose 

Sit down with your client and establish commonality of purpose. Both of you are working towards the same thing: 

A. Create the best possible solution

B. In the least possible time 

C. At the least possible cost

Once it has been stated, it appears intuitive. Yet, until we say it out and put it on the table, it is not so apparent to the other party. In fact, if you wait at the water cooler long enough, you will definitely hear the Project Managers from both sides cribbing. The Client PM usually says one or more of the following: 

• The vendor does not want to do any work or wants to do shoddy work and get away with it. 
• They are not doing enough KT 
• Even for small change they give such a huge estimate, and change request for everything! 
• They just don't understand our business and requirements. I don't know how to explain. 

The Vendor PM will usually say one or more of the following: 

• The Client is really miserly. 
• They always underestimate the time it will take to do something. 
• They are paying us for a cow and want us to make an elephant. 
• They don't understand how the system works. 
• They have such weird requirements! Who works like this? 

So, the step of establishing commonality of purpose is the most important one. It establishes trust and ensures that you row on the same direction, not in opposite directions. 

Once commonality of purpose is established, the next thing is to understand where scope creep is coming from. 

Step Two: 

Diagnose and Guide 

Most scope creep comes from the two areas I have mentioned above. You do your own diagnosis on your projects and understand WHERE the scope creep is coming. And then ask yourself WHY. 

What problem is the client trying to solve by doing this extra work? 

Let's get straight to taming the beast. 

Step Three 

Managing Scope Creep and Making Great Friends 

Here is the most important tip anyone will ever share with you on managing scope creep. It is so important that I am going to write it in caps. 

START WITH YES. 

Whenever the client asks you whether something can be done, NEVER start the conversation with No. if you know that it can be done, start with, "Yes". If you are not sure, start with "We will try to find a way to do this." 

Managing Workflow Complications

Most clients who try to add additional approval and exception workflows are basically trying to tame one beast - Compliance. 

That is the core objective. 

Start the conversation by saying - My work ends with doing the coding. Your work starts after that and goes on forever. So, my work is the shorter one. Let's talk about how this will work after go live in your business. Let's discuss a few scenarios and understand how much additional work it will add for your users, and what you are doing about it now. 

After that, listen. Let them explain all their use cases and exceptions. Understand their compliance needs thoroughly and most importantly, understand how users manage exceptions now. A system that can be excepted by the user in an emergency will eventually be excepted as a matter of course. The user's onboarding learning curve is slow, but their bypassing learning curve for any system is amazingly steep. So, if you make it necessary for users to bypass the system for one thing, they will be bypassing it for most things sooner than you realise. 

After the client has finished putting their requirements on the table, don your product specialist hat (or get your product specialists on board) and design a solution that meets their needs without being overly complicated. I can assure you that most workflows can be simplified. 

Pro Tip: For each workflow step, ask your client: 

• How will this step increase the transaction load of the user? 

Let's understand this with a real life example: 

Let's say that the client wants all travel to go to the department head. The questions we ask then are: 

A. How many travel requests will the DH have to approve in a day? Week? Month? How much time will it take them to approve each (assume reading time). If we go with 5 a week and 5 minutes per TR, that's 25 minutes of extra work per week. For an already stretched executive. 

Next, ask them how they plan to manage situations that are definitely going to arise - the executive on leave, too busy, traveling himself, etc. 

Usually, in such cases, a thing called Delegation of Authority is used. 

Let the client think about that. And then help them understand how to balance compliance with minimum transaction load on the users. 

• What value is this step adding to your process? 

The most frequent response to this is "It gives us better control" or "Compliance." 

Do not resist. After the client says this, sit back in silence and let them think. 

If they do not appear to be making headway, ask gently, "Are you creating a better process, or are you helping someone do CYA? Think about that. If the system can be hacked, it will neither lead to better compliance nor control. Every new control element you put in there is also a hacking opportunity. Think about the real business value of every step. And its real objective." 

Always be mindful of the client's imperatives. 99% of the times, clients see the difference between business value and CYA. But some cultures are necessarily CYA cultures. In those cultures, you can only help the client by perpetuating the CYA culture. Do that. 

And most importantly, NEVER disrespect the client - neither in public with your team, nor in private in your head. A Lot of delivery managers and PMs get together to laugh at clients in private. The client does not know tech as well as you do, and you don't know business as well as they do. Further, respect cannot be faked. Come from a place of real understanding, and you will create synergy. Come from a place of negotiation, and you will create a tug of war. I am still in touch with client PMs who worked with me 15 years ago, and more. 

Managing Reports 

Report requirements are the biggest headache for most PMs. The client wants to extract every element of data being put (or not put) into the system in about 15 reports on average (that's a joke, not a statistic). 

So, how does one tame the report monster? 

There are, once again, 2 simple questions that one asks the client. 

Since I have dealt with dashboard design and report management in another post, will just quickly state the 2 questions here: 

A. Who will enter this data? 

Request the client to go through their entire data flow process (you can use a proprietary methodology I have listed elsewhere on this blog - the Data River Diagram) and have them understand how the data will flow into the system in the first place. 

Is there enough reliability of that data for us to use it in reporting? 

B. What decision will it aid / How will you use it? 

Every pixel on an executive dashboard is important. Every second of executive time is important. If a data element is making it to reporting, it must help the user do one of the following: 

A. Monitor and control 

B. Diagnose and Correct 

C. Predict and Decide 

If the report is not fulfilling one of these 3 objectives, it should not be there. 

Your clients will truly appreciate your trying to create reports and dashboards that are relevant for the long term. 

In fact, invest some time in creating a report library that you know helps other organisations create effective dashboard and reporting interfaces, then proactively share it with clients. Will significantly shorten the cycle time and will also help the client see value in your work. 

So, are there any best practices that have helped you deliver better business value to your clients? Do share! 

On Requirement Gathering

 If you are a system design consultant, this piece is for you.

There is a children's poem that explains how the battle was lost for want of a horse shoe nail.

Take a printout of the poem and tape it just above your screen.
Remember that poem when you are doing requirement gathering. It is ALWAYS the small things.
****
When do you do the transaction - how long after you have done it in the real world? Why do you think that is the optimal time?

What do you look for when deciding your sales pitch? What are the elements you need at once place, together?

When do you think its ok to share your password with a colleague? For which apps will you never do it?

What will you do if your orgn KRA requires you to fill daily updates, but you are in a field area with no signal?
***
After 15 years, I have found that the level, industry, or technology does not matter. When a project is delayed or faces user resistance, very often, it is because we did not ask the human questions.

We did not understand the fine print of their lives.

An article from 2011: Not betting on Android yet

 

I love the news that Android has overtaken Symbian as the mobile OS. It is, in principle, the victory of the open source.

 

But am not betting on Android just yet. Because, Android is yet to face and successfully deflect a major challenge. And that, is the acid test of a victor. An unchallenged victor is not a victor – merely a figure of preponderance.

 

Sample this: An Android app is created. it appears to be a simple stress buster app that allows you to knock a hammer virtually when you are stressed. Great. A few million downloads happen over a time unit – say a month or so. Its a viral app that is promoted by online word of mouth and because its free, the download is easy.

 

What we do not know is, that underneath the hammer code is another code – malware. It could be anything – a code that surreptitiously handles your data – either obliterating it systematically, or acting like a virus and moving to other phones (not the app section, just the virus section, or monitoring all your connections and forwarding your emails to another address in bcc without telling you, or using your phone to participate in a DDOS attack .. anything at all.

 

The 2 things that stack up against Android as against other OSs are:

1. The easy implementation and the much higher “Viral” impact possible.

2. The more the no. of connected Android smartphones, the greater the temptation for a malware creator.

 

I’d love to see the victory of the Android.. because it puts the power in the hands of the user – because it allows people to contribute and use .. creating a community of producers and consumers. 

 

Which is why, its important for Android to anticipate at least some of the growth pangs, and to plan for it by creating security apps that can be downloaded by users. Am sure someone has thought of it already and its in process somewhere.. just wish we non geeks knew about it.

 

And before we place that Victor crown of olive branches on the Android head, Android will have to prove that it can quash more than one malware challenge. It will take one, exactly one major application based attack to completely kill the Android credibility. And thats one chink in the armour that some competition is waiting to exploit.

 

As i write this, there is, am sure, a programmer somewhere, writing such a malware and smiling to themselves, and there is somewhere, a programmer writing a code that will take care of phone security on Android. Like the African Giraffe and Lion story, we just have to wait and see which one runs faster.

 

How to Design a Dashboard for a customer

 

1. Do NOT sell flashy stuff for the sake of appearing “trendy” or “up to date” . “Up to date” gets dated pretty quickly. Useful, on the other hand, usually endures.

 

2. Use common sense more than you use the solution vendor’s marketing material.

 

3. Ask a few questions:

 

A. What are your categories of users? (Line managers, Middle Managers, Top Management, HR Business Partners, HR Senior Managers, Finance Managers..)

 

B. Do the information needs remain the same through the year, or do they change according to your time of year (financial year end closing, Appraisal year end closing, quarter end closing of sales…)

 

C. What is the top DECISION SUPPORT information that you need? no less than 1, and no more than 8. For each category of user. Gather this information using questionnaires divided by user category. Arrive at the top (by mode) answers and finalise them.

 

D. How often does this information change enough to impact ur decision making? (Eliminate all information that does not change significantly for a month or more. e.g., gender diversity is a statistic that will not change for the rest of the year, except during the campus recruitment season, when we need to actively monitor if we are hiring enough from each gender)

 

The second use of this information, is to determine the refresh rate with the database.

 

E. Do you want the dashboard to be the opening screen, or do u want to access this on need basis? (Tells you a lot about the actual usage of the dashboards being designed) . Please get this information, again, by category of user, then determine. Some categories may want it to be the first screen, others may want more than one dashboard that they access on need basis.

 

F. NOW, go to the flashy stuff – the look and feel.

 

What is the process you would like to follow, as an Analytics consultant?

 

 

 

Employee Engagement and Productivity – The role of the employee personality

 

This morning, i set self a small challenge – Does employee engagement have a positive correlation with productivity? Can employees be productive even if they are not engaged? Can they be engaged without being productive? (think public sector in India) .

 

In most research studies (see links below) Engagement is almost always found to be positively correlated with Productivity.

 

But what if, it was possible for employees to be productive without being engaged? What if they brought to work  – not their personality, but their experience and expertise?

 

Surprisingly, this was the predominant school of thought in the manufacturing era, when we expected people to leave their personalities outside the door, with their shoes, and to wear them again on the way out. Inside, they were time and motion machines (think Frederick Winslow Taylor and the One Best Way theory) .

 

In the IT era, we said, we are hiring brains and not time and motion machines. And yet, we continued to do effort estimate on “man days” and “man hours” – based on the “average time it should take a person to do this task”.

 

Coming back to the subject, does an employee have to be engaged to be productive?

 

I think that productivity is a function also, of the personal discipline and professional ethics of the employee. Of course, here we assume that the employee has the relevant experience, expertise, and authority, and all the organisational factors have been taken care of. Those are hygiene factors in any discussion on incremental productivity.

 

Without any employee engagement measures, using the pure “Work-for-pay” model, the output is:

 

Work = Pay

OR

Work  < Pay

OR

Work > Pay

 

What are the factors affecting this equation and the direction it tilts in?

The employee’s personal engagement level, his/her personal traits, since all employees are treated the same, but some are on the left of the equation and some on the right.

 

So, at least some part of the engagement quotient comes from the employee – from their own personalities.

 

When doing any engagement initiatives, the organisation has to target them, not towards general theories of psychology and Organisational Behavior, but towards the kind of employees they have hired in the first place. The extra benefit obtained from each engagement dollar is also a function of the fit of initiative to the personalities of employees.

 

In a small organisation, it is self evident. And in large organisations, this principle should be exercised using a simple breakdown process – let each sub organisation decide what works for them. Monitor results, correct course where required, but do not assume that the entire organisation has exactly the same kind of people.

 

Now, lets assume positive correlation between engagment and productivity, such that, for every dollar spent on engagment, the producivity does go up, only the scale is unpredictable.

 

i.e.,

Pay + Engagement = Work + x

where x is the additional productivity created by engagement initiatives.

 

Question to ponder: Can x be a negative value? Can engagement intiatives backfire and make employees even less productive than they would otherwise be? What do you think leads to negative values of x?

************************************************************

 

Further reading

 

Here is the set of online resources that mentions other studies done on the subject:

http://www.workforce.com/article/20130501/DEAR_WORKFORCE/130509997/how-do-we-know-our-engagement-efforts-are-paying-off

 

http://www.insyncsurveys.com.au/resources/articles/employee-engagement/2012/10/impact-of-employee-engagement-on-productivity/

 

http://www.sciencedaily.com/releases/2011/07/110720142459.htm

 

http://www.sciencedaily.com/releases/2009/05/090513121050.htm