When Visual Models are Better than Textual Requirements (Part III: User Flow Diagrams)

Let’s face it, textual requirements are not great at clarifying the sequence of interactions a user has to go through as they try to accomplish a task or achieve desired outcome. Use cases can be a little better, describing the steps that demonstrate all interactions the user has with the system. Take for example Scott Sehlhorst’s example of an online purchase, in which the normal flow goes like this:

1. The user will indicate that she wants to order the items that have already been selected.
2. The system will present the billing and shipping information that the user previously stored.
3. The user will confirm that the existing billing and shipping information should be used for this order.
4. The user will confirm that the order information is accurate.

5. […]

Still, when you’re trying to convey to business and technical stakeholders the journey the user will have to go through to accomplish a goal like making an online purchase, a visual representation describing the specific sequence of action leading the customer to the desired outcome is going to be much better. As explained in this article from Signal v. Noise, 

Flows written down into stories or paragraphs are hard to reference and they don’t easily decompose into checklists for design and review.

The article shows how to create one of my favorite visual representations: the user flow diagram. Below is my adapted version of the main component of this type of diagram:

Shorthand to represent steps in an interaction between user and system.

Sometimes, users may choose different actions as their next step, in which case we can use a modified version, like this:

Alternative notation for more complex flows

Let’s take a look at the online purchase use case described using this notation (in the scenario depicted, a registered customer has logged in, added products to a shopping cart, and is ready to start checkout):

Don’t you find it much easier to visualize the different scenarios that need to be accounted for using this type of diagram compared to textual requirements or even a use case?

For example, when the customer is looking at the “updated shopping cart”, in this diagram it’s easier to identify all the potential steps he/she would want to take from there:

  • Change their mind about a product or quantity, and update the shopping cart.
  • Proceed to checkout.
  • Decide to continue shopping.

Now you can account for all these actions that users may want (or need) to take in your textual requirements, use cases, user stories, wireframes, or other artifacts that may be used to produce a shared understanding of what needs to be built. Through conversations with business stakeholders (and ideally end-users as well), you may identify additional paths that should be available to improve the overall user experience:

From “Form with fields to enter new billing and/or shipping information”:

  • Optionally save the new information in the customer’s permanent records (if this is meant to be the new default for the customer as opposed to a temporary choice).

From “Order details”

  • Quickly edit products or quantities in the cart, or billing or shipping information, without having to go back multiple steps.

Note that these additional requirements could be considered “nice to have”, and simply added to the backlog for future consideration. Still, as with the relationship map described in the last article, this kind of  visual representation increases the opportunities to identify f potential improvements to the workflow.

The main difference between the user flow diagram described here and a relationship map or swimlane diagram is that the user flow places more emphasis on the user journey, highlighting all the steps required by a user to accomplish a task or a achieve a desired outcome. For that reason, they are particularly useful when you’re trying to identify and communicate requirements for customer-facing applications, since in this case providing an optimized user experience through a more pleasant sequence of interactions with the system can become key to ensuring better business results through improved customer satisfaction, loyalty, and retention.

This is Part III of a series. Read also Parts I – State Diagrams and II – Relationship Maps.

When Visual Models are Better than Textual Requirements (Part II: Relationship Maps)

In this series that starts with Part I (State Diagrams), and ends with Part III (User flow diagrams), I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.

# # #

As a business analyst working on software projects, you’re probably asked to draw a lot of diagrams. Sometimes it may be hard to understand why, when textual requirements is what’s traditionally required to get “sign off” from stakeholders for what needs to be built. But as we started to see in Part I: State Diagrams, visual representations can help you understand what questions to ask to uncover potentially hidden requirements, reconcile differing viewpoints about what the system is meant to do, and communicate the big picture of a solution being built incrementally, among other benefits.

In this article of the series, we’re going to take a look at relationship maps. While state diagrams focus on a single business object and how it transitions states in response to conditions and events, and process maps depicts the sequence of steps that transform inputs into outputs, a relationship map highlights the inputs received from external parties (customers, providers, partners) and the outputs provided to them, as well as the functional areas involved in handling those inputs and outputs and the handoffs (inputs and outputs) within the organization.

Imagine that you’re starting to work on a system to automate invoice processing for a hardware repair company. A relationship map for the project could look like this:

Because the diagram focuses on the affected business functions and their inputs and outputs, it’s easy to determine the cross-functional relationships between these functions (engineering, account management, finance) and the external actors (customers and providers). After building this map, a BA could identify a potential process improvement opportunity in the handoff of invoices to the customers (highlighted in orange above).

The analyst could ask relevant questions to stakeholders, such as, “Given that the finance department is responsible for generating the repair invoice the customer gets and receiving the payment, does it still make sense to have the handoff of the repair invoice from finance to account management before it reaches the customer?”  The proposed change would be captured in a relationship diagram like this:

But now, comparing it with the previous version, it’s easy for the BA to see that the account management is left “out of the loop” regarding the completion of a repair order, previously signaled to them via the customer invoice forwarded by the finance team. We can then modify the diagram again, to make sure the notification still happens (see added green arrow):

Note how in this version the customer still has to submit a repair request to the account management team, responsible for validating the terms, such as the service level agreement the request has to adhere to. But account management no longer needs to be involved in the customer invoicing process: the finance team can invoice the customer directly. However, since in the “as-is” process the invoice received from finance served as the notification to the account management team that the service had been provided, we now need to extend the “repair complete” notification issued by the engineering team to the finance department (for invoicing purposes) so it also reaches the account management (new green arrow).

Showing the first and last diagrams (as-is and to-be ) above to business stakeholders makes it much easier for them to understand the recommendation for the process change compared to writing a textual description of the proposed changes and directly asking for sign off for the final requirements. Once the process change has been well-understood and approved, a textual requirement can be created to communicate to the development team what needs to be built and tested:

When the engineering team marks a repair service as complete, a “repair complete” notification will be forwarded to:

