Reference: Sommerville, Engineering Software Products, Chapter 3

 

There are three factors that drive the design of software products:

• Business and consumer needs that are not met by current products;
• Dissatisfaction with existing business or consumer software products;
• Changes in technology that make completely new types of product possible.

In the early stage of product development, you are trying to understand, what product features would be useful to users, and what they like and dislike about the products that they use.

A feature is a fragment of functionality such as a 'print' feature, a 'change background feature', a 'new document' feature and so on. Before you start programming a product, you should aim to create a list of features to be included in your product. The feature list should be your starting point for product design and development.

It makes sense in any product development to spend time trying to understand the potential users and customers of your product. A range of techniques have been developed for understanding the ways that people work and use software. These include user interviews, surveys, ethnography and task analysis. Some of these techniques are expensive and unrealistic for small companies. Informal user analysis and discussions, which simply involve asking users about their work, the software that they use, and its strengths and weaknesses are inexpensive and very valuable.

You need to have an understanding of your potential users to design features that they are likely to find useful and to design a user interface that is suited to them. Personas are 'imagined users' where you create a character portrait of a type of user that you think might use your product. For example, if your product is aimed at managing appointments for dentists, you might create a dentist persona, a receptionist persona and a patient persona. Personas of different types of user help you imagine what these users may want to do with your software and how it might be used. They help you envisage difficulties that they might have in understanding and using product features.

A persona should 'paint a picture' of a type of product user. They should be relatively short and easy-to-read. You should describe their background and why they might want to use your product. You should also say something about their educational background and technical skills. These help you assess whether or not a software feature is likely to be useful, understandable and usable by typical product users.

Aspects of persona descriptions:

• Personalization: You should give them a name and say something about their personal circumstances. It is sometimes helpful to use an appropriate stock photograph to represent the person in the persona. Some studies suggest that this helps project teams use personas more effectively.
• Job-related: If your product is targeted at business, you should say something about their job and (if necessary) what that job involves. For some jobs, such as a teacher where readers are likely to be familiar with the job, this may not be necessary.
• Education: You should describe their educational background and their level of technical skills and experience. This is important, especially for interface design.
• Relevance: If you can, you should say why they might be interested in using the product and what they might want to do with it.

The main benefit of personas is that they help you and other development team members empathize with potential users of the software. Personas help because they are a tool that allows developers to 'step into the user's shoes'. Instead of thinking about what you would do in a particular situation, you can imagine how a persona would behave and react. Personas can help you check your ideas to make sure that you are not including product features that aren't really needed. They help you to avoid making unwarranted assumptions, based on your own knowledge, and designing an over-complicated or irrelevant product.

Personas should be based on an understanding of the potential product users, their jobs, their background and their aspirations. You should study and survey potential users to understand what they want and how they might use the product. From this data, you can then abstract the essential information about the different types of product user and use this as a basis for creating personas. Personas that are developed on the basis of limited user information are called proto-personas. Proto-personas may be created as a collective team exercise using whatever information is available about potential product users. They can never be as accurate as personas developed from detailed user studies, but they are better than nothing.

A scenario is a narrative that describes how a user, or a group of users, might use your system. There is no need to include everything in a scenario – the scenario isn't a system specification. It is simply a description of a situation where a user is using your product's features to do something that they want to do. Scenario descriptions may vary in length from two to three paragraphs up to a page of text.

Scenario elements:

• A brief statement of the overall objective.
• References to the personas involved so that you can get information about the capabilities and motivation of that user.
• Information about what is involved in doing the activity.
• An explanation of problems that can't be readily addressed using the existing system.
• A description of one way that the identified problem might be addressed.

Scenarios should always be written from the user's perspective and based on identified personas or real users. Your starting point for scenario writing should be the personas that you have created. You should normally try to imagine several scenarios from each persona. Ideally, scenarios should be general and should not include implementation information. However, describing an implementation is often the easiest way to explain how a task is done. It is important to ensure that you have coverage of all of the potential user roles when describing a system.

It is easy for anyone to read and understand scenarios, so it is possible to get users involved in their development. The best approach is to develop an imaginary scenario based on our understanding of how the system might be used then ask users to explain what you have got wrong. They might ask about things they did not understand and suggest how the scenario could be extended and made more realistic.

