What is your technology 'BASED' on?
The Performance Technologies Group
Category: current-papers | Author: James Breeze and Craig Errey | Date: 26/07/2006
What is your technology 'BASED' on?
In building your last business application did you get requirements from users or test the application with them? Even if you did, you may still have had trouble making the technology work the way they needed it to. This is because engaging users is only half the equation. The technology must be built so that it is entirely 'people-based' not 'data-based'.
Lost in data
Many business applications end up being so confusing and complex that they simply reduce people's jobs to data entry. What do we mean by this? Essentially, instead of having the application directly reflecting people's jobs and workflow, it comprises endless screens and forms for people to enter data. People need to learn the right sequences of screens to fill in, how to fill in various fields correctly, and various buttons to press. If you tried to map the business process to the screen, you'd find little or no relationship between the two.
These systems are meant to improve quality, productivity and staff satisfaction. But because they don't reflect people's knowledge and experience in their work, staff have to rote learn a new set of procedures that don't align with their existing knowledge. This means they take much longer to complete transactions, make many mistakes and may not even use the business application at all, preferring to use spreadsheets that they can design that more closely reflect what they actually need to do.
'Data based' applications
Of course, we all know that just about all software systems sit on a database, as you have to store the information (data) somewhere. Software engineering has evolved with a strong data / information focus.
General business and systems analysts codify work processes in terms of data flow (i.e. use cases), not human information processing and decision making. Programmers then assemble the databases first and build the application and its user interface around them. It's a bit like starting a new building by putting the plumbing and electrical in first and then trying to wrap a building around it.
This means that the interface often looks like a mass of database tables and provide poor flexibility when the business wants to tweak the way the system works to drive better work practices.
Out of the box solutions can cause all sorts of problems when it costs too much to modify their interfaces to make it resemble what's actually going on in the business. This occurs because the database tables are predefined and the user interface is often so tightly embedded in the fundamental design that even simple user interface changes require entire database rewrites.
If the basis of all systems is data, instead of people, then what hope have we got for making business systems easy for people to use? It's a fundamentally flawed approach to application design.
'People based' applications
It's an easy trap to fall into designing a new application from the data up. The data is the thing we can most easily document and understand. We can exactly work out what transformation needs to happen to the data, and we can precisely specify the application communication with use cases. It's no wonder that it is the first place to start.
On the other hand, understanding people can be complicated? Or is that really true? Let's think about the problem for a moment. What are we really trying to do to make applications easy to use?
If you ask a psychologist or instructional designer how to make something easy to use, then they'll generally come back with an answer something like 'make it similar to something they already know - use their existing knowledge'.
When we make software 'intuitive', what we really mean is that it is 'familiar'. There's nothing mystical about how to design something that's intuitive.
So let's come back to the problem we are trying to solve — making it easy. The context is the business. Business is made up of business processes and people whose job it is to deliver those processes. If we want to make software easy to use in a business context, then we need to start with people's jobs.
It's fair to say that people do know their jobs and often know them very well. Therefore, the first place we start is to collect the job descriptions of the people who will be using the application. The job descriptions generally contain the Key Result Areas (broad groups of activity, the specific activities within those KRAs and the Key Performance Indicators that let you measure how well the activity and job is being performed).
In that document, you have the basis for designing 'people based' software.When the application follows the job description (assuming that the job description does reflect how things should be done), then if people know their job, then they will know how to use the application.
Sounds too simple, doesn't it? There has to be more to it than this? In fact, this is one of the core components of our XPDesign methodology. The job description contains the sequence of activities, the information required, the decisions to be made and the measurement framework.
However, the job description is not something that developers are used to working with, or know how to construct - it's a special skill that HR people and industrial psychologists have.
To present the requirements in a way that IT understands, we have taken a well known IT approach, object oriented design and development, and made it 'people based' by taking an object oriented approach to requirements and user interface design. Instead of workflows being about data they are about exactly what decisions a person needs to make to achieve their job goals. It's simply a higher level of analysis and design, starting with the real-world aspects first, then going to the data, rather than starting from the data up.
If your application is designed around how a person thinks and works then it will provide greater flexibility and reuse, and be far more intuitive to use. Business systems should be developed from a PEOPLE BASE, not from a DATA BASE.