a) the finance system (existing behavior, which already triggers the invoicing process); and

b) the account management system (new functionality that will update the order status in the account management system so that account managers can have the information readily available when interacting with customers over the phone).

# # #

Visual representations of business functions involved in a business process, like the one provided by relationship maps, can be extremely useful for identifying areas of improvement and communicating proposed changes in existing processes. Relationship maps offer an excellent view of the key business entities and the inputs and outputs that flow between them. They can also serve as input for the creation of other useful diagrams such as a process map, with the functional areas becoming lanes in the diagram. By not focusing exclusively in one type of visual representation of the business model, BAs can dramatically reduce the risk of overlooked requirements or missed opportunities to improve business processes.

# # #

Looking to take your textual requirements and visual models to the next level? Join the waiting list for the coaching program Crafting Better Requirements.


When Visual Models are Better than Textual Requirements (Part I: State Diagrams)

In this series, I show how different visual models can help you create better requirements. If you don’t want to miss the next installments, make sure to follow me on LinkedIn or subscribe to our infrequent updates entering your email to the right.

# # #

The ability to write high-quality textual requirements is a skill highly valued by many organizations, in particular the ones that have suffered the negative consequences of poorly defined requirements: project delays, cost overruns, expensive rework, dissatisfied users.

But visual models are also key to preventing misunderstandings and missing requirements as a business analyst specifies system behavior for an agile or traditional software project. A process map showing the sequence of steps, inputs, and outputs needed to handle a business process across multiple functions, a relationship map showing what information and products are exchanged among internal and external actors, a state diagram describing the behavior of an object over time — all these models can be extremely useful to facilitate the knowledge transfer about how a software application will support a business process, and uncover requirements that must be a part of the solution.

Let’s look first at state diagrams. A state diagram is a model suitable to when you’re trying to answer questions about the lifecycle of a business object: what states are allowed for it, what events trigger a change in the current state.

Example of state diagram depicting the states for the object “Contact” in an email automation application

The object (or data entity) can be anything that the business (and the information system that automates it) must keep track. For instance, a blog post in a content management system that can transition from “draft” to “published” and “deleted”, or a contact in an email automation system that can have the states of “subscribed”, “unsubscribed” and “deleted” (as in the example above), or a product in an ecommerce platform that can be in the states “in-stock”, “out-of-stock”, or “discontinued”.

Why draw a state diagram?

It’s possible to surmise the behavior of a business object over time analyzing requirements and use case descriptions. For example, one could gain an understanding of the contact object in a marketing automation system by noting how it’s handled in the requirements for User Subscribes to Mail List, User Unsubscribes from Mail List, User is Deleted by System When Email Address No Longer Exists. But if the state of the object is critical for the system (e.g., the business could get in trouble if contacts who unsubscribed from the company’s mail list are kept in the Active state by mistake), it’s helpful to be able to get the full picture of the object as it passes through the system.

Let’s say you’re writing requirements for a content management system. By drawing the desired states for blog posts (“draft”, “published”,  “deleted”), you could more easily identify all desired transitions (for example, not just from “draft” to “published”, but also from “published” back to “draft” to allow an accidentally published post to go back to draft where it can continue to be worked on). If your requirements didn’t account for this scenario, content managers would have to go through multiple steps to fix this mistake, copying the content to a text editing tool, deleting the published post, and creating a new draft.  The diagram would quickly highlight the missing transition to be incorporated into your requirements (“A content manager can revert a post from published back to the draft state to allow for more work to be done in a post prematurely published by accident.”).

What next?

Just reading articles or books about a business analysis tool or technique won’t get you far. To truly master the use of the technique, you must practice it in a context in which you receive expert feedback. Otherwise, you can end up like a senior BA who when asked to produce a state diagram to represent the states and transitions for gift certificates while participating of Crafting Better Requirements, created this:

Clearly the BA misused the term “state diagram” here.  “Purchase Gift Certificate” and “Redeem Gift Certificates” are not states of the object “gift certificate”. These are user goals that can be represented by use cases and business process diagrams. A valid state diagram for gift certificates would describe the states a gift certificate can be in (e.g., “created”, “delivered”, “partially used”, “depleted”) and what events would cause a gift certificate to transition from one state to another.

Luckily this senior BA made this mistake in a safe environment of a coaching program as opposed to in front of his manager and stakeholders at work. To avoid damaging your reputation due to flawed models like this at your job, see if you can enlist the help of a knowledgeable colleague to provide honest feedback for the diagrams you draw before you share them with a larger audience. Or take it a step further and do like the hundreds of BAs who decided to take their requirements writing and modeling to the next level by joining the Crafting Better Requirements program.

# # #

Read also Part II: Relationship maps and Part III: User flow diagrams

Goal setting: good or bad?

The advice “stop focusing on goals” was popularized in books like How to Fail at Almost Everything and Still Win Big: Kind of the Story of My Life by Scott Adams and Four Seconds: All the Time You Need to Replace Counter-Productive Habits with Ones That Really Work by Peter Bregman.

The authors’ premise is that establishing areas of focus and putting our energy into “systems” or habits can lead to better results than setting reach-it-and-be-done kinds of goals. Having goals can lead to myopia and the feeling of discouragement and stress, they say, while instituting areas of focus and routines broadens our perspective and makes the process of improving our situation more pleasant and rewarding.

Numerous other authors take the opposite stance, saying that goals are crucial to accomplishing great things in life. Who is right here? In my opinion, neither group has the answer.

Beal Projects’ two-pronged approach to achieving desired outcomes

In the framework I, Adriana Beal, developed for personal use and to help the participants of my coaching program to reorient their career in a more compelling direction, there are two complementary tactics:

Tactic #1: Finite, “from A to B” goals

