You are here: Home
Let’s design products, processes and systems that can survive the Innovation Age
An organisation and its customers is by definition human-centric, it is sustained by people in communication. Despite this, organisational design of digital products, processes and systems rarely take on a humanistic perspective. They usually seek a final fixed structure rather than bending to the needs of the individual user and yielding to their changing needs over time.
One reason is that business owners find it extremely difficult to commit to ‘living’ products, processes & systems that flex and change according to the shifting demands of the people that use them. Another is that analysts often seek to address an immediate opportunity or problem against which they’ve been tasked to deliver, rather than thinking more widely and advising business owners strategically.
The reality is that a finite definition, fixed structure, for a product, organisational process, or system can never remain valid over extended time. It will become redundant, inefficient, and lose market share. This redundancy cycle is becoming faster and faster in the current Innovation Age. So to continue designing digital products, organisational processes and systems based on a final structure is in itself to implement built-in rapid redundancy.
Redundancy may have some value in commercial product design but most business owners should be concerned if they realised their products, organisational processes and systems are being designed with redundancy that makes them liabilities faster than ever before.
If you wish to understand more about how to design ‘living’ products, organisational processes and systems for your organisation, then please contact me.
ben@cautionyourblast.com
Ben Stewart
Establishing and nurturing interactive development as a field of digital expertise in your organisation will place you at the forefront of contemporary communication.
Interactivity remains a very important aspect of the digital world we’re building. Important not because it is new, or unusual, but because it is fundamental. Digital software technology always surfaces at some point for human interaction, this is why at a fundamental level, Digital = Interactive.
Interactivity drives all digital communication affecting user adoption, the way we use it, our understanding, awareness, emotional engagement, and of course learning. This is why it is an important consideration in software product design and of course any organisation seeking to communicate in our digital world.
A new generation digital organisation must stay up to date and knowledgeable about delivering interactivity as this is a communication veil through which people will view you. It requires investment in both interactive talent and an environment into which they can excel.
Key to success is talent and expertise in creative (digital) interactive development. This area of skill is often misunderstood and I often use a zen approach (describing what something is not) to help contrast the key differences.
Interactive development is not:
- not simply content production, but content production through code development.
- not simply user experience, but user experience driven by programmatic interaction behaviours.
- not simply information architecture, but information architecture based on multi-dimensional datasets.
- not simply about multimedia content, but where multimedia is just one facet of a wider experience.
- not simply graphic design, but graphic design driven by programmatic rules.
- not simply about telling a story but about how that story is discovered and realised by the target user.
And more importantly if your business is communication then establishing and nurturing creative interactive development as a field of expertise in your organisation is now fundamental to your business and essential to keep you at the forefront of contemporary communication.
If you would like more information on building digital interactive specialism in your organisation please contact me: ben@cautionyourblast.com
Ben Stewart
Usability, Freedom & Ubiquity
Mention User Experience (UX) and more than likely thoughts go to interaction design, narrative value, accessibility, vocabulary and information architecture. These are aspects I generally think of as contributing to the overall usability of a product, and they form one of the essential keys needed for successful user adoption of a new product.
But Usability is just one aspect of user experience that affects product adoption. When making investment decisions during product planning you need to be appraised of two other aspects of experience that affect product adoption: Freedom and Ubiquity.
By Freedom I mean the freedom to adopt due to the absence of rules and conditions under which the product can be used. For example the need to register, to authenticate, to purchase at a cost, to use a real name, to have a prior email address, to learn a new process, learn a new language, to own a computer, etc., these are all potential barriers to entry impacting the freedom to uptake a product.
By Ubiquity I mean the wider use, popularity and adoption within a community or a marketplace, conformance to product standards, file formats, communication protocols, language and vocabulary, software platforms, devices, etc. With ubiquity comes a higher preference of choice, less scepticism, less opposition and increased consumer pressure to buy into a product.
Good product planning requires product and marketplace knowledge on all three of these aspects in order to balance investment and maximise the user adoption experience (UAX) for a product.
The following example graphs the image of an unbalanced user adoption experience. It shows a high level of usability, some constraints impacting freedom, but very low ubiquity.
Where this helps in product planning is I know that there is no point in further investment in the usability of the product while the ubiquity of the product is so low. Also improving freedom is likely to be a poor investment until the overall picture is more balanced.
User stories can be categorised with UAX points (Usability: 2, Freedom: 0, Ubiquity: 5) helping to drive sprint prioritisation. But improving Ubiquity often also requires investment in marketing, it’s not simply all about more development.
Used from the beginning of a product lifecycle this UAX balancing act will achieve the best adoption results for the investment made.
If you would like more information on digital product adoption and innovation please contact me: ben@cautionyourblast.com
Ben Stewart
Business processes are not the best way of thinking about, describing or designing core business functions for me, but activities are. I accept there is wide scale promotion and adoption of business process management and hence often work within it’s limitations but it’s not always capable of helping me to fully understand, innovate and manage a business. This blog starts to unravel why.
The word “process” implies a series or sequence of events and more specifically implies that rules exist to control the flow. Wikipedia says it well: “A process describes the act of taking something through an established and usually routine set of procedures or steps to convert it from one form to another”.
Initially because of it’s definition and implications I never solely relied on business process analysis and management to measure and design for business. I needed to also look beyond those constraints, to the area of human activity management. As a result while I’ve learnt business process analysis, modelling and management techniques, I’ve been aware of their limitations. For around the last twelve years I’ve always used activity analysis and management which happily address the failures of a process approach for me.
Core Business Function → Key Tasks
A core business function, e.g. Sales, can be described with key tasks each of which has goal related outcomes. These tasks may or may not be sequentially related. And if they are related then sequence is not the only type of relationship that may be necessary. In addition to being related sequentially, key tasks can be related through being conjoined, parallel, iterative, mutually exclusive, shared, simultaneous, and synchronous. They can also be unrelated and omnipresent. Not every task that is required is series related, nor can it be described correctly as a process.
I assign a key task wherever there is an exchange of value between the business and other parties. These value exchanges are the fundamental building blocks required to model an existing or new business.
Key Task → User Activities
Every key task can be analysed, designed, funded, implemented, monitored, measured, changed, replaced and retired, by understanding the user activities that are required to deliver it’s outcomes. In each of it’s inherent activities lies the fundamental success or failure of the key task and of the wider business.
User activities will often be related with rules (as can key tasks). And there will sometimes be rules enforcing sequence, i.e. a process, but I find it’s never to the degree that it fully describes the fundamentals required to design and deliver a key task successfully. The process approach forces all activities to be sequentially related as that is the defining characteristic of a process. But of course this is not the way people work (and increasingly it’s not the way that computers work). It is not useful to define a way of working as a process if it’s not carried out that way. Instead by defining work the way it is observed and carried out i.e. as a number of sometimes unrelated multi-tasking user activities, we also expose natural relationships, inherent rules, and allow for evolution of new activities and relationships.
To get this complete picture of what is happening in an existing business, or for a new business design, we need to go beyond process analysis and adopt an activity viewpoint.
I always refer to activities formally as “User Activities” as a reminder that even when an activity appears to be fully automated there is always human involvement of some kind. This could be simply at the level of managing, auditing, monitoring, or exception handling. An activity describes an undertaking of some kind as one part in achieving a task outcome so by definition it requires a human touch point of some kind. An activity will always belong to somebody.
People & Machines
Activities imply people, processes imply machines (that includes computers). Machine-like mechanisation requires analysis of sequentially dependent events and the rules for controlling the flow i.e. a process. Not surprisingly where business process analysis (BPA) and business process management (BPM) really excel is for replication and automation.
Human behaviour and work on the other hand regularly demand wider consideration. In successful human activity there is more than rules (for process or otherwise), there is experience, psychology, environment, tools, image, understanding, role, division of labour, status, reward, language, context, and more. All these are present in each of the user activities that are required to successfully deliver a key task. And as I mentioned before, an activity always belongs to someone, this is why business process analysis and business process management miss many of the key issues impacting the success of core business functions today.
If you would like more information on how business activity management works in practise please contact me: ben@cautionyourblast.com
Ben Stewart
Wawa (London), always has a range of sales and production activities for their sofas and chairs in progress, as these are the core designer-maker products behind their business.
When things get busy it’s often difficult to know what to prioritise and who should do what to keep this stream of work flowing smoothly. It’s not unlike the challenges in digital product development so we recently leant a hand for a day to smooth the operation by drawing on our experiences in digital.
It’s been fun and very informative doing non-digital for a day! In a nutshell we’ve taken existing ideas from enterprise resource planning (ERP), digital product management, and software development to manage this process in a style that suits Wawa.
And best of all we can start employing these big ideas in a small way, by simply using a whiteboard!
How it works
The first idea is to use Lean principles. These originate from the manufacturing industry and focus on the smooth flow of work, constraining the quantity of work in progress, and eliminating wasteful practises. One of the main tools we can utilise from Lean is the idea of the Kanban practise which literally means scheduling what to produce, when, and how much. Another is the practise of ‘pulling’ an item of work once its ready into the next step in the process.
Our whiteboard supports these by displaying a framework of the main tasks from left to right through the sales and production cycle. We then identify the work by using post-it notes for each item.
This is a mockup we made in Omnigraffle to check out how it might work…
The second idea is to use Agile practises. These originate from the software development industry and focus on the continuous inclusion of key people, collaboration and iterative time-boxed cycles of work.
Agile practises help us to manage the whiteboard. Firstly using the idea of a stand-up meeting where everyone gets together for ten minutes each morning to discuss the status of work on the whiteboard and update it by agreeing to pull work items into the next activity.
Another aspect we borrow from agile is time-boxed iterations where each task is given a duration of time for delivery. For our purposes we will start by keeping this simple using a task duration of 1 week elapsed for each task e.g. when an item goes into the Frame task we expect the sofa frame to be built and ready in the complete column one week later. This cycle frequency of one week can be controlled by limiting how many items are allowed in a task at any one time, another key Lean principle.
Here’s Richard checking out the new sales and production whiteboard for useful information while talking to a customer, before we’d even finished migrating work in progress to the board !
Summary
We want to manage our sales and production activities for sofas and chairs with some sensible limits and better visibility on what’s going on. The whiteboard and the visible process framework set the basis for this and then the post-it notes quickly identify task item volumes and progress. We can write other controls directly on the board e.g. the limit of items allowed in any one task at a time, the name of the person owning a task item etc.
And finally because its on a whiteboard together we can easily keep improving the idea, and of course we’ll progressively begin to migrate elements of the process to Digital as and when there is justification !
If you’re interested in knowing more and think your business could benefit from sharing in these ideas please email me at: ben@cautionyourblast.com
Wawa sofas and chairs can be seen at: www.wawa.co.uk
22nd February Earthquake
By now you will no doubt be aware of the seriousness of the latest earthquake on Feb 22nd in New Zealand and the human tragedy that the people of Christchurch are experiencing.
Aftershocks are continuing to cause distress and hamper efforts in the many rescue and cleanup operations that are underway.
At the time of writing 28th Feb:
- 148 confirmed dead and still many unaccounted for.
- 50,000 properties remain without water – 33% of the city (out of a total of 150,000).
- estimated that 75,000 houses are without sewerage.
- approximately 37,000 customers are without power.
- early estimate of the damage caused by last week’s 6.3-magnitude quake was between $10 to $15 billion – two to three times the $5b estimated cost of September’s 7.1-magnitude quake and 7 to 8 per cent of the GDP, compared to Hurricane Katrina’s one per cent impact on the US economy.
Any donation you can manage will be enormously helpful in this crisis situation, the internet options are:
Part Three – Context Alignment
In an idealistic world all five of our key analysis contexts (see Part One in this series) would align such that they are all essentially the same thing, here’s a totally hypothetical example:
| Business Process |
provide transportation for city commuters |
| (Business) Task |
transport city commuters from their departure to destination points |
| (User) Activity |
I as a Commuter want to travel from A to B in the city |
| (User) Interaction |
self-service: I set my destination B on the city teleporter & press ‘GO’ |
| Operation |
when the commuter presses ‘GO’ then teleport them from A to B |
Of course this perfect alignment where each context is synonymous with the others is idealistic and it’s never the case in a real life. But it serves the purpose to demonstrate that a high degree of context synonymity equates to better alignment between the goals of the organisation and the efficiency in the delivery of these goals, it also implies a high degree of relevance from the business measurements and reporting.
The above simplification overlooks the fact that there can be anything from a handful to hundreds of separate Tasks in any one Business Process. Ideally we might wish to design fewer to lower the operational costs and ongoing management overheads. But it is also important to have multiple Tasks that can be reorganised rather than a single Task ‘black box’ that only does one thing. The right balance can be found by checking that there are enough component Tasks to support business adaptability and innovation.
I check suitability for adaptability and innovation by generating a number of future scenarios against which the flexibility/rigidity or otherwise of the process can be tested. This need for alignment carries on down the context tree and requires the same balance should exist when assigning Activities to Tasks.
This is harder to do and often organisations have excessive numbers of Activities supporting a single Task. A common example of where Activities proliferate is where a frontline call-centre team doing customer service is not trusted to do a process that involves an expensive computer application, maybe it’s one with a wide range of ‘power functions’, and as a result all customers get transferred to a ‘special team’ who are the trusted ones.
In this situation the use of specialist teams is a proliferation of Activities with no basis in flexibility or innovation, in fact it creates a much more rigid and fragile organisational design. It simply masks an IT failure to meet the business needs and is an example of the organisational design being dictated by the features of a computer system! I have seen many organisations that are designed this way and appear to be ignorant of the expense and wider issues. Such organisations have potential for massive improvements in their operations and business models.
If you’re wondering about how IT can address the problem above, it is to expose key functions from the said application in a front end (optimised for usability), even possibly integrated with other task functions, or into an existing application or intranet. You should be aware that this is not expensive or difficult for most applications – even now for windows thick client apps.
Just remember that all Activities should be driven by the goals not driven by the tools. And as we go further down the context tree the problems of alignment usually become more common. For example user Interactions across different software systems are sometimes treated as wholly separate activities where the user might work on one system for a period of time processing a batch of things and then go to another system to concentrate on something else. Whereas they would have liked to used the functions from across both applications in a continuous set of synchronous interactions to carry out their Activity.
In these context alignment checks I also look for alignment in goals. It’s commonplace to find that the goals of a business task are not the same as the goals of the corresponding user interaction. This is most often due to poor organisational management of goals, e.g. conflicting bonus structures: a customer service representative is rewarded on reaching a target of15 calls per hour but they can easily do this by having a number of very short customer calls so they drop calls or transfer them regularly; this is in contrast to the business goal of reducing repeat customer calls. These targets are mutually exclusive demonstrating a lack of alignment in organisational goals.
Obviously I’m scratching the surface with these examples but this post serves to highlight the need to review the alignment across these analysis contexts. This review will report on business and organisational issues, and underpin design for improvements. In some cases it will contribute to the business case for change.
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.
Over the last ten years I’ve had many colleagues and clients who have shown an interest in understanding more about how I carry out analysis of business opportunities and business problems. My approach has changed little over this time – if anything I’ve just honed the short-cuts rather than find any need to alter the core approach.
In this first post, and in the next couple, I’ll attempt to lift the lid and share the most important aspects of this work.
Part One – Terminology
If terminology doesn’t reflect the language already in use in organisations I think it should be avoided if possible. A shared understanding of the main words used in opportunity and problem analysis is important for discussing the findings, the issues and improvements. Occasionally I’ve had to interpret for consultants using arcane terms like “Process Levels 1,2,3,&4” where they are simply not understood by the customer, let alone the downstream delivery teams. They also force learning on key stakeholders who have better things to do with their time.
I use the following five simple terms which provide simple contexts for structuring my analysis and for modelling observations and data. I’ve used these successfully for many years. They’re easily understandable by organisational staff and management.
Note that I often drop the qualifying words in brackets when my audience demonstrates an understanding of the terms.
(Business) Process: this describes the workflows required for the handling and execution of a particular business event and the associated business goal. A business process can incorporate many people and can be asynchronous over a potentially extended period of time, (e.g. supermarket online shopping offers, purchase, through to fulfilment).
(Business) Task: a logical major step deliverable occurring in the context of an overall business process. A task can be delivered over an extended period of time in an asynchronous manner, by multiple people (e.g. collection and packaging of supermarket goods for delivery).
(User) Activity: a logical goal-driven function carried out by a single person (e.g. frontline customer service advisor: handle failed online customer payment). An activity can utilise multiple tools and take place in a non-synchronous way over a period of time. Note that a person will typically have many activities to carry out within any given role.
(User) Interaction: a synchronous unit of work carried out as part of a persons activity on a specific toolset e.g. using computer software, a mobile device, machinery, or manual work (e.g. record new credit card details via computer). This includes the detail of discrete person-tool actions that takes place in the course of an interaction (e.g. enter expiry date in the mandatory computer website form field with format mm/yy). For this reason interactions can utilise hierarchies of actions such that a core set of key interactions may hide the complexity of user actions for some levels of discussion whilst for other purposes the detailed actions can be discussed as necessary. Actions can be sequential, parallel, mandatory and arbitrary.
Operation: an event, or group of events, applicable only to mechanistic or computerised toolsets that have no person-facing interactions (e.g. create a new database record and queue for fulfilment: customer name, customer ref, date/time, shopping products ordered, delivery address, etc.).
These terms are agnostic to the methodology being used, whether it is six sigma or another approach. They also carry across into design to provide useful context e.g. when designing for an activity we are focussing on an individual user’s needs, rather than the business, or the technology.
In the next blog, Part Two – Quick Immersion, I’ll talk about how I handle complexity to get accurate insights into the opportunities and issues around the way an organisation is working.
Poor recognition of the important role that a Graphical User Interface (GUI) plays in modern software has undermined the take up of enterprise mashup technologies. The latest example I’ve seen is the systemic failure of corporate IT to include GUI design and development tasks in their plans for a new enterprise mashup.
Operational managers recognised that their existing desktop GUI was failing to deliver efficient process support. This forced users to navigate more than a dozen apps in one business process. An enterprise mashup project was identified and initiated to provide a new desktop solution. However no GUI design tasks and no tasks for building the HTML interface were planned. When the project started the developers had no understanding of what they were to build and the business had no way of visualising what the solution would be like to use, consequently four weeks into the project they were three weeks with 75% of the spent budget wasted.
This is not an isolated case. Over the last ten years of designing enterprise mashups I’ve consistently seen the following problems within corporate IT that have undermined the very idea of a mashup:
- internal corporate IT has no GUI design skills or practice methodology
- project design and development is outsourced to a IT system integrator that has no GUI design skills or practice methodology
- issued project plans have no tasks or skilled resources in the areas of GUI design
- end users are mistakenly thought to have the skills necessary to design their own GUI
- engineers with HTML/CSS build experience are mistakenly thought to have the skills necessary to design a quality GUI
- technical pre-sales employees from the mashup software provider are mistakenly thought to have the skills necessary to design a quality GUI
- little understanding of what a quality GUI actually is: one that supports the end users’ work patterns like a glove and is a joy to use
- no understanding of the enormity of the opportunity for the business by implementing high quality GUI
Almost everybody is now a power user of the web and this does mean they are more likely to notice issues of poor GUI. However this does not mean they have the credentials to solve these issues.
Now I believe that the answer lies in accepting that this situation is also a product opportunity. There is a need for GUI design guidance and structures to be built-in to enterprise mashup software platforms. Enterprise mashup software needs to transform itself from being an enemy of IT to being a valuable friend. This is possible by addressing the GUI skills gap through the bundling of native standards and strict guidelines.
This opportunity brief is being met by Apple who are demonstrating with iOS app development how to deal with this problem. Now the arrival of the Mac App Store might do the same for their laptops and desktops. Just maybe Apple will provide the next enterprise mashup platform, and resolve the important issue of the GUI?
Posted: November 8th, 2010 |
Author: Ben |
Filed: Consultancy, Experience |
No Comments »
