IIBA IIBA-AAC – Techniques on initiative horizon

1. Personas

Before designing a solution, make sure you know who is it for. Otherwise you risk designing something that no one is interested in. But sometimes it is not that easy because you may have an infinite list of stakeholders. Take for example, a website or a public service. You can never group and name all of the visitors of your website. But these people are your main stakeholders and their needs need to be taken into account when you are designing a solution.

This is when the concept of persona comes in really handy. A persona can be defined as a fictional character or archetype that exemplifies the way a typical user interacts with your solution. This is the definition from the Agile extension to the Bag guides. Although they are fictional, they represent a class of typical users. Personas will be based on qualitative research such as interviews and surveys, and represent the common desires, pain points and view of the world of a particular user type.

A persona is described as though it is a real person. It will have a name, a photo, a day in life, narration, all done for a single purpose to understand and emphasize with Nintendo’s Stakeholder. In order to align this solution with the stakeholder need, let’s have a look at an example. Let me jump back to my mirror board. As you can see, I’ve got a little template here.

The Gel extension to the Beaver Guide says that business analysts can choose between two types of templates for capturing information about personas. This short template, which would be a small, precise one page summary of the information you know about your personas. Or a long template which will be filled with more details depending on the needs of your project. And how much time are you allowed to spend doing this? You may choose between the two. For the sake of this exercise, let’s stick to the template that I’ve got here. All personas, regardless of the template, will have their name and photo.

So let us start with this. Let’s call our persona Fred the Farmer. It is generally a good idea to give persona a somewhat realistic name with a bit of description there something like this. I personally prefer to keep the same letter rule. So if your name starts with F, the description to the persona will start with F. It just gives them more memorable names that typically are easier to use and they add a bit of humor to your persona as well. So this Fred the farmer. Now let’s find a suitable picture for him. I’m using a mirror add on called Unsplash to do it.

This addon allows me to search through the unsplash base of photos. I like this one. So just drag and drop it here and give it some time to load. Here it is. My Freddy farmer. Now, if I double click it, I can crop the image. All right. And this is my Fred. Hi, Freddie. Cool now I can start populating the information about this persona. As I mentioned before, this information should be based on your research. But for the sake of our exercise, let’s assume we have done the interviews and we are populating the data based on some average answers that we received from our residents.

So, first of all, the personal background of Fred. The personal background will capture some of the information about the personas family, about their living situation, something that may be related to a cause, but not necessarily directly. So, for example, Fred can be the second generation farmer. So his farm, he got it from his parents, and he may have a family with two kids and he may be in his late 30s. All right, that’s the personal background of our persona.

Now in the business background, so it is a family business. He may be hiring up to five seasonal workers, and he’s generally good at what he is doing. Now let’s go into technology savviness. So especially if our solution is going to be based on modern technology, we need to understand how familiar our personas are with modern tech. So in this case, this particular type of farmer may be very familiar with modern technology, especially when it comes to a specific farming equipment.

So I’ll write it down that he’s killed with farming technology, including modern digital products, which means he is generally not afraid of technology and not afraid to try a new technology solution. All right, this is tech seven s background. And now, coming closer to our solution, our product and our service, what are the challenges and pain points that this particular person may have at the moment? So, first of all, too much time spent traveling when it comes to paying bills.

He cannot afford it because he’s got quite a business to run. And if he needs to go somewhere to pay his bills, it’s not convenient. What else can be there? He really depends on stable supply. So not paying the bills on time is not an option, and using some kind of generators may be too expensive. All right, these are his challenges when it comes to paying bills and why this person may decide to use our product. So first of all, to save time. Second, to have an ability to pay ahead.

For example, to cater for some seasonal changes in workload and effectively to manage his payment schedule, right? So this is a quick and dirty example of how our persona may look like for a farmer in a remote area, really dependent on his power supply, but doesn’t have much time to travel to the office to pay his monthly bills.

So he’s looking for a solution that would help him to save time to pay when he wants to pay, to cater for different seasonal changes in his business. Now, after we’ve looked at an example and discussed what a persona is, let’s talk about why do we use personas. First of all, they help your team members share a consistent understanding of the user group.