Tactic #1 is about defining a specific outcome we are trying to achieve. The idea is to transition something (us, a business, a process, etc.) from point A to point B. A reach-it-and-be-done goal is extremely useful to help us focus our efforts. Instead of just relying on habits and routines (e.g., “I will read a book a month to keep building my competencies”) that may lead to unfocused efforts, a finite goal lets you concentrate on a specific outcome (e.g., “I will master machine learning by the end of the year”) that leverages our positive habits and routines to take your performance to the next level.

An effective “A to B” goal may look like one of these statements:

“Boost revenue by 20% this year”
“Drive down purchasing costs by $1 billion over the next five years”
“Find a repeatable and scalable business model”
“Halve the time it takes to respond to customer complaints”
“Get a job at a Fortune 500 corporation”
“Become more knowledgeable in predictive analytics”
“Lose 10 pounds”

Once a finite goal is achieved, it may need to be replaced with another goal that makes sense after “point B” is achieved. For instance, after achieving the goal of finding a repeatable and scalable business model, a startup would shift its focus to scaling the business, which becomes the next goal.

Sometimes, after a goal is achieved, it must replaced with permanent habits and routines (tactic #2 described below) in order to produce lasting results. For example, after achieving the goal of losing 10 pounds, a person could shift its focus to maintenance, changing the strategy from temporarily food restriction to long-term exercising habits and routines to prevent the weight from creeping back on. Or, after meeting a cost reduction target, a company may shift its focus to making the cutbacks sustainable, rather than risking decreasing quality or service by trying to further extend their cost reduction efforts.

Tactic #2: Permanent habits and routines to keep us on the path to success

In addition finite, “from A to B” goals, we need to identify the habits and routines that can keep us on the path to success, however we define it.

Imagine a person who defines success as living a life free from health and financial worries. They know that in order to achieve this desired outcome, they need to overcome some self-defeating behaviors, such as being sedentary, eating junk food, and failing to pursue skill development opportunities that can be translated into valuable career opportunities. Developing good habits such as packing healthy snacks to bring to work and regularly scheduling blocks of time to learn new skills free from Internet distractions may be key to staying on track with this long-term goal.

The verdict

Rather than picking a side on this fight (“goals are counterproductive” vs. “goals are the key to success”), a better option is to use integrative thinking to incorporate both ideas: well-designed goals that mobilize our efforts toward the removal of obstacles in the way of a desired outcome, and recurring patterns of behavior that are critical for getting us closer to our long-term aspirations.

If you think about it, the chances of success are increased by a combination of positive habits and behaviors that with time-bound goals dedicated to overcoming an obstacle in the way of achieving a desired outcome. The problem with goal setting is not the approach itself, but that it’s often used incorrectly. To quote from goal-averse author Scott Adams,

“A hammer can be used to build a porch or it can used to crush your neighbor’s skull. Don’t hate the tool.”

But how to identify the right goals and routines to adopt?

There is no shortcut to selecting the right goals or the right habits to cultivate: you need to do your homework, starting from your own definition of success and looking for proven ways to get you there. For example, research shows that chess students who study with coaches have higher national ratings compared to those who don’t. If you wanted to become a chess master, it would make sense to first set a goal to do some research to find a good coach, and then  replace it with a routine of deliberate practice under the coach’s supervision.

If you study the trajectory of highly successful business analysts, you’ll notice that while there may be large differences in their career paths, they all share three critical attributes: the ability to generate valuable creative ideas to solve business problems, communicate these ideas in effective ways, and get buy-in for those ideas from decision makers. To elevate your role, get access to the most interesting projects, and build a compelling career, you need to develop laser-like focus on developing the skills that count the most.

Need inspiration for defining your next goal? Download the guide Beyond SMART Goals: Effective Goal Setting for Business Analysts.

Wondering which new habits to adopt to work your way up in the skill ladder? Check out our list of recommended superpowers all business analysts should be developing to remain relevant in a world of constant technology advances. 

Photo: Jonas Hosler (CC BY 2.0) 

Is it possible for a BA to concentrate on both Business Analysis and Business Analytics side by side?

A reader asks:

Is it possible for a BA to concentrate on both Business Analysis and Business Analytics side by side?

In order to have a productive conversation about a topic without getting derailed by misconceptions, first we need to eliminate any confusion about how the terms are being used. So here’s how I’m using the following terms throughout this article:

Analytics: The science of applying a structured method to solve a business problem using data and analysis to drive impact. [1]

Business analytics: The use of simpler analytics methodologies on past data. [1]

Advanced analytics: Everything else, including predictive analytics. [1]

Business analysis: The activities associated with defining and understanding business problems and determining the right solution. Such activities include problem identification, requirements discovery, analysis, specification, validation, approval, as well as knowledge transfer about desired outcomes, requirements, assumptions, and risks to the delivery team.

Just based on these definitions, it’s pretty clear that business analytics (as well as advanced analytics) can have a huge impact in the quality of business analysis. Analytics can help you understand the specifics of the problem you’re trying to solve, and add precision to decisions about priorities, requirements and design.

Here are some examples of how business analysts can use analytics to improve the quality of their solutions:

  • A BA working on the prioritization of change requests submitted by users of an internal application can use analytics to determine how many people would benefit from each of the proposed improvements and make prioritizing recommendations accordingly. (E.g., “500 users need to reply to a message in our platform each month, and in average each of these users replies to 10 messages a month. 30% of the time users have to change the “From:” field before replying so the message is sent from a shared account. The “reply-from” enhancement meant to facilitate changing the “From:” field will affect 500 x 30% = 150 users and 500 x 30% x 10 = 1,500 replies per month. We recommend bumping this improvement to the top so it’s implemented before this other planned enhancement that will only affect 12 users performing an average of 3 actions per month.”).
  • A BA working for a credit card issuer and responsible for a system that manages the credit card approval process examines historical data and notices that the company is showing signs of increased losses and incorrect actions for customers. She uses descriptive analytics to divide customers into multiple segments and recommends the company moves from the existing single model for predicting risk for all customers to distinct risk models that handle only a subset of all customers. The change improves the accuracy in risk modeling and creates millions in loss savings.
  • A BA working for a retail business and responsible for specifying a solution to enable the company to implement a survey to collect the preferences of its “high value customers” uses historical data to expand the reach of the customer survey.

As you can see from these examples, analytics helps BA find better solutions to the problems they’re trying to solve. Business analytics and advanced analytics are extremely useful problem-solving tools. Used well, they can make for better software products, happier customers, higher profitability, more productive employees, improved accuracy in risk modeling, quicker work turnaround, and all sorts of positive outcomes.

So to answer the reader’s question, not only it’s possible for a business analyst to focus on both business analysis and business analytics in the work they do, it can hep you dramatically expand the value you deliver to your organization.

How to get there?

You can’t be great at business analytics without getting out in the real world and start spending time with business data. If you don’t have an opportunity within your workplace, find a nonprofit to help, and get to work analyzing their survey results or Google Analytics data. You don’t need a PhD in statistics, but being familiar with basic statistics will greatly enhance your career as a business analyst with analytics expertise, so find some online resources to help you get a solid grounding on this topic. Statistics training will help you enhance your analytical thinking and look at business problems differently.

For tips on getting started with predictive analytics, check out the resources listed at the end of the article It’s time for business analysts to add machine learning to their “bag of tricks”

[1] Behind every Good Decision: How Anyone Can Use Business Analytics to Turn Data into Profitable Insight


Photo: Neerav Bhatt (CC)

A reader asks: Should the BA be responsible for providing design inputs for developers?

I’m new to the business analyst role (8.5 mos to be exact), and I came across your webinar “6 Mistakes That Lead to Missing Requirements” from Bridging the Gap. During the Q&A portion, a question came up about listing “solutions”, and another about some projects requiring the BAs to provide the developers high fidelity mockups. I’m in this exact situation right now. The team I am part of requires the BA to be the one documenting the design specifications. We’re not so much into understanding the requirements – the developers want to know right away what design specs to implement.

So my question is – is it really the BA who provides the design inputs for developers? Is it the BA who writes the design document? I’m really confused. If I simply give them the requirements (the conditions that must be fufilled), they wouldn’t know what to do. We are in an agile environment, so I know that the line delineating each role tends to get blurred, but I’m getting more and more pulled into the solution space as opposed to staying in the problem/requirements space.
I hope you could shed some light. Thank you!

Before I offer my answer to this question, let’s look at some facts:

1. Most software requirements can be satisfied by more than one software design.

It’s very rare that a functional requirement can only be satisfied by one particular design. For instance, a requirement for a webstore that says “the system will allow customers to write product reviews” could be fulfilled by many different designs, including a button “Write review” that when clicked opens a pop-up window, a link saying “Leave a review” that when clicked shows a sliding panel with the fields to be filled out before submitting the review, and a “reply to this message to leave a review” feature that automatically processes a customer review submitted via email reply.

And note that we’re not talking just about user interface design here. There are other aspects of software design, such as where to allocate capabilities across modules and components, which technical methods will be used to implement a feature, etc., for which there will be multiple designs capable of satisfying a given set of requirements.

2. Shortcomings in user interface design can dramatically limit the value delivered by a solution, even if it implements the right capabilities.

If you implement a requirement with a design that makes it difficult / confusing / time-consuming for users to perform a task, the negative consequences in terms of user adoption, productivity, etc., can be significant, to a point where the solution may deliver negative value to the business.

3. As with requirements, great design results from iteration.

The same way that producing quality requirements requires iterating on the problem domain to make sure the requirements address the right problem or opportunity, producing high quality designs requires multiple passes to explore and refine concepts in pursuit of the best solution.

Bottom line: design needs to be taken care of by *someone*, and the best teams wil have designers who collaborate with the rest of the team to design the optimal solution based on the agreed upon requirements.

As you can see from the three facts above, design is an important element that needs to exist separate from requirements and coding. Embedding UI design in the requirements is bad because you’re prematurely limiting how the requirements will be addressed (is a pop-up window truly better than a sliding panel to provide the ability to submit a review?), before different ideas can be explored. And leaping from requirements to coding is bad because it means the design will happen implicitly during coding, without considered thought. It’s like deciding to build a house based on the requirements “must have 3 bedrooms, 2 bathrooms, and 1 kitchen” without thinking through how to best allocate the rooms. You could end up with the requirements met but the residents unhappy that they have to pass through the kitchen every time they want to go from their bedroom to a bathroom, or dissatisfied with the high cost of temperature control because room placement didn’t take advantage of the position of the sun.

An additional benefit of separating design from requirements is requirement stability. If you’re embedding design into your requirements, and the user interaction has to change (say, from clicking a button to using a dropdown) because of a technical constraint or to maintain consistency with how other user actions have been implemented, your requirement (the capability or condition the solution must meet) doesn’t have to change. This can save significant time, ensuring your requirements documentation (e.g., user stories and acceptance criteria) doesn’t have to change, only the design, and user acceptance tests if you’re designing those based on the user interaction.


The main reason we have so many BAs confused about their role and which documents they’re supposed to create is that in many organizations managers aren’t aware of the importance of separating requirements from design and design from coding. Typically in these organizations there are no designers on the team, and developers are rewarded by the number of lines of code written, or user stories implemented, or tasks marked as completed, rather than by truly solving the business problem. This means developers don’t want to “waste time” exploring different ideas on how to implement a specific capability. The BAs in these organizations are left with the task of producing the final design, often with insufficient time to dedicate to understanding the problem and articulating and validating the requirements before jumping into “solution mode”.

Now, should the UI (or, for that matter, the technical) design  be done by the same person doing the requirements work? I don’t see a problem with that, as long as the person has the skills and time to perform both jobs well. The reality, though, is that the skills required to produce great UI design are different than the skills required to create excellent requirements, and it’s rare to find the two sets of skills in the same person.

This means that having the same individual in charge of requirements and design may result in a design with great look and feel but that doesn’t solve the right problem (if the person has design skills but not business analysis skills), or a solution with usability issues (if the person has good analytical skills but not the knowledge or or talent to produce a good design).

Here’s an example that illustrates the latter, extracted from a previous project. The requirement stated that users would be allowed to upload up to 3 files concurrently. The BA created a wireframe that looked like this:

When the developer saw how cluttered the design made the page look, he suggested a different design:

(This is a low-fidelity representation created just to illustrate the point; the actual design looked much better.)

In this new version, in the (rare) occasions the user needed to upload more than one file he or she could click “Add more” and the system would add a second line for input. Users agreed that the design change made the page much more readable and efficient for the majority of users navigating from field to field using the tab key to fill out the form with just one file to upload.  If the developer just followed the specification provided by the BA, an inferior solution would have been deployed.

But note that regardless of the design choice here, having requirement statements documenting the expected behavior (“users must be allowed to upload up to 3 files concurrently”) is important to reduce the risk of a design choice failing to meet the actual requirement. People could get so involved in the discussion of the best user interface that they forgot what the original requirement was. With a design linked to an actual requirement statement, it’s much easier to remember to address details like the need to prevent users from uploading more than 3 files. Based on the stated requirement, a separate annotated wireframe could be created to show the state of the screen with input fields for 3 files and the “Add more” button disabled.

The most effective teams I worked with had one or more user interface designers available to work on software projects, taking the functional requirements produced by a business analyst and translating them into low- or high-fidelity wireframes in collaboration with the developers and the BA. The business analyst would remain involved throughout the design process, contributing with suggestions and validating that the UI design accommodates all the functional requirements and exception cases and doesn’t incorporate unnecessary capabilities that increases software complexity without adding value.

(The best teams I’ve worked with also had software architects in charge of developing and maintaining a solid architecture of modules and components that made enhancing the system easier over time and ensured performance, security, scalability and other quality requirements would be met.)

But what if I work for an organization that doesn’t hire UI designers and expects the BA to deliver design artifacts to the dev team?

In some organizations without designers, you may be able to find talented developers who have a passion for good user interaction willing to sit down with you to discuss alternatives to implement a given capability (as in the “file upload” example above). In other workplaces, programmers will be unwilling to engage in this effort, and the task will fall on your plate.

The best advice I can give to people who are in a situation like the one described by the letter writer is to try to educate your boss on the importance of separating requirements work from design work. Even if you can’t get help for doing both jobs, at least try to ensure that in each project you have time to dedicate to understanding the problem to be solved and writing requirements that are free from premature design constraints that you validate with your stakeholders before moving to the design phase. Even if your developers don’t care about the actual requirements, *you* should care and make sure that the wireframes you deliver accommodate all the functional requirements and address exception conditions that can arise. And if you don’t have a background in user interface design, you should also try to read about this topic as much as possible in order to avoid making egregious mistakes when creating wireframes for the development team.

And, when you’re looking for a new job, ask about the company’s practices as to what pertain to requirements, design, coding, and testing. If given a choice, go work for a company that already sees requirements as an essential step on the path from business needs to satisfied customers and for managers who insist on creating designs on a foundation of high-quality requirements, as this will dramatically increase your ability to deliver successful solutions.

The difference between an average and a high-performing business analyst

When asked to describe their role, many business analysts working on customer-facing software products or internal information systems use terms like “liaison”, “bridge”, “communication line”, and “translator”, typically referring to work they do to make sure “what the business has in mind for a computerized system is accurately understood by the technical team”.

This interpretation of the BA job is very limiting. It comes with an implied assumption that someone on the business side has done the proper analysis of the business problem, and the job of the BA is limited to finding a common language and ensuring the objectives between the two groups are aligned so that the need communicated by the business can be fulfilled by the IT or software engineering team.

Every time I started a position involving business analysis, I took a different approach, making my #1 job not develop requirements that translated the business and user needs into a technical solution, but to make sure all software solutions I worked on had a clear business motivation in sync with the business strategy.

This shift in perspective can quickly take you from a reactive to a more proactive position in your organization. Here’s an example to illustrate the difference:

Jim, the average BA

Tom, the business stakeholder: “Hi, Jim! We just received a report from the customer success team showing that we have a large number of customers complaning about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jim, the average BA: “Sure, Tom! Let me get right to work.”

Jim goes talk to the development team, discovers that the Orders Placed page takes between 8 and 12 seconds to download, and that with some significant work, can have its latency reduced to 4-6 second. He then writes the requirement:

“The Orders page shall download completely within 6 seconds over a 20 Mbps or faster Internet connection.”

Tom signs off on the requirement, and the work is handed to the development and testing teams. Two months later, the change goes live, but with little impact to the business in terms of customer satisfaction or retention. What went wrong?

Jane, the high-performng BA

Tom, the business stakeholder: “Hi, Jane! We just received a report from the customer success team showing that we have a large number of customers complaining about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jane, the high-performing BA: “Sure, Tom! Can I look for a 15-min slot on your calendar for us to go over your findings and make sure I have all the information I need to proceed?”

Tom, the business stakeholder: “That works, thanks!”.

Jane talks to Tom to gather more information. She also schedules some time with the head of the customer success team and the system’s tech lead to better understand the context of the complaints received, and learns the following:

  • Only customers using the old version of the application are complaining that the Orders Placed page is too slow.
  • The latency of the Orders Placed page has not changed between the old and the new version. What changed was simply that the new version uses incremental rendering to start displaying content as it becomes available, rather than waiting to display the complete page only after it’s fully downloaded. Even though in the new version the customer still has to wait until the page is entirely downloaded in order to interact with it and get the information they need, the perception of slowness is no longer there.
  • The customers in the old version are legacy customers who aren’t considered “ideal customers” for the business. Their lack of commitment to upgrade to the new version is just one more sign they’re not extracting enough value from the relationship to remain customers in the long run.
  • The current focus of the business is to increase satisfaction and retention rates among its  group of “ideal customers”, who are already in the new version and happy with the performance of the Orders Placed page.
  • The chief complaint within the “ideal customers” group is not that the Orders Placed is too slow, but rather that the information offered about the estimated delivery time is often wrong.

Armed with all this information, Jane can go back to Tom with a better diagnosis of the problem.

Jane, the high-performing BA: “Tom. looks like making the Orders Placed page run faster is not going to help you achieve your business objectives. Here’s what I learned [ summarizes the key points from her investigation ], and here’s how I recommend we proceed…”.

Jane can now work with Tom on a plan to increase the accuracy of the estimated delivery time. Any changes that are required in the system to achieve this objective (e.g., querying the shipping carriers more often, refreshing the EDT more often) can be tackled by the developers who would otherwise be busy making the page load faster with little to no impact to the desired business outcomes.

# # #

When a BA is doing only reactive work, he or she is more likely to have people questioning the need for the role. After all, why can’t Tom the business stakeholder go directly talk to Jeff the developer about “making the Orders Placed page faster”?

The more proactive your work becomes, the less risk you face of your job being considered superfluous. A business analyst can deliver incredible value to an organization by going beyond understanding and translating the wants and desires of the business stakeholders to technical stakeholders. High-performing BAs also avoid the risk unnecessary scope creep that reactive BAs constantly face. You’ll know you’ve become a high-performing BA when you’re helping the business answer two fundamental questions before getting into “solution mode”:

  • What is the real problem to be solved here?
  • Is this problem even worth solving?


# # #

Interested in getting better at problem definition?

Register to our free email course “Understanding the problem: A key step to being a successful problem-solver” using this form.

It’s time for business analysts to add machine learning to their “bag of tricks”


Are you tired of hearing about machine learning and “the artificial intelligence revolution”? Or perhaps just dismissive of the topic, thinking it’s not relevant outside of the realm of Amazon and Google or a team of data scientists working for a Fortune 500 company? Well, it’s time to change your mindset and recognize that machine learning is another powerful tool that business analysts can add to their “bag of tricks” as they look for new ways to deliver value to their organization.

With the proliferation of open source tools, as well commercially available applications that hide most of the complexity of building a prediction model, it’s getting easier and easier to use machine learning to help solve all sorts of business problems. The applications are endless. To preserve the confidentiality of proprietary information, I can’t use any real-life example from my consulting practice. Instead, I’ll illustrate the possibilities using a simulated project based on a real dataset released as a companion for the paper Explaining the Product Range Effect in Purchase Data by Pennacchioli, D., Coscia, M., Rinzivillo, S., Pedreschi, D. and Giannotti, F., . In BigData, 2013. (If you’d like to play with the same data, you can find it here.)

The dataset contains purchase data aggregated by customer from January 2007 to December 2011 for five supermarkets owned by Coop, one of the largest Italian retail distribution company. It includes variables such as the distance between the customer’s house and the closest and farthest store locations (which may carry different items), the average unit prices of the products purchased by the customer, the total amount of items purchased, and the price paid for each purchase during the time span covered.

Simulated Case Study

A multi-unit enterprise is interested in expanding its line of products to attract more “high value customers” in a specific geographic area where there it has five stores. The company uses a loyalty card to track the patterns of consumption of each registered customer and classify as “high value” the ones who spend $5,000 or more per year across the five stores, assigning them a “VIP” status.

A business analyst on the IT team is assigned to write the requirements for a solution that will allow the company to create and execute a survey to collect the preferences from the “VIP” customers of the five stores. These preferences will inform the decision of which new items to carry in the stores to increase customer loyalty and share of wallet among those top customers. As the BA gathers information from the stakeholders and internal databases to inform the requirements for the project, she learns that the company has 60,365 registered customers with a label of “VIP” or “Regular” assigned to them. Out of these 60,365 labeled customers, 18,278 have “VIP” status. An additional set of 8,103 customers are still unlabeled, as their use of the loyalty card is more recent. This set includes both brand new customers and existing customers convinced by a recent marketing campaign to register to the loyalty program for which the company doesn’t have yet enough purchase history collected for label assignment based on the existing rule.

The BA decides to see if it’s possible to find any reliable patterns to identify “VIPs” among these 8,103 customers with a shorter purchase history in order to expand the number of people invited to take the customer survey, so more data is available to generate insights and the preferences of top customers just adhering to the loyalty program can be taken into account. After extracting the records of the 60,365 labeled customers from the loyalty system, she uses R Studio (an open source tool that makes it easier to use the open source statistical language R) to make sense of the data.

She does some variable selection and transformation, and splits the resulting dataset into two sets, one for “training” the model (42,255 records, 70% of the available data), and another for testing the model accuracy with “unseen data”(18,109 records). She then uses a supervised learning algorithm to analyze the training data and produce an inferred function that can be used for mapping new examples of “VIP” customers.

To find out if she trained a good model, the BA looks at statistics provided by R including Accuracy (90%) and Kappa (77%), and checks the model against the training and test datasets. The following table shows how well the model performed with new observations (the test set with labeled customers not used to train the model). The correct predictions are the ones in the diagonal line from top-left to bottom-right. Our test set has 12,619 “Regular” customers, with 11,729 (92%) being correctly labeled by the model. The test set also has 5,490 “VIP” customers, with 4,624 (84%) classified as such. The error (misclassification rate) is 9.7%, consistent with the performance achieved by the model with the training data.

Additional steps could have been taken to improve the model: test a different algorithm (extremely easy to do using the R package caret), find a better combination of predictors to feed into the model, and so forth. But since the business is not dealing with a problem in which false positives or false negatives would cause any harm, the BA decides that the model is good enough for the intended purpose. She can now apply the model to predict the status of customers in the unlabeled set using predictors like average purchase cost, and flag the ones assigned the “VIP” class to participate on the survey.

The figure below shows a partial depiction of the resulting decision tree used to classify customers as “Regular” or “VIP”. The number within parentheses in the end nodes represent # of observations / # of observations in the wrong class in the training set of 42,255 observations. For example, the end node with a red border at the center of the diagram has 7,590 customers assigned to the class “VIP”,  with 546 of those incorrectly assigned to that class.

Note how not all predictors of “VIP” (high spending) status are obvious. Even though we’d expect customers with a lower average purchase (less than $7.91, top left node of the tree)  to be “Regular” (lower spending), some of the behavior of “Regular” customers is far from intuitive. For example, one might expect that customers with an average purchase greater than $7.91 and average product price above $ 7.13 would be higher spenders (“VIP” class), but in the training set, 1,204 of those are “Regular” customers, and only 33 are “VIP” (see far left end node with red border). In the full dataset of labeled customers, 89% of customers with this profile are “Regular” (i.e., spend less than $5,000 in the stores per year).

It’s also interesting to see that “maximum distance to a store” is a more important predictor than “minimum distance to a store” (metrics provided by R show that on a scale of zero to 100, “maximum distance of a mile or less” has importance 98.11, and “minimum distance of a mile or less” has 84.15). Discoveries like this would be hard to identify without the help of machine learning, and can raise issues more important than the business originally meant to address.

As a result of this quick exercise, based on the attributes that the model found to have the strongest predictive power (average purchase amount, average product price, and maximum distance from the customer’s home to one of the five stores), the company is now capable of flagging more potentially “high-value” customers to invite to respond the survey.

Instead of merely writing the requirements for a solution that would enable the company to survey customers already flagged as “VIP”, the BA contributed with additional value to the project by allowing the survey to be extended to more customers who, based on the identified predictors, are likely to be in the same “high value” category as the “VIP” customers that the company wants to hear from. The survey results from the two groups of customers (“true VIPs”, and “predicted VIPs”) could be kept separate and compared to check if they seem consistent before being consolidated to inform the company’s decision-making process.

If the model helps the business achieve its objectives,  it can continue to “learn” as more customer data becomes available, with benefits in terms of accuracy and identification of new customer behavior that may start to develop over time.

# # #

As seen in the case study above, machine learning can exploit fundamental correlations between a variable of interest at a certain future time and other correlated metrics at a current or historical time, and predict the future state of the variable with some accuracy. There are myriad situations when predictive analytics can help business analysts solve business problems or improve the quality of their solution. From analyzing data from a CRM system to understand the drivers of customer churn to using web crawling data to predict which mobile device doctors would feel more comfortable using before making a large purchase decision, the applications are endless. And with the proliferation of free learning resources and open source applications, there is no excuse for ignoring these powerful tools and techniques that can dramatically improve the impact of business analysis in your organization.

 # # #

Ready to jump into the predictive analytics bandwagon?

Here are some good resources to help you get started:

How to Run Your First Classifier in Weka

Practical Data Science with R

Need help getting your team ready to use predictive analytics methods that are appropriate to your issues without feeling intimidated or producing misleading insights that don’t add value?

Get in touch and we’ll be happy to help you accelerate your journey to becoming a data-driven or data-inspired organization.

* * *

 Photo credit: O’Reilly Conferences (Creative Commons)

A BA asks: when replacing a system, how much do you need to care about the as-is state?

A BA asks:

During IT project implementations, how easy is it to determine the level of the (AS-IS ) detail required? Do you prefer the solution (TO-BE ) be informed by the AS-IS or rather should it be independent of the current set up? As IT professional do you think we dwell too much on the past and fail to solve the issue or we fix our own problems leaving the real pains (challenges) experienced by business?

There are two aspects of developing a superior solution that need to be taken into account here:

  1. The need to investigate the real problem to be solved, rather than focusing on the solution that exists today and reproducing it in the new set up at the risk of replicating inefficiencies from the past.
  2. The need to understand what exists today and why it was built in a certain way so that you don’t end up removing from the new solution critical pieces that turn out to be required to fully solve the business problem.

Imagine that you’re working on the requirements to replace a system used for routing support requests to the appropriate support staff members. In the legacy application, you have a screen where a manager looks at the list of new tickets and decide who to assign the work to based on the level of complexity and other attributes.

In the new system, the assignment of tickets may very well be automatized using business rules or even machine learning. In that case, the as-is process of displaying a list of tickets pending assignment would be replaced by an automated process. Still, it’s important to interview the managers making the manual assignment about their as-is process (e.g., to understand the considerations they make to select the right support person to work on a ticket so that this knowledge can be used to specify the optimal automated solution in the new system). Likewise, the managers should be interviewed about the to-be process (e.g., to understand the concerns they may have with the automatic assignment and elicit information that may lead to new requirements such as the need to allow a manager to override the system assignment based on human judgment or knowledge the system doesn’t have, like when an employee calls to say he’s taking a sick day and his tickets need to be reassigned).

So the answer to this question is, when replacing a legacy system, you should make sure you understand 1) how things work today; 2) why they work a certain way (which could be “no good reason, we’ve always done things like way” or “there is this very important reason why we use a three-digit code to identify the urgency of a ticket even though two digits would suffice). This is how you equip yourself with the knowledge to determine which portions of the as-is process can be eliminated or improved, and which ones needs to stay to ensure the business needs are properly met.

