As any person involved within a new application implementation or configuration will testify – the most important indicator of success is when the primary design objective of creating a solution that the end user actually wants, needs, and uses is met. Too often, software is developed and implemented without significant or intelligent design thought, or professional user discovery being undertaken. The result of this is poor user buy-in, under utilised functionality, and users who have no emotive connection with the applications that are expected to improve their working practices. Yet designers continue to ignore researching user’s goals, and often simply ignore users.
Goal directed design is a technique developed by Alan Cooper (author of The Inmates Are Running the Asylum). Cooper argues that talented people continuously design bad software. Moreover, Cooper argues that, despite appearances, business executives are simply not the ones in control of the high-tech industry. They have inadvertently put programmers and engineers in charge, leading to products and processes that waste huge amounts of money and erode competitive advantage. They have let the inmates run the asylum.
The goal directed design methodology differs from traditional software design. Although both methodologies undoubtedly start with a “business” problem or objective, the approach of the traditional design methodologies has been to capture user requirements, whereas goal directed design develops actual descriptions of users and what that specific user is aiming to accomplish.
Traditional design methodologies typically have a heavy emphasis on technical features and functionality requirements that are used within the design effort as a problem solving device – matching features with the user population. In contrast, goal directed design uses an individual user’s goals in order to discover features that may in turn become relevant to a wider audience.
In essence, the tipping point between the two design methodologies is that goal directed design focuses on what the user is trying to achieve. The following further outlines the primary aspects of the design methodology.
Identify Business Problem
In order to begin the design process, there must be both a clear statement and understanding of the business problem that has dictated the commissioning of the system, in addition to a clear statement and understanding of what the solution is trying to achieve.
Once this has been achieved, the identification of target user roles within the context of the business problem is undertaken to determine whom it is who will ultimately be interacting with the design solution in question.
Research
Research is primarily facilitated via user interviews. The objective of this research is to understand the working habits and goals for each “user type” identified. To achieve this, a number of research techniques (which are often foreign to the technical personnel typically tasked with such discovery tasks) are required to be mastered by the interviewers.
Many firms who have undertaken a design effort with the best intentions of satisfying user goals fail because the personnel tasked with the discovery effort is typically sourced from within the technology-centric project team. They typically fall into the more traditional and comfortable “functionality requirements specification” discovery mode.
The key to success in uncovering goals during user interviews is to ensure that both non-directive and probing questions are the core of the interview script. These techniques allow the interviewee to express independent attitudes and perceptions outside of the realm and ring-fence of software functionality. They also allow the developers to approach the design of the software question in a way in which the final outcome can be directly matched to, and measured against, the user’s stated goals.
An additional tip when conducting discovery is to undertake user interviews in the user’s own working environment. This allows the interviewer to observe the “natural habitat” of the user, and to build up a more accurate persona in the following design steps.
Regardless of the design in question, the interviewer should be taking in these surroundings and noting how the user interacts with this environment. For example, “Does the user have a manual business card rolodex on their desk that they use as opposed to an electronic one?”, and “Are there rough notes stuck to the desk to remind the user of a task for today?”, are both typical types of observation points of note that can valuably feed into the development of personas.
In addition, interviewing in the working environment allows the interviewer to ask the user to demonstrate how they currently may undertake a task first hand – a process which cannot be replicated in any other interview environment as it may entail more than just interaction with the user’s desktop.
It is important to note that user interviews can also be complimented by secondary research tasks such as detailed reviews of legacy systems, an understanding of the business objectives for the firm, and additional participatory techniques such as group shared design sessions.
Prepare user profiles
At the conclusion of the user research, the development of user profiles can begin. A typical user profile will be representative of a sub-set of users within the firm, and will contain detailed and specific information in relation to the work activities and goals that these resources face on a daily basis.
User profiles represent hypothetical users within the firm, and are used to define both the scope and nature of the design problem. The profiles are also used to determine what the software in question should do and how it should behave.
Although these profiles represent hypothetical users (for a simplistic example – a first year associate within the corporate tax department), they must be based on facts discovered within the discovery process in order to maintain the overall objective of goal-orientated design, and also in order to maintain their credibility when taken to the wider user population for validation or fed into the software development life-cycle.
In addition to the above, one of the single most important aspects of the user profile development is to ensure their focus is on user goals, not feature requirements.
Prepare scenarios and mock-ups
In addition to the development of user profiles, scenarios are also utilised as key tools for incorporating tasks into the design. A scenario is a description of an activity that takes place while someone is engaged with a task to meet his or her goal. It contains the prerequisites of the activity, the profiles of those users involved, the specific activity itself, and the end results of the activity.
By working through each scenario, a sitemap or product functionality workflow becomes apparent, which in turn enables the designers to begin constructing low-fidelity mockups showing the information and placeholders that form the basis for visual design and functionality. These mockups can be expanded further and used to envision additional scenarios. The objective behind their use is to allow designers to visualise how the user would interact with the features of the product based on their user profile details.
By asking how your hypothetical user would use (and have their goals met by) a feature and why they would do it in a particular way, you begin to construct a more comprehensive scenario that is directly tied into your goal orientated design process.
It is these scenarios that allow tasks, behaviour patterns, and goals to give shape to high level features and the structure of the final design solution. In essence, the scenarios (once validated) form the basis of user requirements. It is at this point where the technical development of the final solution can begin; if the goal orientated design process was executed effectively, this final design solution will have a greater chance of user buy-in and overall success than other products or solutions that have been designed using the more generic “technical, functionality-lead” processes.
Generic Project Management Touch-Points
When expanding the view of a design effort in order to consider the project management aspects of the undertaking, there are a number of key touch-points that should be consistently in the forefront of one’s mind. These include the following:
· deliver visible benefit and value to the users early – get key features and/or functionality out in a short time frame (90 days)
· deliver continued benefit and value functionality or design aspects in rolling phases
· obtain appropriate sponsorship and buy-in from persons who in turn communicate a clear statement of objectives
· ensure both business analysis and technical personnel are jointly involved.
In essence, these should not be limited to a goal directed design strategy, and could be considered valid regardless of the strategy used.
Conclusion
It is important to remember that the objectives of goal directed design are not complex, nor are they difficult to conceptualise. Goal directed design is simply a methodology that diverts the core focus of the design effort away from the technical features of a product, and more towards the user’s individual interaction and experiences in the hope of aligning the product’s final development with achieving the user’s stated goals – the same users who (through their actions and opinions) will ultimately decide if the product is a success or failure.
