Design Thinking and Ideation

Start by understanding your users' needs, wants, and pain points. Conduct user research, such as interviews or surveys, to gather insights into their behaviours and motivations. This helps you identify what problems they are trying to solve with your software.

User Stories 

A user story is an informal, general explanation of a software feature written from the perspective of the end user. Its purpose is to articulate how a software feature will provide value to the customer.

It's tempting to think that user stories are, simply put, software system requirements. But they're not. User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the customer. Note that "customers" don't have to be external end users in the traditional sense, they can also be internal customers or colleagues within your organization who depend on your team.

In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

Consider the following when writing user stories:

• Definition of “done”. The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
• Outline subtasks or tasks. Decide which specific steps need to be completed and who is responsible for each of them.
• User personas. For whom? If there are multiple end users, consider making multiple stories.
• Ordered Steps. Write a story for each step in a larger process.
• Listen to feedback. Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
• Time. Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
• Visibility. Once the user stories are clearly defined, make sure they are visible for the entire team.

Use the insights from the empathize stage to define the problem you are trying to solve. Develop a clear problem statement that summarizes the challenge you are trying to address.

There are many techniques that teams can use to generate and refine ideas during software project development.

During ideation, it is important to encourage creativity and open-mindedness, and to create an environment where team members feel comfortable sharing their ideas. It's also essential to establish clear goals and criteria for success, so that ideas can be evaluated and refined effectively.

Once ideas have been generated, they can be prioritized and refined based on their feasibility, impact, and alignment with project goals. The most promising ideas can then be developed further and integrated into the software project.

Activity

For this checkpoint, you will have a brainstorming session with your team. You can identify and outline the challenges related to your project.

Brainstorm possible solutions to the problem you've defined. Encourage creativity and open-mindedness in this phase and generate as many ideas as possible.

Consider some of the following techniques.

1. SCAMPER
2. Mindmapping
3. Forced analogies

SCAMPER

Scamper is an acronym that stands for:

S – Substitute

C – Combine

A – Adapt

M – Modify

P – Put to another use

E – Eliminate

R – Reverse

SCAMPER is an idea generation technique beneficial when looking for ways to extend or improve an existing design, making it a great strategy to use during the development stages.

We can use SCAMPER individually or in a team by asking questions about the current design that forces us to think about it from alternative perspectives.

Mindmapping

Minding mapping is a connection visualisation technique that you may have already heard of. It was first developed by the English author and researcher Tony Buzan and discussed in his book ‘Use your Head’ (1972).

mindmapping.com describes a six-step process:

(How To Make A Mind Map | MindMapping.com, n.d.).

1. Enter the Main Topic. Start by entering the main subject in the centre of the mind map, for instance, “Capitals of the world”.
2. Brainstorm Topics. Create main branches to enter your topics such as “London”, “Paris”, “New York” and “Beijing”. Do not worry about the order of the topics.
3. Create Sub-Topics. Elaborate on your topics by creating subtopics. Make sure to use very short phrases or even single words.
4. Rearrange the Topics. If you need to rearrange the topics in your mind map, most software tools allow you to drag-and-drop branches. This will enable you to structure the topics that you brainstormed.
5. Add Images and Formatting. According to the mind mapping theory, images and colours improve memory retention. You can use different colours and fonts and place images on branches.
6. Notes and Research. Take notes of your topics and attached research files - if your mind mapping software allows you to.

Forced analogies

Analogies are a way of comparing two things to show how they are alike to make a point of the comparison. We use analogies all the time in our day to day language. “Life is like a box of chocolates – you never know what you’re gonna get”. You may remember this line from the film Forrest Gump (1994). The first part of the line is a simile comparing life to a box of chocolates. The addition of “you never know what you’re gonna get” makes it an analogy by defining the point of the comparison.

Forced analogies use randomly generated comparisons to spark new creative ways of looking at and solving a problem.

Think of two words, and join them up by the phrase ‘is like’. This will force your thought processes into places you may never have gone and should allow you to develop unique solutions to your task.

Ask yourself:

• How is my problem like a (insert random object)? List traits that could be shared between the problem and the object.
• How may I solve my problem with a (insert random object)? What aspects of the random object could be used to solve the problem.
• How would (insert famous person’s name) solve this problem? Think about how that person might approach the problem if it were part of their area of knowledge.

Try using this random object generator, https://perchance.org/object and this famous person generator https://www.randomlists.com/random-people

Rules for idea generation

The following are some basic rules for any idea generation session, whether you are working in a group or individually:

1. Consider everything that is suggested. In a group situation, try not to criticise anyone’s ideas, and try not to censor yourself when generating ideas. Avoid judging or dismissing anything before you explore it thoroughly. Stating the obvious is just as important as being creative or obscure. Be positive!