Sure, there are things in the as-is process that you may not need to investigate too deeply (for example, the exact screen of the system used to input each type of information). But anything related to the steps involved in the process, how often certain functions of the system are used, the alternative paths used in the process, need to be understood in a decent level of detail in order to mitigate the risk of missing critical requirements that if ignored would cause the to-be system to fail to meet the business needs.

Photo credit: JoniVan Bogaert

How to make sure you’re dealing with the real problem and not just a problem manifestation

In his article Outside-In User Story Example, my favorite product management expert, Scott Sehlhorst, describes how users “almost always fixate on problem manifestations, versus underlying problems”:


Problem manifestation Problem
My contact list is missing this person I need to know the identity of this person
My phone does not ring loudly enough I am not noticing incoming phone calls
I need a faster horse I need to get to my destination faster

To explain what it means to switch a product team’s role from “do these things” to “solve these problems”, Scott uses a personal experience of being a part of a messaging conversation on his phone with three other people (a group MMS) and seeing two names and one phone number because one of the participants was not on his Contact List.

A reader asked in the comment section:

Do you have any personal criteria that help you determine whether you are working with a design or intent? The example of “faster horse” vs “get somewhere faster” is good but I am not sure the difference is always going to be that visible. Do you have any personal recommendations on how to determine whether you are dealing with a design?