The people in your team will know who they design and build solutions for, and this helps build better products. Second, this facilitates a shared understanding of specific requirements that your specific user groups may have. Through detailing the background for the personas, you explain why specific use cases are important to them.

The features of your solution may be prioritized based on how well they address the needs of a specific persona or multiple personas. And finally, your personas provide a face to the requirement. They create more empathy and understanding about the people using your product. In the next couple of videos, we are going to talk about a very particular way of writing down the requirements from the personas point of view. Let us move on.

2. Stories

Impossible to introduce a change if the change is big and you try to implement it in one go. This is the reason we tend to break the solution down into smaller components. We will then use these components as Lego blocks to compose the desired experience out of them. These are the example elements of paying the bill experience. The SMS phone line that you are going to use to pay for your bill over the phone. The website with information or potentially with payment form on it a physical letter that you receive with your bill or your receipt or other correspondence. And an app that you may install on your phone or tablet to manage your bills. So all of these elements, they represent different touch points or different channels for the customer to interact with and what is important. Each one can be treated semi independently of the others.

So you can understand what is the scope of change for each individual component of your solution, implement that scope and then build the final experience out of all these individually implemented scopes. To build the scope for each component, we need to remember that every component always has two sides to it. The front of house. This is what your customer or your persona sees and interacts with, but at the same time it has the back of house. What are the business capabilities behind it? What needs to happen in the business to enable this component to work? And there are always gaps in the current and desired states. You will always find yourself in a situation when you want a certain business capability to be in place, so that you can enable certain behavior for your customers, but you realize that there is none at the moment.

So you need to identify those gaps, document them in a way that will help you address them in the future, and this will form the scope of your initiative for a particular component. To highlight the gaps, we will be using Stories. The Agile extension to the beach guide suggests that you can use two types of stories. The first one is called User stories. Let’s have a look. A user story is a statement that explains which particular feature or capability will be of value for a particular type of user or persona and why. Therefore, it consists of three elements. First element explains who is the user or role or persona that is going to get value. It starts with as a persona or as a role. The second part of it explains what is the feature in question. I need to have a feature or I want a particular feature or capability. And the last part explains the reasoning or the why behind the need.

What is the end goal or value that this particular role or persona is going to get after the feature is implemented? Here’s an example as a current bank account holder, I need to access my account so that I can withdraw cash. As you can see, we’re using a user story format to highlight who is going to get value out of this feature, what the feature is about and what is the goal of implementing this feature. Another format suggested by the Bible Guide is called Job Story. Job Story, similarly to user Story, consists of three statements which combined together explain what is the function to be built and why. However, they come from a different point of view.

Instead of focusing on the role and their goals, job Stories focus on the context of the situation where the user is, what is their motivation, what they try to achieve beyond the immediate interaction, and then they go to explaining what features can help them do it. So let’s have a look at an example. When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so that I can go out for a dinner. As you can see, this story sits much further behind the functionality. It explains which context the user is in, what is their ultimate goal way beyond the interaction with the system and how this particular interaction fits into their experience, into their journey. It is pretty much up to you which format you choose and which format you think will work better on your projects and will appeal better to your stakeholders.

One thing you could do is you could combine your persona with your context when using user stories. That’s something I do on my projects quite often and I find it working really well. So what you do is in addition to the first statement as a role or as a persona, you add another statement who resides in a certain context. Let’s have a look. As a current bank account holder who wants to go out for a dinner, I need to access my account so that I can withdraw cash. As you can see, this format combines the elements of both original user story and job story, explaining who the persona is, what is it they want, which value they want to get out of it, and in which context all of this happens.

So why do we use stories? Stories represent stakeholder needs using short, simple documentation and they invite exploration of the requirements through conversations with your stakeholders about what a particular story means to them. Also through producing acceptance tests to your user stories and any extra documentation to represent the requirements as needed. However, not all of the user stories will be feed for purpose. There is a nice checklist that you can use to make sure that your stories are really good enough. It is called invest. So Invest is an acronym and each letter of this acronym stands for an attribute of a good user story. The first one. I stands for independent.

