Archive | User Stories and requirements RSS feed for this section

Applying Customer Journey Map for capturing As Is experience across a suite of products

16 Oct
There are two capabilities we plan to include for users in the feature set we are currently working on: adding persons and vehicles to a CAD call. While it sounds simple, this work becomes quite challenging because it affects multiple products used by different roles.  In the past I have already done the investigation on the side of the product I am working on (911 incident dispatch software) and that research gave me a relatively good understanding of the work to be done in the context of dispatch software.
Information coming from dispatch however can be utilized by other personas like first responders (fire fighters, police officers, command staff) and record clerks (records division in police departments usually) meaning that there are integration points in system workflows between dispatch and responders, booking officers and record administration. This also means that whatever we want to build, needs to be designed in such a way it could be integrated into all those workflows that I still did not have a good understanding of.
I needed to understand the integration points between our part of the puzzle and the other products before putting together a vision of the to-be state for user flows we were planning to add. After thinking about the tools that could let me do that, I ended up selecting customer journey map for definition of as is experience and user story map for description of the to-be state of things.
Below I am sharing my experience with the technique and some of the observations.
I am not going to speak much on the topic of how great customer journey mapping great and provide a lot of details on all of the scenarios where this tool can come handy. There are existing great articles already that can tell you more about customer journey map: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/3367/Customer-Journey-Mapping-for-Business-Analysts.aspxhttps://www.slideshare.net/vedenin/customer-journey-mapping-for-business-analystshttps://conversionxl.com/blog/customer-journey-mapping-examples/, https://experience.sap.com/skillup/discover-your-wow-factor-with-customer-journey-mapping/. There are even tools online that you can use to start building your CJM (e.g. https://uxpressia.com/).
The reason I have chosen cjm is that this tool provides a way to decompose user’s interaction with a product or a company in general from high-level tasks and goals to very specific steps and elements the person is interacting with. Besides that, the tool can help to capture the emotional aspect of interacting with the software pinpointing areas of experience today that are causing frustration and are subjects for improvement or on the contrary cause delight and therefore should not be lost.
My plan was to organize a two part meeting where during the first meeting we would build an as is cjm involving person and vehicle information and then during the second part of the meeting we would assemble the to-be part of the process primarily affecting dispatch. Spoiler alert: the second part of the meeting did not work out very well and that is one of the lessons learnt from this exercise. Nevertheless, the part where we have described as is experience, worked out pretty well.
 
Theory
CJM allows to convey the story of using a product through quite a few lens:
  1. Persona – a specific type of the user / customer who is working with the software
  2. A certain segment of user’s entire experience with the product (finding out about the product, using the product, interacting with support)
  3. User goals (understanding what the user is trying to achieve during that specific part of the process)
  4. Touchpoints (parts of the software, specific persons a user is interacting during their experience with the product)
  5. Process / tasks (actual steps of the user, specific actions they take)
  6. Emotion (feelings the software invokes during the process of experiencing it, be those positive or negative)