I’m sure Scott and other successful innovators have powerful approaches to deal with this issue. Here I’m going to share mine.

The secret to going from a “problem manifestation” to the real problem to be solved is to have a process that supports these key principles (the actual steps may vary from company to company, product to product, and team to team):

  • All product and feature ideas are based on customer insights, and address an important need they have.
  • Customer insights are gained not only from interviewing customers, but also observing end-users in action. (If you just listen to what people tell you, you’ll miss important insights.)
  • Feedback from customers is sought all along the way: when you have the idea, a concept, a low-fidelity wireframe, the high-fidelity wireframe, after launch.

To give an example of how this works in practice, I’ll reuse Scott’s example of group text messaging.

Imagine that the experience Scott describes happened to a customer of your messaging app, and this person submitted a request for an enhancement to be able to add people in a group conversation to their contact list. How do you know they’re focusing on a problem manifestation and not the real problem?

1) Have “problem interviews” with your customers

Instead of taking the request at face value, first you’d ask the user to explain the context in which they realized they needed this feature. They may say something like, “well, from time to time I find myself in a text conversation with a group of people, and instead of seeing all their names, some people are displayed as phone numbers, which makes it difficult to know who is participating on the exchange. That’s why I wish I could add these people to my Contact List and start seeing their names instead of numbers.”