2. Try to gather large quantities of ideas. Quantity, not necessarily quality, is the aim of an idea generation session. You can throw out as much as you like after the session, and the more ideas you write down, the more you will generate.

3. Challenge your preconceptions and stereotypes. Be highly aware of your ways of thinking and deliberately try to break out of those patterns. It might seem scary, especially in a group situation, but try to eliminate your fear of making mistakes. There are no mistakes when generating ideas. Be honest and open, and you will find that your ideas will start to flow.

4. Build on ideas. Try to add extra thoughts to each idea. If you are generating ideas in a group, let yourself be inspired by other people’s ideas. Try combining ideas to create new ones. Stop and return to the process to maintain freshness and objectivity.

5. Record everything immediately. Make sure you write down every idea as soon as it is thought of. If you do not, then it may become subject to subconscious censorship and may never be recorded.

6. Make sure you are in a comfortable and relaxing environment. You’ll find that you are much more productive if you have set aside a specific time and place for an idea generation session. Make sure that you can brainstorm undisturbed and have enough paper and pencils or pens. You might like to use music to help relax you. You might also find a pile of magazines or books useful for visual stimulation.

7. Listen to everyone else in the group. When you are in a group situation, remember to listen actively and try not to prepare your response or thinking of your own ideas.

8. Don’t interrupt or argue!If you are on your own, listen to your thoughts and note down everything that comes into your head. Try not to use negative terminology – can’t, don’t, won’t.

9. Allow for wild and wacky ideas. Don’t stop yourself from suggesting something because you think it is too ridiculous. It is much easier to tone down ideas than it is to think of the perfect solution immediately. You will be surprised how radical ideas can set off thought processes. See how exaggerated you can be.

Develop low-fidelity prototypes of your solutions to test and refine your ideas. This can be as simple as sketches or paper prototypes, or as complex as interactive wireframes or clickable mockups.

UML Design and Wireframing 

You will use UML diagrams and wireframing to plan, design and communicate the requirements and functionality of a software project.

Both of these methods can also help to depict your:

• use case diagram,
• class diagram ( where you show the relationships between classes in your system and the attributes and methods associated with each class),
• create sequence diagrams to show the interactions between objects in your system over time,
• and represent state diagrams to show the different states that an object can be in and the events that cause it to transition from one state to another.

If you have forgotten how to use these tools, please refer to the resources provided in this section.

Note that you can use this diagrams to communicate the requirements and functionality of your software project to relevant stakeholders . This might also help you to identify potential issues and design flaws early on.

You will use wireframing to create visual representations of the user interface (UI) of your software system. This can be done using specialized software tools or even simple pencil and paper sketches. This will help to define the layout and functionality of the UI and can help to identify usability issues and design flaws early on in the development process.

Similar to UML diagrams, wireframes can be used to gather feedback from stakeholders and users and can also serve as a blueprint for the development team when implementing the UI design.

Test your prototypes with real users to gather feedback and refine your ideas. Use the feedback you receive to iterate and improve your prototypes until you have a solution that meets your users' needs.

Metric Definition, Performance Evaluation, and Benchmarking 

Metrics and benchmarking are important in software development as they help developers to assess the quality, performance, and progress of their software development projects.

Benchmarking involves comparing the performance of one software development project against another or against industry standards. This helps teams to identify areas where they need to improve and to set goals for improvement. For example, a development team might benchmark their code coverage against industry standards to identify areas where they need to improve their testing practices.

During you client interactions, you client might indicate some metrics or performance objectives that they aim to achieve. You need to formalize this and use the metrics during your testing and product performance evaluation or quality assurance process.

Here are some general metrics and benchmarks used in software development that you can consider:

1. Code Coverage: This metric measures the amount of code that has been tested and helps to ensure that all the code is tested, reducing the risk of bugs.
2. Defect Density: This metric measures the number of defects found in the software code, relative to the size of the codebase. This helps developers to track the quality of the code and identify areas that need improvement.
3. Velocity: This metric measures the amount of work completed by a development team in a specific period. It helps teams to estimate the time needed to complete a project and to identify any issues that may be slowing down progress.
4. Cycle Time: This metric measures the time it takes for a development team to complete a specific task or feature. It helps teams to identify bottlenecks in their workflow and to optimize their processes for faster delivery.
5. Mean Time Between Failures (MTBF): This metric measures the average time between system failures. It helps teams to identify the reliability of their software and to identify areas that need improvement.
6. Mean Time to Recovery (MTTR): This metric measures the average time it takes to recover from a failure or downtime. It helps teams to identify areas that need improvement and to optimize their recovery processes.