These lens are coming from Uxpressia’s CJM template (see image below). SAP presents a slightly different view – you can review it by following one of the links above.
Excerpt from CJM
The idea of the technique is to break down the experience of a product by a user to phases and then go through the specific steps in each one of those phases to understand areas of improvement that then can be used as the rationale for new projects and become target outcomes whose project strive to achieve. The length of the process of preparing a high-quality CJM can vary from hours (for smaller products) to weeks (researching the CJM of interacting with a large company like an airline) and can consume a lot of resources.
Preparation for the workshop
Since I was planning to have a 2 part workshop where both as is and to be would be explored, I invited product management representatives as well as onsite developers and quality assurance from my team. There are pros and cons for doing it this way. On one hand, developers may not be as effective in contributing to the as is process since typically they don’t interact with users as much as product management does. On another hand, product management representatives from other products may not necessarily be the best audience to come up solutions specific to your part of the product that they not be very knowledgeable about. The one definite positive outcome of such a team setup is that at the end of the workshop, both development and product management come to a shared understanding of what is typically happening in the product today. In my opinion, another positive side of this setup is that everyone is more alert to the meeting because the conversation about how the interaction takes place is happening now and there are questions being asked and eyeopeners coming up this very moment
Since I knew I was pressured on time, I tried to focus on phase, touchpoints and process for specific personas skipping emotions however those did come up primarily after realizing the deficiencies in the existing workflows.
To actually conduct the workshop, I needed to have some preparatory materials explaining the customer journey map (I had my materials ready from a workshop I ran in January with dispatchers so I planned to reuse those), my rough understanding of the existing cjm (in case the whole conversation turned out to go the wrong way, I needed a plan b that could be used to trigger thought process in the group), and a few reminders (I’ve printed out images of some of the most used screens in the system to remind attendees about the workflow users were going through). That actually proved to be helpful when identifying pain points in the existing flows.
I also took a few large paper sheets we usually use during our periodic SAFe-based release planning (that is something worth another topic on its own) and placed them on a wall.  The idea was to use the drawing board for as is process and then switch to to be and map it out using those sheets glued to the wall.
As for the group size, the workshop included 3 product managers for products that represent a large set of the entire suite, myself, 2 senior developers, 1 QA and 1 UX designer who was primarily observing what was going on. I have sent out the invites in advance however I failed to mention that the workshop is intended as a primarily offline activity. Because of that one of the product managers was present remotely constantly watching what is going on via a camera.
The exercise I prepared as an introduction to cjm is quite simple and easy to do. It is a task to draw a map for ordering food for a family gettogether on a Sunday evening while watching a movie. I have prepared a few slides explaining what I would expect from the participants and even did my own cjm for that in case things really go south however once I’ve explained what I want: phases, steps, touch points and told them it was ok to draw using blocks everything went really smooth. You can review the full example here https://docs.google.com/presentation/d/1BBmLfWXaE6BEAoWYisx4rou8J5lp8vdN_sdyffK43dI/edit#slide=id.p
Lastly, to run the workshop I also needed to define the approach – whether it is scenario-based and we review everything in context of a certain nature of a 911 call or it is a generic 911 call and we try to outline all of the possible branches the call process may follow. After a discussion with a UX designer, I came to a conclusion it was best to focus on specific scenarios rather than describing a generic call that would add too much often irrelevant facts and make it really easy to forget specific steps that may come up only for certain natures (i.e. how an in progress robbery is handled may differ from a suspicious person or domestic violence call).
The workshop, actually
The workshop was scheduled for 2 hours with the first hour dedicated to investigation of as is experience. It actually took 1.5 hours and one of the contributing factors was that not all of the participants realized it was an offline meeting only so some of the time was eaten communicating updates to the person online however we found a way to mitigate that more or less.
Before we have started I have shared the agenda that included the following main points:
  1. As is process from a 911 call to what happens after arrest
  2. Integration points between P&V throughout different products
  3. To be process for person and vehicle entry
I have explained that we would be using the cjm for this and explained what cjm comes down to (the lens described above).
The first step was to determine the actual phases of a 911 incident and put those on the board. Initially, it felt more like a show and tell activity where I am standing in front of the board and everyone is waiting for me to write stuff and then nod in agreement or disagreement. That however was exactly the type of thing that I wanted to avoid. Because I was pressed with time, I skipped the exercise of trying to draw our own cjm for a pizza evening and very briefly explained it by drawing the blocks representing phases of the process (Determine food, find pizza place, find the right pizza, order, get delivery and enjoy the meal). I had to call everyone to the board to make sure engaging the participants into the conversation was really easy. That actually helped and everyone being closer to the board and given an actual marker had more rationale to do something.
The product managers were the ones who helped me to define the actual phases (911 call, CAD Incident, Arrest, Booking, Report, Report to prosecution, IBR report, Court case, Sentencing and Jail Management). Since the software we are developing does not cover some of those phases like Report to prosecution, court case and sentencing), those were mentioned with diving deep into details of what actually happens in those workflows.
The next step was to actually find out what is being done process wise by involved personas during each of the phases under discussion (911 call, CAD incident, Arrest, Booking, Report, IBR report).
I have used a specific example (domestic violence in progress resulting into arrest). Domestic violence is a frequent flyer in the world of 911 incidents where one of the spouses exerts verbal and/or physical violence onto their partner or children. This scenario may evolve into a variety of others including homicide, shooting, manslaughter, etc.) and can be a good starting point to understand all of the involved public safety processes
Adding meat to the bones
During this part of the workshop, we focused on adding actual details to each process phase. CAD Product manager added details related to the 911 call and CAD Incident.
Resulting As Is map
22555920_10155803295224127_1194948475_o (1)
Advertisements