You could then reply, “Oh, I see. It looks like your end goal is to have the names of all participants of an group conversation listed on the screen as the exchange happens, so you know who is participating on it–is that right?”

(Customer) “Yes, that’s it!”

(You) “OK. Let’s say the app automatically identified the person for you, and displayed their name instead of their phone number, even if they aren’t on your contact list. Would that solve your problem?”

(Customer) “Yes, as a matter of fact, it would.”

(You) “Got it. And let’s say this person’s name was displayed every time they are part of a group conversation with you, despite the fact they’re not on your Contact List. Would you still want them added there?”

(Customer) “Well, not automatically. If I have the intention of contacting the person directly in the future, then yes. But it’s possible that the person is someone I don’t have a relationship with, and adding them to my Contact List would just clutter it.”

(You) “I see… It sounds like it would be useful for you to, besides seeing the name of everybody who is in the group conversation, know when someone in that conversation is not on your Contact List, and then decide whether to add the person to the list or not. Is that true?”.

(Customer) “Yes! Once the conversation is over, the app could ask me whether I want to add the person to my Contact List, and only do so if I confirm I want it done.”

Note how at the end of this conversation the user is back to thinking in terms of a solution (“the app can ask me if I want to add the person to my Contact List”). Accept the reality that it’s human nature to focus on problem manifestations and candidate solutions, and that it’s your job to redirect the conversation back to the underlying intent.

