Sensory impressions in software design 

 May 25, 2015

Problem

One of the causes of failed software projects is the transformation of the users' wishes and ideas into the technical implementation. Requirements engineering starts here and tries to transform the user's ideas into technical requirements for the application. These methods are based more on the technical side and create, such as UML, BPMN, etc., a (semi-)formal specification from the statements of the users. With the methods presented here, it is possible to start one step earlier and go deeper. By not only using the statements of the users, but really supporting them in identifying their wishes. This creates the opportunity to go into depth where normal RE methods remain on the surface. The input gained can support the entire project, from the planning of the functional scope to the interface design.

Definitions

  • User: uses the application later
  • Customer: pays for the application
  • Stakeholder: is involved in some way in the project
  • Team: Development team

Walt Disney Strategy

Grasp and examine the vision of the application.

Procedure: Go through the three roles (dreamer, critic, planner) with the vision of the application.

Result: clarification of the vision, reality check, first action steps

VAKOG model

user's perceptions.

Procedure:

  1. The user dives into his imagination of the application.
  2. The user describes his imagination visually, kinesthetically and auditorily.

Result: more detailed description of the user's ideas, distinctive perception channels of the user, learn commonalities of the target group.

UI and Usability

Procedure:

  1. Present concepts of interface and operation to the user visually, kinesthetically and auditorily.
  2. The user gives feedback.

Result: Corrections and adjustments based on user feedback. Refinement of the details and the operating concept.

Submodalities

Design UI and usability

Procedure:

  1. The user dives into his imagination of the application.
  2. The user imagines the interface, the feel and the workflows of the application.
  3. The user changes the submodalities until a coherent image/feeling is created.

Result: Ideas for the adaptation of the user interface, the operation and the workflows.

Dilts Pyramid

Examine and internalize the future image of the application.

Procedure:

  1. Visualize the finished product (features, benefits, UI).
  2. Going through the Dilts pyramid and experiencing and testing the product in the levels:
    • Environment: What environment (technical) and what environment (user attitude) does it encounter?
    • Behavior: How can you work with the application? Which workflows does it offer? How does the application interact with the user?
    • Capabilities: What can the application do? What functions and possibilities does it offer?
    • Values/beliefs: What are the application's guiding ideas? What architectural and design concepts does it realize?
    • Identity: Which business process does the application support?
    • Vision: What benefits does the application bring to the user? What feeling does it leave behind after work?

Perception positions

Putting yourself in the shoes of the stakeholders.

Procedure:

  1. Team member (developer, designer, etc.) puts himself in the position of a stakeholder (user, customer, management, support, operation) via room anchors.
  2. Team member feels into the position and describes the expectations, wishes and view of the project/product.

Result: Better understanding of all project and product participants.

Mentor Technology

Survey of key customers/users.

Procedure:

  1. Actual customers/users of the application are used as mentors.
  2. Questions will be answered from the mentors' perspective. Ideas for questions:
    • What benefit/value should the application bring?
    • Which functions have the highest priority? Which not?
    • Which platforms are relevant? Which are not?
    • What is the focus in terms of usability?
    • What are no-gos for app adoption?

Result: Ongoing check whether the project is still heading in the right direction. In addition to real customer interviews.

Modelling for the development process

Model the development process of successful projects.

Procedure:

  1. Search and identification of successful projects, suitable for your own project.
  2. Elicit strategy.
  3. Transfer of the strategy to your own approach, adaptation to your own needs and specifications.

Result: Improved development process, new perspective, application of best practices

TOTE model

The agile development process.

Approach: Use of iterative development models such as Scrum. Short, fixed iterations between 2 and 4 weeks.

  1. (T) In the planning meeting, the tasks of the next iteration are planned. The priority in the selection of tasks is the highest (business) value for the application and tasks that can also be completely processed during this iteration.
  2. (O) During the iteration, the tasks are processed by the team.
  3. (T) At the end of the iteration, a review meeting takes place in which the result of the iteration is presented to the user/customer. The user/customer can influence and shape the progress of the next iteration through feedback and input.
  4. (E) If all requirements are implemented after x iterations (application meets customer/user expectations), development is complete.

Result: A self-adjusting process with short feedback loops that enables quick corrections.