Each user story should have no inherent dependency on other stories. So each story theoretically should be able to be addressed on its own without any dependency on other stories being developed first. This allows you to have a backlog that is very easy to prioritize picking up only the stories that are available and not being bound to internal dependencies between the stories. N stands for Negotiable. The team should be able to negotiate how to deliver a story. A story should not be prescriptive about the solution to the problem, it should describe what the problem is and what is the need that we are trying to satisfy, not exactly how we’re going to satisfy it. V stands for valuable. Each user story must be delivering value to the customer. If it doesn’t, it is not good enough to be in your backlog.

E stands for Estimable. It means that each story should be written in a way that allows your team to estimate it to understand how much effort they might need to spend to deliver it based on their past experience. S stands for small or size. Appropriately, it means the user stories are sliced down in small enough chunks for a team to complete them in one iteration. You don’t want to have a user story that would take months and months of effort to be implemented. This one will need to be broken down into smaller stories so that each one can be implemented within one iteration for your team. Finally, T stands for testable.

Each user story can be validated objectively by a stakeholder. If it is written in a format that does not give you any way to validate that the story is delivered, it should be addressed again and rewritten. It is also important to remember that the user stories will describe the desired state rather than the steps to achieve that state. What it means is every story in your backlog will describe an element or subset of your solution or product rather than the activities that your team is going to undertake in order to get there. In this manner, your backlog is a good indication of your progress towards delivering the value that you committed to deliver. Otherwise, when you track your backlog items as activities rather than stories, you don’t really know how much of a value have you delivered. What you do know is how much of effort you have spent, which is a very different metric. Now let’s have a look at a few example user stories for our paying the bill experience.

The first one could read something like this as a customer who has an outstanding bill, I want to receive an SMS reminder to pay the bill so that I don’t miss the payment. Another one can be like this as a customer who receives SMS bills, I want to see the due date and payment amount in the SMS so that I know when and how much to pay. And a final example can be this as a customer who receives SMS bills, I want to see a phone number so that I can pay immediately via a phone call. User stories have many advantages such as being easy to understand by the stakeholders and facilitating collaboration between them. They are also very easy to pick up and start using.

It’s an easy format that anyone can use. However, they do have some considerations. First of all, being caught up in the user stories, your team may lose sight of a bigger picture. This is why having a clear product roadmap is really important. Some teams will take time to get used to user stories because these stories provide less level of prescription compared to more traditional software requirements specifications or business requirements documents. Finally, user stories tend to spawn more user stories through the composition. So the information must be organized in a way that ensures your stories are current and relevant. The collection of user stories in your backlog will need to be revisited regularly to be refined and prioritized. So to get your user stories organized, you may consider using tools like user story maps and we will talk about it in the next video.

3. Story maps

A user story map is a tool that is used to assist in creating understanding of product functionality. Also it can be used to understand the flow of usage and to assist with prioritizing your product delivery. Imagine that you’ve got a lot of your user stories in the backlog. If you have hundreds of them, it’s not easy to manage this amount. You need to bring some structure so that that it’s easier to navigate the user stories and to make decisions regarding their importance.

This is when the user story map is really helpful. As you can see, the story map is broken down into sections. First of all, it’s broken down into higher level stories or sometimes they are referred to as themes or user activities. These are the bigger chunks of customer journey that you are going to implement in your product. For example, paying a bill can be such a big chunk, or maybe a smaller one like receive your bill can be a chunk like this. This theme or this high level user story will be broken down into lower level stories, sometimes referred to as Apex or user tasks. This can still be pretty big to be delivered in one go, although smaller than the biggest themes.

An example can be to receive a bill via SMS or receive a bill via an email. And then within each you would detail individual user stories on the level. Sometimes they refer to as steps or just stories. Then you plot your user stories underneath the epic they belong to, underneath the theme that they belong to. And this way you transform your flat structure of a backlog, just a list of all the stories into a twodimensional picture where you can see your individual stories plotted against the epics and themes that they belong to. What you can do next is you can start prioritizing these stories within those epics.

As you can see on our example, we’ve got release one, release two and a tiny bit of release three there, which means you can allocate these stories to releases on the same map. So the map will show you all of your stories broken down by bigger elements of the solution such as epics and themes, and also broken down by the relative importance when they’re going to be released, which release they belong to. These two altogether will allow you to manage the product delivery and to track the progress against your releases as well as against your bigger solution modules.