Even if the customer suggestion ended up being ideal, they’re not going to be thinking of all details, so we’re not trying to design the final solution at this point. It’s quite possible that the same customer who suggested the solution above would become annoyed if the app started asking each time they were on a group conversation with the same person, “Roy Miller is not on your Contact List. Would you Like him to be Added?” without an option to say “No (and don’t ask me again)”.

Every time the customer attempts to describe a solution (“I want to add people from a group conversation to my Contact List”, or “I want to be asked at the end of an group conversation whether I want to add to my Contact List the participants who aren’t there yet”),  you can steer them back to a conversation about their desired outcomes (e.g., know who is in a group conversation, selectively add people on a group conversation to my Contact List when I want to be able to reach out to them), as opposed to how (and when) these outcomes would be achieved.

2) Observe end-users in action

Talking to customers is not enough. It’s also critical to observe the end-user doing the tasks that your product is going to support. If you just listen to what the people tell you, you’ll miss important insights.

In our example, you could observe someone having an group conversation that includes people that aren’t in their Contact List and therefore have their number displayed instead of a name, to see how the interaction happens.

3) Check-in with customer in all stages from problem definition to solution implementation

Drawing a parallel with past real-life projects, first I’d have checked back to customer to see if they agree that these are the two problems they are trying to solve:

  • Know the identity of the people in my group conversation. As a participant in a group conversation, I want to see the names of all identifiable people who are part of the conversation, even when they’re not part of my Contact List.
  • Selectively add people from the conversation to my Contact List. As a participant in a group conversation with people who are not in my Contact List, I want to be given the option to selectively add them to my contact list.

After validating that I had identified the correct problems to solve, and determined that these problems represent high-value market opportunities to pursue, I would develop a concept for how to solve these problems, and check back with the customer to validate that concept. Then I’d check in again when there was a low-fidelity wireframe to show, a high-fidelity wireframe, and after launch.

Throughout the process, we’d be looking at candidate solutions. For the second user story, is it better to update the Contact List and later ask the customer if he wants to keep or discard the new contact? Highlight the names at the end of the conversation and ask whether to add them as a contact? Create a workflow where the users can press names to add them to the Contact List during the conversation? These decisions should be made ahead of implementation as part of the user experience design, taking into account usability, value, feasibility, and costs.

Do you have a different approach to go from “problem manifestation” to “problem” before working on a solution?

If so, share your thoughts (or link to a blog post that fits this topic) in the comments section, so more people can learn from your successes.


Photo credit: Chris Devers (Creative Commons)