Business Analysis, design thinking and movie making (Pixar)

16 Apr

During a trip to Spain I have visited Pixar exhibition at CaixaForum in Barcelona. The expo described 25 years of Pixar’s animation history, their projects and approach to movie making. I was surprised to find out how meticulous and detailed their approach was. Also, I was surprised that their design process appeared like a very firm, thought-through combination of waterfall and iterative approaches. It was also interesting to learn that Pixar started as an actual technological startup that provided hardware and software products for animation for example for Disney.

I was not allowed to take pictures in the exhibition hall but I’ve tried to memorize some of the items that really stroke me. So, Pixar’s approach in a nutshell:

  1. Story
  2. Script in text
  3. Storyboard and digitalized storyboard
  4. Video reel using storyboard
  5. Storyboard in color
  6. Modeling and prototyping i.e. to create actual physical objects
  7. Rendering and filming
  8. Voice over

Here is an article about pixar animation approach with more details

I may be missing a few steps in between but what I recall is that the part before rendering the movie took roughly 3/4 of the entire process. Before starting to actually film, there is a story and a script written, designers then draw and prepare storyboards without considering actual implementation and any technical constraints. This is done so that designers free their minds to the maximum and stay as creative as possible. The engineers will then try to figure what and how can be implemented but in the beginning, this is a no limit stage.

This part (no limit creativity at the time of design) reminded me of a couple of stages in design thinking process – what if and what wows. According to a number of sources, there are 4 main questions that drive design thinking process: what is, what if, what wows and what works. The story  part of the process seems to match to the “what if” phase where the character is invented and is put into an unusual environment/story  in which the character will need to act in an usual manner to fully uncover the potential. The storyboarding and its digitalization reminds of “what wows” as at the storyboard and modelling stages the concept of what is going to be in the finished movie is prepared and tested. All of the images designed here will be then rendered using computer graphics but it is the quality of the thought and creativity put here that will define how successful the movie will be.

When I started thinking about this more, I’ve realized that their process also reminds of a part of software developement process and can be mapped to it quite nicely together with some of the deliverables produced at different stages of the process.

  1. Story corresponds to a product vision and helps to understand what the product is going to be all about and why it is distinct
  2. Script corresponds to use cases as it provides the interaction view on everything happening in the product (business and system level)
  3. Storyboard can be mapped to both the storyboard/navigation flow as well as the wireframes
  4. Modeling and prototyping is the actual prototype of the app, either in prototyping app, paper or in code
  5. Rendering and filming with the voice over is the actual implementation/development of the product at the end of which there is a finished product (in most cases :))

What is interesting however is the difference between time and effort spent on script, storyboarding and prototyping  vs actual development. Unlike in agile projects, development moves forward only when the “thinking through” part is over and everything has been completely defined. Characters/personas have been defined to their fullest, all interactions have been written in great details and there is clarity on the sequence of events from start to end. I could see how much research and analysis goes into character design after  seeing in the part of the expo dedicated to “bug’s life” the drawings of different types of bugs in their actual sizes and comments on proportions of parts of bodies. There were even drawings of different types of bug eyes to make sure actual biology is taken into account so that the designed character looks realistic.

Of course,there are differences between movie making and software development but in general I get a feeling that it is worth to learn more about design approach in movie making and see what parts of it can be reused in business analysis and product design parts of a software development project. One idea that comes to mind is to write requirements documentation more like movie scripts (maybe that would at least make people want to read them :)) and rely on storyboarding a lot more heavily. It would also be interesting to learn about script and storyboard review processes in movie making to understand how exactly that happens and how many people get involved in such activities.

Pixar has produced a handful of movies but each one of them is a masterpiece and I feel like there is a lot to learn from them and movie making projects in general about how to make commercially successful products that meet different constraints.

Useful Links for a Business Analyst

15 Apr

Alright, it has been a long time since I’ve posted anything.

I am going to frequently update this post with useful links

QA+BA Sandwich – getting to the meat of user stories

25 Nov

Right now, this is just an idea I would like to research – more specifically, how to put together QA and BA work at the user story writing phase. My assumption right now, is that we can start testing before software is built and before it has actually started being built. The only problem is that I don’t know how exactly that should work.