In software design, methods from NLP help capture what users really want: the Walt Disney strategy and the Dilts pyramid for the vision of the application, the VAKOG model and submodalities for UI and usability, perceptual positions and the mentor technique for the stakeholders’ point of view, and modeling and the TOTE model for the development process.
The Problem in Software Design
One reason software projects fail is the step from users’ wishes and ideas to the technical implementation. Requirements engineering tackles this by trying to turn users’ ideas into technical requirements for the application. These methods lean toward the technical side and, like UML, BPMN, etc., create a (semi-)formal specification from what users say. The methods presented here start one step earlier and go deeper: instead of only working with users’ statements, they help users actually recognize what they want. That makes it possible to go into depth where standard RE methods stay on the surface. The input gained this way can support the whole project, from planning the scope of functions to designing the interface.
Terms
- User: will use the application later
- Customer: pays for the application
- Stakeholder: is involved in the project in some way
- Team: the development team
Walt Disney Strategy
Capture and test the vision of the application.
Approach: Go through the three roles (dreamer, critic, planner) with the vision of the application.
Result: A clearer vision, a reality check, first action steps
VAKOG Model
Experience how users picture the application.
Approach:
- The user immerses themselves in their idea of the application.
- The user describes their idea visually, kinesthetically and auditorily.
Result: A more detailed description of what the user has in mind, the user’s dominant perceptual channels, and what the target group has in common.
UI and usability
Approach:
- Present interface and interaction concepts to the user visually, kinesthetically and auditorily.
- The user gives feedback.
Result: Corrections and adjustments based on the user’s feedback. Refined details and a refined interaction concept.
Submodalities
Design UI and usability
Approach:
- The user immerses themselves in their idea of the application.
- The user imagines the interface, the feel and the workflows of the application.
- The user changes the submodalities until the image or feeling fits for them.
Result: Ideas for adapting the interface, the interaction and the workflows.
Dilts Pyramid
Test and internalize the future picture of the application.
Approach:
- Visualize the finished product (functions, benefits, UI).
- Go through the Dilts pyramid and experience and test the product on each level:
- Environment: What technical environment and what user attitudes does it meet?
- Behavior: How do people work with the application? What workflows does it offer? How does it interact with the user?
- Capabilities: What can the application do? What functions and options does it offer?
- Values/beliefs: What guiding ideas does the application follow? Which architecture and design concepts does it put into practice?
- Identity: Which business process does the application support?
- Vision: What value does the application create for the user? What feeling does it leave behind after working with it?
Perceptual Positions
Put yourself in the stakeholders’ shoes.
Approach:
- A team member (developer, designer, etc.) steps into the position of a stakeholder (user, customer, management, support, operations) using a spatial anchor.
- The team member feels their way into that position and describes the stakeholder’s expectations, wishes and view of the project or product.
Result: A better understanding of everyone involved in the project and the product.
Mentor Technique
Consult the most important customers and users.
Approach:
- Specific customers or users of the application are chosen as mentors.
- Questions are answered from the mentors’ perspective. Ideas for questions:
- What benefit or value should the application deliver?
- Which functions have the highest priority? Which don’t?
- Which platforms are relevant? Which aren’t?
- Where is the focus when it comes to usability?
- What are the no-gos for the application to be accepted?
Result: An ongoing check of whether the project is still heading in the right direction. In addition to real customer interviews.
Modeling the Development Process
Model the development process of successful projects.
Approach:
- Look for and identify successful projects that match your own.
- Elicit their strategy.
- Transfer the strategy to your own approach and adapt it to your own needs and constraints.
Result: A better development process, a fresh perspective, best practices put to use
TOTE Model
The agile development process.
TOTE stands for Test, Operate, Test, Exit: the current state is compared with the goal, then you act and compare again, until the goal is reached and the loop ends. In software development, this corresponds to iterative process models.
Approach: Use iterative development models such as Scrum. Short, fixed iterations of 2 to 4 weeks
- In the planning meeting, the tasks for the next iteration are planned. Priority goes to the tasks with the highest (business) value for the application and to tasks that can be fully completed within this iteration.
- During the iteration, the team works through the tasks.
- At the end of the iteration, a review meeting presents the result to the user or customer. Through feedback and input, they can influence and help shape the next iteration.
- Once all requirements have been implemented after x iterations (the application meets the customer’s or user’s expectations), development is complete.
Result: A self-adjusting process with short feedback loops that allows quick corrections.
Frequently Asked Questions
Why do software projects often fail when it comes to translating user requirements into technical specifications?
Because users themselves can often only articulate their needs at a superficial level. Requirements engineering takes their statements as a starting point and uses them to create (semi-)formal specifications, for example using UML or BPMN. The step that comes before this remains unaddressed: helping users recognize their own ideas. This is precisely where the methods described come into play, and their results have an impact ranging from the scope of functionality to the user interface design.
How can a user’s ideas about future software be captured more accurately?
Through multiple channels of perception. The user immerses themselves in their vision of the application and describes it visually, kinesthetically, and auditorily. This yields a more detailed description than a mere list of wishes, reveals their predominant channels of perception, and highlights commonalities within the target group. The same approach can later be used to present interface concepts and gather feedback.
How can you generate ideas for the interface and workflows before a prototype exists?
By mentally visualizing the user interface, haptics, and processes, and then adjusting the details of this visualization until a coherent image or feeling emerges. These adjustments give rise to concrete ideas for refining the user experience and workflows, even before any design or development effort is invested.
At what levels should a planned product be thought through?
Six levels are useful once the finished product, including its features, benefits, and user interface, has been visualized: Environment, meaning the technical setting and user attitudes; Behavior, involving workflows and interaction; Capabilities, meaning features and possibilities; Values, encompassing guiding principles as well as architectural and design concepts; Identity, i.e., the business process being supported; and Vision, the value created and the impression left behind.
How can a development team better understand the perspectives of other project stakeholders?
A team member uses a spatial anchor to put themselves in the position of a stakeholder: user, customer, management, support, or operations. From this perspective, they describe expectations, wishes, and views regarding the project and product. It is important to distinguish between the roles: The user will use the application later, while the customer pays for it. Both have different expectations.
How do you continuously check whether a project is still heading in the right direction?
Specific customers or users are brought in as mentors, and the team answers questions from their perspective: What benefits should the application provide? Which features and platforms have priority, and which do not? What is the focus when it comes to usability? What are the deal-breakers for acceptance? This doesn’t replace real customer interviews; it complements them between meetings.
Why are short iterations with customer feedback more effective than a one-time requirements gathering session?
Because this allows the process to self-adjust. The 2015 article described fixed iterations of two to four weeks: Planning is based on the highest business value and on what can be fully completed within the iteration. At the end, the user sees the result and helps shape the next iteration with their feedback. Development is complete when the application meets expectations.
