• Sabyasachi

The creating of persons for software designing

Interaction design is a process for software design focusing on the most important users. Unlike traditional techniques to capture requirements, interaction design focuses on the objectives of a particular class of users, represented as a person. These are the objectives that are considered when are defined the scenarios that represent how this person will use the software. The combination of objective and scenarios leading to the creation of the functional specification of the product, strongly focused on solving the life of a particular group of people.

Selecting people

Usually, there are many users of an application. A person is an imaginary user, which represents a class of users with common objectives and roles. The first thing that makes an interaction designer is to create a detailed person for each user class. Users who share goals and roles are represented by the same person.

Practical objectives and personal objectives: the objectives for the person in two distinct areas are defined. The practical objectives are related to the individual's role (fulfilling a number of sales, close at least multimillion-dollar deal each semester). The personal objectives are difficult or at least difficult for programmers, who consider completely irrelevant. No matter how irrelevant they appear to be, these personal goals are key to understanding how this person will interact with the software, expectations, prejudices, fault tolerance level or confusing interfaces.

Once they are defined all people, identify one or two key people and key users of the application. All requirements and development of features are specifically made for the principal person. It is not known to other users. The developers are sure to argue that "someone" want feature X, and attempt to add to the scope. If the person does not need it, the software does not. Also they ignored the features that serve to sell the software (and not serves to use the software).

Select to the main person is an exercise in prioritization. The logical choice is someone who combines the most valuable corporate objectives with the more frequent use of the system. Can exist two persons, for example, the main person that entering information into the system and the main person who consumes this information. Include any other secondary person will dilute the power of software. Try to make software that does everything for all people’s ends up in a complex product that is difficult to use them all equally.

Defining scenarios

The scenarios describe what the main person needs to do when using the software. The design of interactions first identifies all the things you need to do the person with the software. Each of these activities is a scenario. Then scenarios are categorized in daily use, uses necessary and frontier cases.

The frontier cases are discarded immediately. These occur so infrequently that the cost of implementing exceeds the benefit. This cost is not only monetary, but also the cost of the user from having to understand, ignore or work on extra features needed to support a frontier scenario.

The scenarios needed are those must occur, but very infrequently. The requirement specification includes functional features needed to support these scenarios. The interaction designer is not going to work hard on optimizing these scenarios: as they are so rare, users will tolerate any existing implementation to occur.

The daily scenarios are those that main person who frequently use. Most users have one or two scenes a day. It is rare that exist one or two scenarios daily. This is where new users must achieve maximum efficiency as soon as possible, where they recover before the benefits of good design, and where to apply every effort to design interactions.

Design the solution

The design is divided into two components, program design and the design of interactions. The program design is all that we see. Interaction design is all we can see.

The interactions are designed to withstand the scenarios (which are built in the context of practical objectives). Design decisions are taken to support the best possible person in the context of their personal goals. And here it is where programmers get confused. Programmers want to know how it affects the hypothetical wishes of a person in the design of the interfaces and interactions.

The usability helps build a bridge between these two camps, and plays an important role. Programmers can understand the evidence, statistics, analyzes and experiences can lead to decisions on how people use a computer to comply a practical objective.

There are many good ideas, especially the prioritization of the most important users and their associated daily scenarios. It is also important the focus in minimize the features to maximize the utility of the software.

2 vistas0 comentarios

Entradas Recientes

Ver todo

Project Management Institute, PMI, Project Management Professional, PMP, PMBOK, Certified Associate in Project Management, CAPM, PMI A, PgMP, PfMP, ACP, PBA, RMP, SP y OPM3 son marcas registradas y de propiedad del Project Management Institute, Inc.

SBOK, el logotipo de SCRUMstudy, SDC, SMC, SAMC, SPOC y ESMC son marcas registradas de SCRUMstudy™ (una marca de VMEdu, Inc).

Six Sigma Yellow Belt SSYB, Six Sigma Green Belt SSGB, Six Sigma Black Belt SSBB, Lean Six Sigma Black Belt (LSSB), son marcas registradas y de propiedad de 6sigmastudy.

Los nombres de empresas y los logotipos de empresas mencionados en este sitio web son marcas comerciales registradas y de propiedad de las empresas correspondientes.

© 2020 KiPoint Solutions, S.A. de C.V. - Todos los Derechos Reservados.

(+52 55) 6381 3969 | contacto@kipoint.com.mx

Aviso de Privacidad

  • Facebook - Black Circle
  • Twitter - Black Circle
  • LinkedIn - Círculo Negro
  • YouTube - Black Circle