Scenarios are high-level stories of system use. They should describe a sequence of interactions with the system but should not include details of these interactions. User stories are finer-grain narratives that set out in a more detailed and structured way a single thing that a user wants from a software system. A de-facto standard for writing a story includes a role, an action, and a reason:
      As a <role> I <want | need> to <do something> so that <reason>.

An important use of user stories is in planning. Many users of the Scrum method represent the product backlog as a set of user stories. User stories should focus on a clearly defined system feature or aspect of a feature that can be implemented within a single sprint. If the story is about a more complex feature that might take several sprints to implement, then it is called an epic.

Stories can be used to describe features in your product that should be implemented. Each feature can have a set of associated stories that describe how that feature is used.

As you can express all of the functionality described in a scenario as user stories, do you really need scenarios? Scenarios read more naturally because they describe what a user of a system is actually doing with that system. People often find it easier to relate to this specific information rather than the statement of wants or needs set out in a set of user stories. If you are interviewing real users or are checking a scenario with real users, they don't talk in the stylized way that is used in user stories. People relate better to the more natural narrative in scenarios. Scenarios often provide more context - information about what the user is trying to do and their normal ways of working. You can do this in user stories, but it means that they are no longer simple statements about the use of a system feature.

Your aim in the initial stage of product design should be to create a list of features that define your product. A feature is a way of allowing users to access and use your product's functionality so the feature list defines the overall functionality of the system. Features should be independent, coherent and relevant:

• Independence: Features should not depend on how other system features are implemented and should not be affected by the order of activation of other features.
• Coherence: Features should be linked to a single item of functionality. They should not do more than one thing and they should never have side-effects.
• Relevance: Features should reflect the way that users normally carry out some task. They should not provide obscure functionality that is hardly ever required.

Knowledge required for feature design:

• User knowledge: You can use user scenarios and user stories to inform the team of what users want and how they might use the software features.
• Product knowledge: You may have experience of existing products or decide to research what these products do as part of your development process. Sometimes your features have to replicate existing features in these products because they provide fundamental functionality that is always required.
• Domain knowledge: This is knowledge of the domain or work area (e.g., finance, event booking) that your product aims to support. By understanding the domain, you can think of new innovative ways of helping users do what they want to do.
• Technology knowledge: New products often emerge to take advantage of technological developments since their competitors were launched. If you understand the latest technology, you can design features to make use of it.

Feature trade-offs:

• Simplicity and functionality: You need to find a balance between providing a simple, easy-to-use system and including enough functionality to attract users with a variety of needs.
• Familiarity and novelty: Users prefer that new software should support the familiar everyday tasks that are part of their work or life. To encourage them to adopt your system, you need to find a balance between familiar features and new features that convince users that your product can do more than its competitors.
• Automation and control:Some users like automation, where the software does things for them. Others prefer to have control. You have to think carefully about what can be automated, how it is automated and how users can configure the automation so that the system can be tailored to their preferences.

Feature creep occurs when new features are added in response to user requests without considering whether or not these features are generally useful or whether they can be implemented in some other way. Too many features make products hard to use and understand. There are three reasons why feature creep occurs:

1. Product managers are reluctant to say 'no' when users ask for specific features.
2. Developers try to match features in competing products.
3. The product includes features to support both inexperienced and experienced users.

Features can be identified directly from the product vision or from scenarios. You can highlight phrases in narrative description to identify features to be included in the software. You should think about the features needed to support user actions, identified by active verbs, such as use and choose.

The output of the feature identification process should be a list of features that you use for designing and implementing your product. There is no need to go into a lot of detail about the features at this stage. You add detail when you are implementing the feature. You can describe features using a standard input-action-output template by using structured narrative descriptions or by a set of user stories.

Scenarios and user stories should always be your starting point for identifying product features. Scenarios tell you how users work at the moment. They don't show how they might change their way of working if they had the right software to support them. Stories and scenarios are 'tools for thinking' and they help you gain an understanding of how your software might be used. You can identify a feature set from stories and scenarios. User research, on its own, rarely helps you innovate and invent new ways of working. You should also think creatively about alternative or additional features that help users to work more efficiently or to do things differently.

• How To Write User Stories, Epics, & Personas by Anissa Deanna