How I analyse for opportunities and problems
Part Two – Quick Immersion
In order to get into opportunities or problems quickly I spend most of my time reviewing user activities (see Part One to check out what I mean by user activities). By focussing on this context it provides me with quick immersion into the goals, ways of working and user mindsets of an organisation’s people regardless of the type of business.
An activity is often a litmus test indicator for business opportunities and problems. I find that above this level the information is too vague to provide certainty on what is actually happening. Activities carry relevant ‘real’ cost and embody how and why things get done. Importantly they reflect the presence of human intellectual property which is most often overlooked in business process analysis. Below the activity level there is too much information on existing tools and detailed working processes – ok for writing a training manual but a waste of time for a concise overview. If an activity is crying out for a better way of working then it’s likely that I’ll be able to extrapolate this up to the business process with a business case.
This focus on activities can easily be augmented with information about other context levels, particularly business tasks and user interactions. This approach helps to clarify relevance of activities, tasks and interactions in areas whereby the analyst is not an expert.
Note that activities have logical goal-driven outcomes. Both a user and their goal are essential definitions of an activity. I like using user stories to define and capture these e.g. “I as a commuter want to travel from point A to point B in the city”.
Once a user activity is defined it can then be fully understood and documented through its three determining aspects: Rules, Tools and Labour.
- Rules: industry regulations, internal process rules, good ways of working etc.
- Tools: devices (e.g. smart phones), manual tools, computer software, machinery etc.
- Labour: people, roles and responsibilities, etc.
Together these aspects provide quantifiable costs, effort requirements and compliance (risk) levels for an activity.
Here’s an example from an area everyone should be familiar with, that of online shopping, so you’ll get the idea quickly. The wider context for this example is being asked to review the e-Commerce aspects of a business.
Engaging with staff and users usually through workshops or one on one sessions we quickly come up with a snapshot of a key activities, just a few of which I’ll list here for this e-Commerce example:
- I as a customer want to browse products online
- I as a customer want to decide to purchase
- I as a customer want to checkout (pay)
- I as a customer want to track my order
These example activities all fall under a logical Task context of “Online Shopping” which is the overall context that the user is active in. As described in Part One an activity is a time specific event, but a user can repeat any one activity in their effort to complete their task e.g. browsing the website for products at separate times over many days.
Following feedback that an activity is difficult, or through statistical data indicating a problem, we may look further into more detail e.g. a large percentage of customers start but do not complete the checkout process.
Using this activity as an example, I as a customer want to checkout (pay), we can capture the rules, tools and labour aspects:
Rules: Consumer rights; Returns policy; Payment Industry Compliance and Payment Data Security; Customer Data Privacy
Tools: Public Website; Payment Gateway
Labour: Customers; Staff; Testers
And looking further, typically during a shadowing session with a user, we’d likely find the following user interactions are involved in achieving the goal of checking out:
- Review Order
- Enter Customer Data
- Enter Payment Data
- Submit Payment
- Retrieve Receipt
Note that I record these interactions with a verb-noun naming convention which describes the action (review, enter, submit, retrieve) and records the domain vocabulary (order, customer data, payment, receipt).
This level of interaction detail is required in designs that realise opportunities and deal with problems. Standardisation of the verbs will help in all aspects of development. And the business vocabulary must match that used in practise and be consistent throughout all subsequent change projects.
This level of detail is where issues are usually located with an activity, in this case it could be that there is only one type of payment option available which is not well matched to the customer’s needs or their financial profile. Addressing this by adding appropriate options would significantly increase conversion at the checkout.
In summary this approach allows me to achieve very quick immersion and obtain a thin slice across the potential opportunities or issues in any area where people are active. The practise methodology gives me ways to adapt my understanding to be specific to the area I’m working in such that I can understand the in-house experts and also be understood when communicating with them.
Leave a Reply