4. Storyboarding

Storyboarding, also known as dialog, map dialog or architect navigation flow and even sometimes referred to as customer journey, is a technique for understanding how people will actually use the solution. Storyboarding is used together with other techniques such as use cases or user stories and prototyping to detail visually and textually the sequence of activities that will sum up different different user interactions with your solution.

Storyboarding is used when formal prototypes may be unnecessary or too expensive. When used to describe the interaction with a software system, the storyboard shows how the screens are likely to look like and how they will flow from one to another. When used to describe the business organization, the storyboard shows the interaction between the user and a business process such as back office. Let’s have a look at an example of a storyboard. So this is my mirror board for Storyboarding. I’ve got this canvas here as a template. You can create your own and as you can see, Storyboard consists of a set of scenarios. Each scenario has two placeholders.

One placeholder for the visual. It may be a mock of your interface of your screen, a wireframe or a set of wireframes. At the same time it may be a business process, diagram or some other visual that explains what is going on in this scenario. And you have a placeholder for your textual description of the scenario, what is happening there. When you are producing your scenarios, you then can take them and show to your stakeholders to potential end users as a substitute for a proper prototype and ask questions about these flows and tease out some information from them.

So basically you can take them into your user testing sessions instead of a prototype if you don’t have one, or if you feel like investing in a proper prototype maybe too early or too expensive for you. So let’s have a look at how scenarios may look like. The first 1 may be our scenario. When you receive an SMS reminder about your bill, say five days before the due date, you receive a reminder that you got a bill to pay. And maybe that reminder might have some call to actions how to actually pay it on the spot. So first I just type in the text what is happening in this scenario?

So you have five days left to pay your bill and you receive an SMS, right? And now I add some visual to this scenario. I will use mirror feature to find icons and I will search for a phone, give it time to load. Okay, and now I will use this phone as my visual for this scenario. I will add some text of the SMS, something like this and I will add a call to action, for example, a phone number that person can use to pay their bill. So this is our first scenario. Five days left to pay your bill, receive an SMS. This is how the SMS is going to look like and you can take it to your customers and ask questions how they are likely to react to this SMS or what they are likely to do next. Another scenario can be an example of a process flow.

In this case, let’s think about the next step in your scenario. You receive this SMS and you want to pay so you call the contact center. So you call the contact center and now in the visual part of it we will describe the process flow, how this is going to look like. Once again, I’m going to use some icons. Let’s say this is our customer and then I will add another icon for my call center person. All right? And now I will play a dialogue between them. I hope it is still readable. So the person the contact center asks center question and then the person calling will explain what they need to do.

I need to pay my bill. And then the contact center representative will ask some follow up questions to be able to protest this payment. For example what is your bill reference number? And then the person replies with some number and what happens next is the call center representative will move the call to automated line to accept credit card details and process the payment. And finally, we need some scenario that will conclude this whole journey. Let’s say it is another SMS that will confirm the payment and the SMS may look something like this your bill is paid, this is how much you have paid and this is a link to get your receipt.

So this is a simple example of how you can use Storyboarding to visualize or prototype your product without an actual prototype. What is good about it is you can easily use it instead of prototypes to talk to people, to get their initial feedback and to make some decisions whether certain elements of your products are going to work or are not going to work and then enhance it going forward without spending any time actually building things. When do we use Storyboarding? We can use this to elicit, elaborate, organize and validate the requirements. It can also be used to communicate what needs to be built and to assist with visual design.

 It can show different variations of the proposed solution and it can align stakeholders with the vision of the proposed solution. It can also be used as an input to tests. As you can see, Storyboarding has a variety of applications, all thanks to the following benefits. First of all, it can significantly reduce abstractness caused by other techniques such as use cases or user stories. It can be produced quickly and at a very low cost compared to other techniques such as prototyping.

And the intuitive nature of the Storyboard encourages stakeholders participation. It has, however, some limitations. First of all, it has a different look and feel than the final product. It is also easy to get into this solution mode when you’re storyboarding and you may accidentally focus on how rather than why. And finally, it is easy to miss some significant rules or constraints due to the concentration on the vision.