basic skills in problem solving related to technology

Advisory boards aren’t only for executives. Join the LogRocket Content Advisory Board today →

• Product Management
• Solve User-Reported Issues
• Find Issues Faster
• Optimize Conversion and Adoption

A guide to problem-solving techniques, steps, and skills

You might associate problem-solving with the math exercises that a seven-year-old would do at school. But problem-solving isn’t just about math — it’s a crucial skill that helps everyone make better decisions in everyday life or work.

Problem-solving involves finding effective solutions to address complex challenges, in any context they may arise.

Unfortunately, structured and systematic problem-solving methods aren’t commonly taught. Instead, when solving a problem, PMs tend to rely heavily on intuition. While for simple issues this might work well, solving a complex problem with a straightforward solution is often ineffective and can even create more problems.

In this article, you’ll learn a framework for approaching problem-solving, alongside how you can improve your problem-solving skills.

The 7 steps to problem-solving

When it comes to problem-solving there are seven key steps that you should follow: define the problem, disaggregate, prioritize problem branches, create an analysis plan, conduct analysis, synthesis, and communication.

1. Define the problem

Problem-solving begins with a clear understanding of the issue at hand. Without a well-defined problem statement, confusion and misunderstandings can hinder progress. It’s crucial to ensure that the problem statement is outcome-focused, specific, measurable whenever possible, and time-bound.

Additionally, aligning the problem definition with relevant stakeholders and decision-makers is essential to ensure efforts are directed towards addressing the actual problem rather than side issues.

2. Disaggregate

Complex issues often require deeper analysis. Instead of tackling the entire problem at once, the next step is to break it down into smaller, more manageable components.

Various types of logic trees (also known as issue trees or decision trees) can be used to break down the problem. At each stage where new branches are created, it’s important for them to be “MECE” – mutually exclusive and collectively exhaustive. This process of breaking down continues until manageable components are identified, allowing for individual examination.

The decomposition of the problem demands looking at the problem from various perspectives. That is why collaboration within a team often yields more valuable results, as diverse viewpoints lead to a richer pool of ideas and solutions.

3. Prioritize problem branches

The next step involves prioritization. Not all branches of the problem tree have the same impact, so it’s important to understand the significance of each and focus attention on the most impactful areas. Prioritizing helps streamline efforts and minimize the time required to solve the problem.

Over 200k developers and product managers use LogRocket to create better digital experiences

4. Create an analysis plan

For prioritized components, you may need to conduct in-depth analysis. Before proceeding, a work plan is created for data gathering and analysis. If work is conducted within a team, having a plan provides guidance on what needs to be achieved, who is responsible for which tasks, and the timelines involved.

5. Conduct analysis

Data gathering and analysis are central to the problem-solving process. It’s a good practice to set time limits for this phase to prevent excessive time spent on perfecting details. You can employ heuristics and rule-of-thumb reasoning to improve efficiency and direct efforts towards the most impactful work.

6. Synthesis

After each individual branch component has been researched, the problem isn’t solved yet. The next step is synthesizing the data logically to address the initial question. The synthesis process and the logical relationship between the individual branch results depend on the logic tree used.

7. Communication

The last step is communicating the story and the solution of the problem to the stakeholders and decision-makers. Clear effective communication is necessary to build trust in the solution and facilitates understanding among all parties involved. It ensures that stakeholders grasp the intricacies of the problem and the proposed solution, leading to informed decision-making.

Exploring problem-solving in various contexts

While problem-solving has traditionally been associated with fields like engineering and science, today it has become a fundamental skill for individuals across all professions. In fact, problem-solving consistently ranks as one of the top skills required by employers.

Problem-solving techniques can be applied in diverse contexts:

• Individuals — What career path should I choose? Where should I live? These are examples of simple and common personal challenges that require effective problem-solving skills
• Organizations — Businesses also face many decisions that are not trivial to answer. Should we expand into new markets this year? How can we enhance the quality of our product development? Will our office accommodate the upcoming year’s growth in terms of capacity?
• Societal issues — The biggest world challenges are also complex problems that can be addressed with the same technique. How can we minimize the impact of climate change? How do we fight cancer?

Despite the variation in domains and contexts, the fundamental approach to solving these questions remains the same. It starts with gaining a clear understanding of the problem, followed by decomposition, conducting analysis of the decomposed branches, and synthesizing it into a result that answers the initial problem.

Real-world examples of problem-solving

Let’s now explore some examples where we can apply the problem solving framework.

Problem: In the production of electronic devices, you observe an increasing number of defects. How can you reduce the error rate and improve the quality?

Before delving into analysis, you can deprioritize branches that you already have information for or ones you deem less important. For instance, while transportation delays may occur, the resulting material degradation is likely negligible. For other branches, additional research and data gathering may be necessary.

Once results are obtained, synthesis is crucial to address the core question: How can you decrease the defect rate?

While all factors listed may play a role, their significance varies. Your task is to prioritize effectively. Through data analysis, you may discover that altering the equipment would bring the most substantial positive outcome. However, executing a solution isn’t always straightforward. In prioritizing, you should consider both the potential impact and the level of effort needed for implementation.

By evaluating impact and effort, you can systematically prioritize areas for improvement, focusing on those with high impact and requiring minimal effort to address. This approach ensures efficient allocation of resources towards improvements that offer the greatest return on investment.

Problem : What should be my next job role?

When breaking down this problem, you need to consider various factors that are important for your future happiness in the role. This includes aspects like the company culture, our interest in the work itself, and the lifestyle that you can afford with the role.

However, not all factors carry the same weight for us. To make sense of the results, we can assign a weight factor to each branch. For instance, passion for the job role may have a weight factor of 1, while interest in the industry may have a weight factor of 0.5, because that is less important for you.

By applying these weights to a specific role and summing the values, you can have an estimate of how suitable that role is for you. Moreover, you can compare two roles and make an informed decision based on these weighted indicators.

Key problem-solving skills

This framework provides the foundation and guidance needed to effectively solve problems. However, successfully applying this framework requires the following:

• Creativity — During the decomposition phase, it’s essential to approach the problem from various perspectives and think outside the box to generate innovative ideas for breaking down the problem tree
• Decision-making — Throughout the process, decisions must be made, even when full confidence is lacking. Employing rules of thumb to simplify analysis or selecting one tree cut over another requires decisiveness and comfort with choices made
• Analytical skills — Analytical and research skills are necessary for the phase following decomposition, involving data gathering and analysis on selected tree branches
• Teamwork — Collaboration and teamwork are crucial when working within a team setting. Solving problems effectively often requires collective effort and shared responsibility
• Communication — Clear and structured communication is essential to convey the problem solution to stakeholders and decision-makers and build trust

How to enhance your problem-solving skills

Problem-solving requires practice and a certain mindset. The more you practice, the easier it becomes. Here are some strategies to enhance your skills:

• Practice structured thinking in your daily life — Break down problems or questions into manageable parts. You don’t need to go through the entire problem-solving process and conduct detailed analysis. When conveying a message, simplify the conversation by breaking the message into smaller, more understandable segments
• Regularly challenging yourself with games and puzzles — Solving puzzles, riddles, or strategy games can boost your problem-solving skills and cognitive agility.
• Engage with individuals from diverse backgrounds and viewpoints — Conversing with people who offer different perspectives provides fresh insights and alternative solutions to problems. This boosts creativity and helps in approaching challenges from new angles

Final thoughts

Problem-solving extends far beyond mathematics or scientific fields; it’s a critical skill for making informed decisions in every area of life and work. The seven-step framework presented here provides a systematic approach to problem-solving, relevant across various domains.

Now, consider this: What’s one question currently on your mind? Grab a piece of paper and try to apply the problem-solving framework. You might uncover fresh insights you hadn’t considered before.

Featured image source: IconScout

LogRocket generates product insights that lead to meaningful action

Get your teams on the same page — try LogRocket today.

Share this:

• Click to share on Twitter (Opens in new window)
• Click to share on Reddit (Opens in new window)
• Click to share on LinkedIn (Opens in new window)
• Click to share on Facebook (Opens in new window)
• #career development
• #tools and resources

Stop guessing about your digital experience with LogRocket

Recent posts:.

Enhancing product stickiness for increased user retention

A great value proposition might entice a user in the beginning, but you still need a way to maintain their loyalty for years to come.

Understanding technical debt: Beyond code quality

A proactive approach to technical debt leads to faster recovery, better performance, and a healthier product. With the right strategies, you can manage it without sacrificing innovation.

Collaboration between product management and marketing

Product management and product marketing both contribute to the success of a product in their own capacity.

Leader Spotlight: Knowing where customers are aiming, with Ravit Danino

Ravit Danino talks about how knowing where customers are aiming helps you better frame the discussion around your roadmap.

Leave a Reply Cancel reply

• University of Denver Boot Camps

18 Skills All Programmers Need to Have

Are you an aspiring programmer, or perhaps just interested in learning more about the programming field? Read on to learn more about the hard and soft skills that programmers need to succeed.

Technology has become the backbone of our everyday lives, and programmers are needed to keep moving that technology forward. The options are endless: an aspiring programmer can bring the next life-changing smartphone app to life, create new worlds in gaming, or craft the way millions of people across the globe interact and communicate online. These are just a few of the ways programmers impact the world around them, but all programmers have certain things in common — the in-demand hard and soft skills that propel their career success.

Hard Skills

• Data structures and algorithms
• Database and SQL
• Object-oriented programming (OOP) languages
• Integrated development environments (IDEs)
• Cloud computing
• Web development
• Text editors
• Git version control

Soft Skills

• Communication (verbal and written)
• Teamwork and conflict resolution
• Problem solving
• Adaptability
• Accountability
• Time management

9 Hard Skills Programmers Need

1. Data Structures and Algorithms

Many programmers think that data structures and algorithms (DSAs) are just something you have to “get through” in school, but will never need in real life. However, they’re surprised when so many interviews include DSA questions. There are several reasons companies are interested in a prospective employee’s DSA knowledge, and why programmers should be interested in it too.

For many companies, such as Meta, Google, Microsoft, and Amazon, writing code is just the final step in a long process. The majority of a programmer’s time is actually spent considering the best way to approach a project, including the best data structures and optimal algorithms to employ. These decisions have a real impact on the company’s resource usage and profitability, so it’s no surprise that DSAs figure prominently in their interview process. And, even for companies outside of Silicon Valley, these questions are important because they demonstrate a programmer’s foundational knowledge and problem solving abilities.

Once a programmer has the position, DSAs still play a role in day-to-day work. Specifically, data structures are a particular way of organizing data so that it can be used most effectively, and there are many to choose from . One of the most commonly used data structures is an array , which holds and indexes items of the same data type such as integers. Additional types of data structures include linked lists , which organize data into linear, sequentially-linked order; and stacks , which allow programmers to access recently placed items first, as if they were picking up the first book in a pile. 

Algorithms , meanwhile, are a set of instructions programmers give to computers to solve a problem, much like the recipe one might give a cook. These step-by-step guidelines can perform a variety of tasks, including searching and sorting data in a way that is ordered and makes sense.

In addition, many startups, as well as FAANG employers , look for programmers who possess the agility to scale programs and innovate through the use of DSAs.

2. Database and SQL

One of the basic expectations of any programmer is that they are familiar with core database concepts. This is because data is the fuel companies run on, and it proliferates almost every aspect of every project. 

While there are many languages used to work with databases, the most common is Structured Query Language (SQL — pronounced “sequel”). Though SQL was developed in the 1980s, it is still the standard language used to communicate with relational databases and is considered critical for modern programmers. In recent years, SQL has been heavily used by PC databases because it facilitates access to distributed databases (e.g., those spread out over multiple computer systems); allowing several local users to access the same network simultaneously. SQL also enables easy storage and organization of data in relational databases (e.g., databases where tables are related to one another through common data). 

If you’re interested in gaining SQL experience, it may be helpful to practice with MySQL . Referred to as a relational database management system (RDMS), this open-source software is based on SQL and many aspiring coders use it to work on developing their own systems, applications, and websites for free.

NoSQL , on the other hand, is a database management system (DBMS) that stores and accesses data using key-values, rather than relationally, which offers some additional flexibility. One example of a NoSQL database is MongoDB , an open-source program which can be used for high-volume document data storage, and deals with document structure variations nicely.

Of course, there are many more systems and software packages to learn when mastering databases, but having a strong foundation in database concepts and SQL is an important first step for all programmers.

3. Object-oriented programming (OOP) languages

OOP languages support a way of programming (sometimes called a paradigm) that relies on classes and objects. Think of classes like groups of similar things, such as fruits, with objects that tell us more about individual items in that class, such as apples. This programming paradigm is important because it allows programmers to easily reuse complex code across programs. For example, if I say “my apple,” it isn’t necessary for me to tell you all the attributes of my apple (i.e., red, round, grew on a tree, belongs to me). Similarly, by using an object (myapple) from a class (fruit), a programmer can easily communicate instructions or information across multiple programs, enabling more effective and efficient coding as a result.

For this reason, OOP languages such as Java , C++ , Python , and Perl are important for programmers, and they need to have at least one in their skill set.

In addition, such languages as JavaScript and PHP pair well with OOP languages to further enhance efficiencies and functionality.

4. Integrated Development Environments (IDEs)

Combining a variety of developer tools through a single graphic user interface (GUI), IDEs are a workbench for programmers where all the tools they need are laid out and ready for them to use — kind of like a workbench with a saw, drill, nails, and a hammer if you were planning to build a birdhouse.

IDEs are valuable in that by learning one IDE, a developer can become familiar with a variety of tools that work synergistically, rather than learning each tool separately and pulling together the right tools for each coding task. In addition, because all the tools are available through one GUI, the programmer doesn’t have to spend time switching between applications.

It’s important to note that IDEs are language-specific, meaning that an IDE may be designed to work with one or more programming languages. Here is a quick rundown of some of the more popular IDEs and the languages they work with (listed alphabetically).

• AWS Cloud9 : Supports over 40 languages , including JavaScript, Python, PHP, Ruby, Go, and C++ 
• Code:: Blocks : Supports C and C++
• Eclipse : Supports Java
• Eclipse Theia : Supports over 60 languages, including JavaScript, Java, and Python
• GNAT Studio : Supports Ada, SPARK, C, C++, and Python
• IntelliJ IDEA : Supports Java, but understands many other programming languages, including Groovy, Kotlin, Scala, JavaScript, TypeScript, and SQL
• NetBeans : Supports several languages including, Java, PHP, JavaFX, and JavaScript
• PyCharm : Supports major Python frameworks such as Flask, Django, web2py, Pyramid, and Google App Engine 
• SlickEdit : Supports over 70 languages , including C++, Java, HTML, PHP, JavaScript, Python, Perl, and Ruby
• Xcode : supports Swift, but allows coding in C, C++, Objective-C, Objective-C++, Java, Applescript, Python, React.js, and Ruby
• Visual Studio : Supports C, C++, C++/CLI, Visual Basic .NET, C#, F#, JavaScript, TypeScript, XML, XSLT, HTML, and CSS
• Visual Studio Code : Supports many languages including, C++, C#, CSS, Dart, Dockerfile, F#, Go, HTML, Java, JavaScript, JSON, Julia, PHP, Python, SCSS, T-SQL, and TypeScript.

It’s also important to remember that while cloud-based IDEs aren’t constrained by the programmer’s operating system, this is a use constraint for IDEs that aren’t cloud-native.

5. Cloud computing

Cloud computing is experiencing explosive growth, as cloud developers are needed for all businesses who wish to migrate their environments, storage, and digital assets to the cloud. In fact, according to LogicMonitor , 87% of global IT decision makers agree that the COVID-19 pandemic has accelerated cloud migration for most organizations. In addition, once migrated, businesses will need programmers familiar with the technology necessary to work effectively with cloud-native applications. And, as businesses rely more heavily on data science, machine learning, and artificial intelligence, work in the cloud becomes even more important since algorithms and models consume significant resources. The result of these business transitions and needs is that cloud engineers and developers, as well as cloud-savvy programmers, are in high demand.

The good news is that many of the languages needed for cloud computing are already top languages for programmers, including:

In addition, it’s a good idea for programmers to familiarize themselves with cloud platforms, such as: 

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud Platform (GCP)

Even focusing on just one, to learn key functionality, will help you gain a better understanding of how the others work, adding value to your skill set.

6. Web development

Many professionals consider web development a subset, or specialization of programming. Therefore, it only makes sense for those who plan on working in web development to learn the associated languages and tech, right? Well, maybe not.

Certainly, it goes without saying that programmers who plan to work in web development need to have a strong background in the core tools. Some of these tools include:

• HTML/CSS : HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) are both basic coding languages — often, they are the first two that web developers learn. HTML helps organize the content and structure of a web page, while CSS determines its style and presentation.
• JavaScript : JavaScript is most commonly used for front end development, though it is sometimes used for back end development as well. As one writer for Mozilla explains, “Every time a web page does more than just sit there and display static information for you to look at — displaying timely content updates, interactive maps, animated 2D/3D graphics, scrolling video jukeboxes, etc. — you can bet that JavaScript is probably involved.”
• API : An API (Application Programming Interface) is the part of a remote server that receives a user’s requests and sends responses to the rest of the server and website. Programmers set up a website’s API to complete user requests and connect them to an external server without leaving the original site. Having familiarity with APIs ranks high on any web development skills list because it helps improve a customer’s experience on websites.
• PHP : PHP (Hypertext Preprocessor) is a highly accessible, general-purpose scripting language that can be easily embedded into HTML to accentuate front end programming efforts. Unlike JavaScript, PHP is executed entirely on the server-side , rather than the client-side .

With that said, even programmers who don’t plan on working in web development can benefit from understanding the basics. For example, many projects that programmers work on include a web component. With some foundational knowledge of web development concepts, concerns, and constraints, programmers are better able to understand how data will be collected and used, what functionality may be required at a later date, and how enterprise systems may be impacted in the future. Certainly, this knowledge will help programmers have a more comprehensive understanding of not only the best way to develop their own portion of the project, but also how to offer additional solutions to those whose expertise is focused on client-side functionality.

7. Containers

Containers are preconfigured environments that package code and other dependencies an application needs to run, without the need for downloads to a physical computer. Unlike traditional methods where code is developed in a specific computing environment and transferred to a new location resulting in bugs (i.e., virtual machines ), containers bundle the application code with related configuration files, libraries, and dependencies which minimizes the potential for bugs. In addition, because the operating system (OS) files are included, containers virtualize the operating system and the application can run anywhere. As a result, programmers are able to develop and deploy applications in a faster and more secure manner. 

A basic example of container usage in education is a teacher preparing for their Python programming class . By using a container, they are able to grab the necessary application, libraries, and dependencies (including the OS), making it easier to prepare while ensuring learners will have the necessary access to learn Python from anywhere. 

Some of the most popular container management software includes:

• AWS Fargate
• Google Kubernetes Engine
• Linux Containers
• Microsoft Azure Container Services

8. Text editors

Text editors are programs that enable the opening, viewing, and editing of plain text files. Because text editors do not add formatting to text, like word processing programs do, programmers can use text editors to easily write and edit in programming and markup languages. In addition, text editors help programmers create documentation files and maintain configuration files.

Some of the most frequently used text editors include:

• Visual Studio Code
• Sublime Text

Git is a version control system that allows programmers to manage and track changes to source code throughout the development process. It makes it easy to correct any errors that may occur because every version is saved and can be recalled on demand. And, using version control encourages programmers to innovate through trial and error, as they don’t have to worry about losing previous coding attempts.

Git is the most widely used version control system among employers, so it’s important to be well versed and ready to use it when approaching a career in programming.

9 Soft Skills Programmers Need

Soft skills are different from technical (hard) skills in that they are a combination of personal attributes and interpersonal skills that enable professionals to work more effectively and more harmoniously with others.

Here are a few of the most valuable programmer soft skills:

1.  Communication : The ability to explain ideas or work methods clearly, ask and answer questions productively in a group setting, and help reduce conflict through respectful dialog is important to succeeding in coding.

2. Teamwork and conflict resolution : Constructively sharing ideas, and supporting others’ ideas in turn, is a key element in team success. But would it surprise you to know that consistent agreement isn’t always beneficial? In fact, it’s actually the differing backgrounds and ideas each team member brings to the table that helps a team yield a better result than individual outcomes. Specifically, it’s how differing ideas are discussed, tested, and applied (as a group) to reach a common goal that makes for great collaboration and outstanding results.

3.  Problem Solving : Problem-solving skills are just as important for programmers as technical ability. As Dominique Simoneau-Ritchie, the Director of Engineering at Lever, wrote for HackerNoon , “The more senior you are, the more you’ll be expected to take on complex, poorly defined problems, often with very little context. The true secret to increasing your impact is learning how to tackle a problem of any size and breaking it into manageable pieces that you can successfully solve.”

4.  Empathy : The ability to truly understand the thoughts, feelings, and experiences of another, without judgment, is a vital skill for programmers. Empathy for program end users will result in software with higher satisfaction levels and better user acceptance. And, empathy for team members will not only enhance team connections, but will also foster a culture of trust and mutual assistance. It’s no wonder that so many companies rank empathy as a top 5 soft skill.

5.  Patience : It’s a virtue — but not for the reason you might think. Patient people tend to be less stressed when dealing with obstacles. Studies have shown that cortisol (a stress hormone) negatively impacts cognitive performance, perception, and organizational skills , which are critical to successful coding. As a result, patience (or a lack thereof) can significantly impact project outcomes and coding quality.

6.  Curiosity : “The best developers tend to be naturally curious people who love to learn,” CodeFights CEO Tigran Sloyan writes for Tech Beacon . This skill is likely what drives their ongoing exploration, iterative testing of various ideas, and actively seeking new ways to improve, which are key drivers in a programmer’s growth and success.

7.  Adaptability : If there is one thing that’s constant in programming, it’s that everything changes. Technology evolves, new versions of software release, requirements change, and clients’ needs multiply. For this reason, it is imperative that programmers be adaptable and resilient when it comes to dealing with change and occasional setbacks. Having the ability to calmly assess what needs to be done and adapt is key to success in this field.

8.  Accountability : Many wrongly associate accountability with “blame,” but when used effectively, it is actually something quite different. Accountability begins before a task is assigned or a single line of code is written — it is simply the building of trust between teammates through public discussion of direction, design, and timelines. Specifically, that trust translates into each teammate committing to doing their best work, quickly letting the team know if there is an unanticipated obstacle, and knowing that teammates will work together to address the obstacle in the best way possible. By working transparently and setting collective goals and timelines, accountability is a support — not a sword. Professionals can demonstrate this skill by truly supporting their teammates in a mutual fashion to achieve their overall goals. In fact, the popularity of agile methodology through Scrum project management is an excellent example of the correct application of accountability.

9.  Time management : Whether it’s a client deadline, a team deliverable, or available budget hours, programmers must be able to manage their time effectively. This includes everything from estimating time to complete a task, helping the team agree on deliverable timelines, or completing individual tasks on time. It also includes knowing when you are running behind and asking a team member for help. Making time management a priority not only makes you more productive as an individual, but it also makes you a better, more reliable team member. Consequently, this is why employers consider this soft skill so important.

Becoming a Programmer

Career prospects for programmers look bright. According to CareerOneStop , an expected 9,700 U.S. job openings in programming are anticipated each year through 2030 with a median salary of $89,190. 

Even better, in the Denver, Colorado, area, programmers can anticipate a median salary of $91,550 and companies such as Meta (formerly Facebook), Intel, Honeywell, Lockheed Martin, and Colorado State University are all actively looking for programmers ,  

To take advantage of these great opportunities, you’ll need to acquire the knowledge and skills programmers need to be successful. The good news is that there are several options to choose from — a traditional degree, independent study, or a coding boot camp.

Obtaining a degree in computer science is always a popular choice for those interested in pursuing a career in programming. Taking three to four years, these degrees allow learners to explore the theoretical aspects of programming, while pursuing adjacent subject matter and additional interests. Given the significant time and financial commitment required to pursue this type of degree, it’s important to be sure it’s the right path for you. Some learners consider taking an introductory coding course, boot camp, or conducting independent study prior to committing to a degree program.

For those who lack the time or financial resources required to pursue a traditional degree, or want to explore their options before making a commitment, independent study can be the right choice. Also, many who prefer a slower tempo and self-directed approach pursue independent study of a programming language to enhance their existing skill set. Common options include:

• MIT OpenCourseWare  
• The Odin Project

Interestingly, many who begin their coding journey in independent study soon progress to enrolling in a coding boot camp. Boot camps are a great place to gain in-demand skills in a practical environment where learners apply their newfound knowledge on real-world projects that will eventually populate their professional portfolios. 

Regardless of the educational path you choose, the right combination of in-demand hard and soft skills will fuel your progress toward a rewarding career in programming.

Are you ready to take the next step and gain the in-demand technical skills needed for a successful web development career? Consider University of Denver Coding Boot Camp — learn critical programming languages, put them into practice on real-world projects to populate your professional portfolio, and hone your soft skills working collaboratively with your classmates. Start your future in programming today! 

Get Program Info

Step 1 of 6

What Are Problem-Solving Skills? Definition and Examples

• Share on Twitter Share on Twitter
• Share on Facebook Share on Facebook
• Share on LinkedIn Share on LinkedIn

Forage puts students first. Our blog articles are written independently by our editorial team. They have not been paid for or sponsored by our partners. See our full  editorial guidelines .

Why do employers hire employees? To help them solve problems. Whether you’re a financial analyst deciding where to invest your firm’s money, or a marketer trying to figure out which channel to direct your efforts, companies hire people to help them find solutions. Problem-solving is an essential and marketable soft skill in the workplace. 

So, how can you improve your problem-solving and show employers you have this valuable skill? In this guide, we’ll cover:

Problem-Solving Skills Definition

Why are problem-solving skills important, problem-solving skills examples, how to include problem-solving skills in a job application, how to improve problem-solving skills, problem-solving: the bottom line.

Problem-solving skills are the ability to identify problems, brainstorm and analyze answers, and implement the best solutions. An employee with good problem-solving skills is both a self-starter and a collaborative teammate; they are proactive in understanding the root of a problem and work with others to consider a wide range of solutions before deciding how to move forward. 

Examples of using problem-solving skills in the workplace include:

• Researching patterns to understand why revenue decreased last quarter
• Experimenting with a new marketing channel to increase website sign-ups
• Brainstorming content types to share with potential customers
• Testing calls to action to see which ones drive the most product sales
• Implementing a new workflow to automate a team process and increase productivity

Problem-solving skills are the most sought-after soft skill of 2022. In fact, 86% of employers look for problem-solving skills on student resumes, according to the National Association of Colleges and Employers Job Outlook 2022 survey . 

It’s unsurprising why employers are looking for this skill: companies will always need people to help them find solutions to their problems. Someone proactive and successful at problem-solving is valuable to any team.

“Employers are looking for employees who can make decisions independently, especially with the prevalence of remote/hybrid work and the need to communicate asynchronously,” Eric Mochnacz, senior HR consultant at Red Clover, says. “Employers want to see individuals who can make well-informed decisions that mitigate risk, and they can do so without suffering from analysis paralysis.”

Showcase new skills

Build the confidence and practical skills that employers are looking for with Forage’s free job simulations.

Problem-solving includes three main parts: identifying the problem, analyzing possible solutions, and deciding on the best course of action.

>>MORE: Discover the right career for you based on your skills with a career aptitude test .

Research is the first step of problem-solving because it helps you understand the context of a problem. Researching a problem enables you to learn why the problem is happening. For example, is revenue down because of a new sales tactic? Or because of seasonality? Is there a problem with who the sales team is reaching out to? 

Research broadens your scope to all possible reasons why the problem could be happening. Then once you figure it out, it helps you narrow your scope to start solving it. 

Analysis is the next step of problem-solving. Now that you’ve identified the problem, analytical skills help you look at what potential solutions there might be.

“The goal of analysis isn’t to solve a problem, actually — it’s to better understand it because that’s where the real solution will be found,” Gretchen Skalka, owner of Career Insights Consulting, says. “Looking at a problem through the lens of impartiality is the only way to get a true understanding of it from all angles.”

Decision-Making

Once you’ve figured out where the problem is coming from and what solutions are, it’s time to decide on the best way to go forth. Decision-making skills help you determine what resources are available, what a feasible action plan entails, and what solution is likely to lead to success.

On a Resume

Employers looking for problem-solving skills might include the word “problem-solving” or other synonyms like “ critical thinking ” or “analytical skills” in the job description.

“I would add ‘buzzwords’ you can find from the job descriptions or LinkedIn endorsements section to filter into your resume to comply with the ATS,” Matthew Warzel, CPRW resume writer, advises. Warzel recommends including these skills on your resume but warns to “leave the soft skills as adjectives in the summary section. That is the only place soft skills should be mentioned.”

On the other hand, you can list hard skills separately in a skills section on your resume .

Forage Resume Writing Masterclass

Learn how to showcase your skills and craft an award-winning resume with this free masterclass from Forage.

Avg. Time: 5 to 6 hours

Skills you’ll build: Resume writing, professional brand, professional summary, narrative, transferable skills, industry keywords, illustrating your impact, standing out

In a Cover Letter or an Interview

Explaining your problem-solving skills in an interview can seem daunting. You’re required to expand on your process — how you identified a problem, analyzed potential solutions, and made a choice. As long as you can explain your approach, it’s okay if that solution didn’t come from a professional work experience.

“Young professionals shortchange themselves by thinking only paid-for solutions matter to employers,” Skalka says. “People at the genesis of their careers don’t have a wealth of professional experience to pull from, but they do have relevant experience to share.”

Aaron Case, career counselor and CPRW at Resume Genius, agrees and encourages early professionals to share this skill. “If you don’t have any relevant work experience yet, you can still highlight your problem-solving skills in your cover letter,” he says. “Just showcase examples of problems you solved while completing your degree, working at internships, or volunteering. You can even pull examples from completely unrelated part-time jobs, as long as you make it clear how your problem-solving ability transfers to your new line of work.”

Learn How to Identify Problems

Problem-solving doesn’t just require finding solutions to problems that are already there. It’s also about being proactive when something isn’t working as you hoped it would. Practice questioning and getting curious about processes and activities in your everyday life. What could you improve? What would you do if you had more resources for this process? If you had fewer? Challenge yourself to challenge the world around you.

Think Digitally

“Employers in the modern workplace value digital problem-solving skills, like being able to find a technology solution to a traditional issue,” Case says. “For example, when I first started working as a marketing writer, my department didn’t have the budget to hire a professional voice actor for marketing video voiceovers. But I found a perfect solution to the problem with an AI voiceover service that cost a fraction of the price of an actor.”

Being comfortable with new technology — even ones you haven’t used before — is a valuable skill in an increasingly hybrid and remote world. Don’t be afraid to research new and innovative technologies to help automate processes or find a more efficient technological solution.

Collaborate

Problem-solving isn’t done in a silo, and it shouldn’t be. Use your collaboration skills to gather multiple perspectives, help eliminate bias, and listen to alternative solutions. Ask others where they think the problem is coming from and what solutions would help them with your workflow. From there, try to compromise on a solution that can benefit everyone.

If we’ve learned anything from the past few years, it’s that the world of work is constantly changing — which means it’s crucial to know how to adapt . Be comfortable narrowing down a solution, then changing your direction when a colleague provides a new piece of information. Challenge yourself to get out of your comfort zone, whether with your personal routine or trying a new system at work.

Put Yourself in the Middle of Tough Moments

Just like adapting requires you to challenge your routine and tradition, good problem-solving requires you to put yourself in challenging situations — especially ones where you don’t have relevant experience or expertise to find a solution. Because you won’t know how to tackle the problem, you’ll learn new problem-solving skills and how to navigate new challenges. Ask your manager or a peer if you can help them work on a complicated problem, and be proactive about asking them questions along the way.

Career Aptitude Test

What careers are right for you based on your skills? Take this quiz to find out. It’s completely free — you’ll just need to sign up to get your results!

Step 1 of 3

Companies always need people to help them find solutions — especially proactive employees who have practical analytical skills and can collaborate to decide the best way to move forward. Whether or not you have experience solving problems in a professional workplace, illustrate your problem-solving skills by describing your research, analysis, and decision-making process — and make it clear that you’re the solution to the employer’s current problems. 

Image Credit: Christina Morillo / Pexels 

Related Posts

6 negotiation skills to level up your work life, how to build conflict resolution skills: case studies and examples, what is github uses and getting started, upskill with forage.

Build career skills recruiters are looking for.

15 Common Problem-Solving Interview Questions

In an interview for a big tech company, I was asked if I’d ever resolved a fight — and the exact way I went about handling it. I felt blindsided, and I stammered my way through an excuse of an answer.

It’s a familiar scenario to fellow technical job seekers — and one that risks leaving a sour taste in our mouths. As candidate experience becomes an increasingly critical component of the hiring process, recruiters need to ensure the problem-solving interview questions they prepare don’t dissuade talent in the first place. 

Interview questions designed to gauge a candidate’s problem-solving skills are more often than not challenging and vague. Assessing a multifaceted skill like problem solving is tricky — a good problem solver owns the full solution and result, researches well, solves creatively and takes action proactively. 

It’s hard to establish an effective way to measure such a skill. But it’s not impossible.

We recommend taking an informed and prepared approach to testing candidates’ problem-solving skills . With that in mind, here’s a list of a few common problem-solving interview questions, the science behind them — and how you can go about administering your own problem-solving questions with the unique challenges of your organization in mind.

Key Takeaways for Effective Problem-Solving Interview Questions

• Problem solving lies at the heart of programming. 
• Testing a candidate’s problem-solving skills goes beyond the IDE. Problem-solving interview questions should test both technical skills and soft skills.
• STAR, SOAR and PREP are methods a candidate can use to answer some non-technical problem-solving interview questions.
• Generic problem-solving interview questions go a long way in gauging a candidate’s fit. But you can go one step further by customizing them according to your company’s service, product, vision, and culture. 

Technical Problem-Solving Interview Question Examples

Evaluating a candidates’ problem-solving skills while using coding challenges might seem intimidating. The secret is that coding challenges test many things at the same time — like the candidate’s knowledge of data structures and algorithms, clean code practices, and proficiency in specific programming languages, to name a few examples.

Problem solving itself might at first seem like it’s taking a back seat. But technical problem solving lies at the heart of programming, and most coding questions are designed to test a candidate’s problem-solving abilities.

Here are a few examples of technical problem-solving questions:

1. Mini-Max Sum  

This well-known challenge, which asks the interviewee to find the maximum and minimum sum among an array of given numbers, is based on a basic but important programming concept called sorting, as well as integer overflow. It tests the candidate’s observational skills, and the answer should elicit a logical, ad-hoc solution.

2. Organizing Containers of Balls  

This problem tests the candidate’s knowledge of a variety of programming concepts, like 2D arrays, sorting and iteration. Organizing colored balls in containers based on various conditions is a common question asked in competitive examinations and job interviews, because it’s an effective way to test multiple facets of a candidate’s problem-solving skills.

3. Build a Palindrome

This is a tough problem to crack, and the candidate’s knowledge of concepts like strings and dynamic programming plays a significant role in solving this challenge. This problem-solving example tests the candidate’s ability to think on their feet as well as their ability to write clean, optimized code.

4. Subarray Division

Based on a technique used for searching pairs in a sorted array ( called the “two pointers” technique ), this problem can be solved in just a few lines and judges the candidate’s ability to optimize (as well as basic mathematical skills).

5. The Grid Search 

This is a problem of moderate difficulty and tests the candidate’s knowledge of strings and searching algorithms, the latter of which is regularly tested in developer interviews across all levels.

Common Non-Technical Problem-Solving Interview Questions 

Testing a candidate’s problem-solving skills goes beyond the IDE . Everyday situations can help illustrate competency, so here are a few questions that focus on past experiences and hypothetical situations to help interviewers gauge problem-solving skills.

1. Given the problem of selecting a new tool to invest in, where and how would you begin this task? 

Key Insight : This question offers insight into the candidate’s research skills. Ideally, they would begin by identifying the problem, interviewing stakeholders, gathering insights from the team, and researching what tools exist to best solve for the team’s challenges and goals. 

2. Have you ever recognized a potential problem and addressed it before it occurred? 

Key Insight: Prevention is often better than cure. The ability to recognize a problem before it occurs takes intuition and an understanding of business needs. 

3. A teammate on a time-sensitive project confesses that he’s made a mistake, and it’s putting your team at risk of missing key deadlines. How would you respond?

Key Insight: Sometimes, all the preparation in the world still won’t stop a mishap. Thinking on your feet and managing stress are skills that this question attempts to unearth. Like any other skill, they can be cultivated through practice.

4. Tell me about a time you used a unique problem-solving approach. 

Key Insight: Creativity can manifest in many ways, including original or novel ways to tackle a problem. Methods like the 10X approach and reverse brainstorming are a couple of unique approaches to problem solving. 

5. Have you ever broken rules for the “greater good?” If yes, can you walk me through the situation?

Key Insight: “Ask for forgiveness, not for permission.” It’s unconventional, but in some situations, it may be the mindset needed to drive a solution to a problem.

6. Tell me about a weakness you overcame at work, and the approach you took. 

Key Insight: According to Compass Partnership , “self-awareness allows us to understand how and why we respond in certain situations, giving us the opportunity to take charge of these responses.” It’s easy to get overwhelmed when faced with a problem. Candidates showing high levels of self-awareness are positioned to handle it well.

7. Have you ever owned up to a mistake at work? Can you tell me about it?

Key Insight: Everybody makes mistakes. But owning up to them can be tough, especially at a workplace. Not only does it take courage, but it also requires honesty and a willingness to improve, all signs of 1) a reliable employee and 2) an effective problem solver.

8. How would you approach working with an upset customer?

Key Insight: With the rise of empathy-driven development and more companies choosing to bridge the gap between users and engineers, today’s tech teams speak directly with customers more frequently than ever before. This question brings to light the candidate’s interpersonal skills in a client-facing environment.

9. Have you ever had to solve a problem on your own, but needed to ask for additional help? How did you go about it? 

Key Insight: Knowing when you need assistance to complete a task or address a situation is an important quality to have while problem solving. This questions helps the interviewer get a sense of the candidate’s ability to navigate those waters. 

10. Let’s say you disagree with your colleague on how to move forward with a project. How would you go about resolving the disagreement?

Key Insight: Conflict resolution is an extremely handy skill for any employee to have; an ideal answer to this question might contain a brief explanation of the conflict or situation, the role played by the candidate and the steps taken by them to arrive at a positive resolution or outcome. 

Strategies for Answering Problem-Solving Questions

If you’re a job seeker, chances are you’ll encounter this style of question in your various interview experiences. While problem-solving interview questions may appear simple, they can be easy to fumble — leaving the interviewer without a clear solution or outcome. 

It’s important to approach such questions in a structured manner. Here are a few tried-and-true methods to employ in your next problem-solving interview.

1. Shine in Interviews With the STAR Method

S ituation, T ask, A ction, and R esult is a great method that can be employed to answer a problem-solving or behavioral interview question. Here’s a breakdown of these steps:

• Situation : A good way to address almost any interview question is to lay out and define the situation and circumstances. 
• Task : Define the problem or goal that needs to be addressed. Coding questions are often multifaceted, so this step is particularly important when answering technical problem-solving questions.
• Action : How did you go about solving the problem? Try to be as specific as possible, and state your plan in steps if you can.
• Result : Wrap it up by stating the outcome achieved. 

2. Rise above difficult questions using the SOAR method

A very similar approach to the STAR method, SOAR stands for S ituation, O bstacle, A ction, and R esults .

• Situation: Explain the state of affairs. It’s important to steer clear of stating any personal opinions in this step; focus on the facts.
• Obstacle: State the challenge or problem you faced.
• Action: Detail carefully how you went about overcoming this obstacle.
• Result: What was the end result? Apart from overcoming the obstacle, did you achieve anything else? What did you learn in the process? 

3. Do It the PREP Way

Traditionally used as a method to make effective presentations, the P oint, R eason, E xample, P oint method can also be used to answer problem-solving interview questions.  

• Point : State the solution in plain terms. 
• Reasons: Follow up the solution by detailing your case — and include any data or insights that support your solution. 
• Example: In addition to objective data and insights, drive your answer home by contextualizing the solution in a real-world example.
• Point : Reiterate the solution to make it come full circle.

How to Customize Problem-Solving Interview Questions 

Generic problem-solving interview questions go a long way in gauging a candidate’s skill level, but recruiters can go one step further by customizing these problem-solving questions according to their company’s service, product, vision, or culture. 

Here are some tips to do so:

• Break down the job’s responsibilities into smaller tasks. Job descriptions may contain ambiguous responsibilities like “manage team projects effectively.” To formulate an effective problem-solving question, envision what this task might look like in a real-world context and develop a question around it.  
• Tailor questions to the role at hand. Apart from making for an effective problem-solving question, it gives the candidate the impression you’re an informed technical recruiter. For example, an engineer will likely have attended many scrums. So, a good question to ask is: “Suppose you notice your scrums are turning unproductive. How would you go about addressing this?” 
• Consider the tools and technologies the candidate will use on the job. For example, if Jira is the primary project management tool, a good problem-solving interview question might be: “Can you tell me about a time you simplified a complex workflow — and the tools you used to do so?”
• If you don’t know where to start, your company’s core values can often provide direction. If one of the core values is “ownership,” for example, consider asking a question like: “Can you walk us through a project you owned from start to finish?” 
• Sometimes, developing custom content can be difficult even with all these tips considered. Our platform has a vast selection of problem-solving examples that are designed to help recruiters ask the right questions to help nail their next technical interview.

Get started with HackerRank

Over 2,500 companies and 40% of developers worldwide use HackerRank to hire tech talent and sharpen their skills.

• Skip to main content
• Skip to primary sidebar
• Skip to footer

Additional menu

The 5 steps of the solving problem process

August 17, 2023 by MindManager Blog

Whether you run a business, manage a team, or work in an industry where change is the norm, it may feel like something is always going wrong. Thankfully, becoming proficient in the problem solving process can alleviate a great deal of the stress that business issues can create.

Understanding the right way to solve problems not only takes the guesswork out of how to deal with difficult, unexpected, or complex situations, it can lead to more effective long-term solutions.

In this article, we’ll walk you through the 5 steps of problem solving, and help you explore a few examples of problem solving scenarios where you can see the problem solving process in action before putting it to work.

Understanding the problem solving process

When something isn’t working, it’s important to understand what’s at the root of the problem so you can fix it and prevent it from happening again. That’s why resolving difficult or complex issues works best when you apply proven business problem solving tools and techniques – from soft skills, to software.

The problem solving process typically includes:

• Pinpointing what’s broken by gathering data and consulting with team members.
• Figuring out why it’s not working by mapping out and troubleshooting the problem.
• Deciding on the most effective way to fix it by brainstorming and then implementing a solution.

While skills like active listening, collaboration, and leadership play an important role in problem solving, tools like visual mapping software make it easier to define and share problem solving objectives, play out various solutions, and even put the best fit to work.

Before you can take your first step toward solving a problem, you need to have a clear idea of what the issue is and the outcome you want to achieve by resolving it.

For example, if your company currently manufactures 50 widgets a day, but you’ve started processing orders for 75 widgets a day, you could simply say you have a production deficit.

However, the problem solving process will prove far more valuable if you define the start and end point by clarifying that production is running short by 25 widgets a day, and you need to increase daily production by 50%.

Once you know where you’re at and where you need to end up, these five steps will take you from Point A to Point B:

• Figure out what’s causing the problem . You may need to gather knowledge and evaluate input from different documents, departments, and personnel to isolate the factors that are contributing to your problem. Knowledge visualization software like MindManager can help.
• Come up with a few viable solutions . Since hitting on exactly the right solution – right away – can be tough, brainstorming with your team and mapping out various scenarios is the best way to move forward. If your first strategy doesn’t pan out, you’ll have others on tap you can turn to.
• Choose the best option . Decision-making skills, and software that lets you lay out process relationships, priorities, and criteria, are invaluable for selecting the most promising solution. Whether it’s you or someone higher up making that choice, it should include weighing costs, time commitments, and any implementation hurdles.
• Put your chosen solution to work . Before implementing your fix of choice, you should make key personnel aware of changes that might affect their daily workflow, and set up benchmarks that will make it easy to see if your solution is working.
• Evaluate your outcome . Now comes the moment of truth: did the solution you implemented solve your problem? Do your benchmarks show you achieved the outcome you wanted? If so, congratulations! If not, you’ll need to tweak your solution to meet your problem solving goal.

In practice, you might not hit a home-run with every solution you execute. But the beauty of a repeatable process like problem solving is that you can carry out steps 4 and 5 again by drawing from the brainstorm options you documented during step 2.

Examples of problem solving scenarios

The best way to get a sense of how the problem solving process works before you try it for yourself is to work through some simple scenarios.

Here are three examples of how you can apply business problem solving techniques to common workplace challenges.

Scenario #1: Manufacturing

Building on our original manufacturing example, you determine that your company is consistently short producing 25 widgets a day and needs to increase daily production by 50%.

Since you’d like to gather data and input from both your manufacturing and sales order departments, you schedule a brainstorming session to discover the root cause of the shortage.

After examining four key production areas – machines, materials, methods, and management – you determine the cause of the problem: the material used to manufacture your widgets can only be fed into your equipment once the machinery warms up to a specific temperature for the day.

Your team comes up with three possible solutions.

• Leave your machinery running 24 hours so it’s always at temperature.
• Invest in equipment that heats up faster.
• Find an alternate material for your widgets.

After weighing the expense of the first two solutions, and conducting some online research, you decide that switching to a comparable but less expensive material that can be worked at a lower temperature is your best option.

You implement your plan, monitor your widget quality and output over the following week, and declare your solution a success when daily production increases by 100%.

Scenario #2: Service Delivery

Business training is booming and you’ve had to onboard new staff over the past month. Now you learn that several clients have expressed concern about the quality of your recent training sessions.

After speaking with both clients and staff, you discover there are actually two distinct factors contributing to your quality problem:

• The additional conference room you’ve leased to accommodate your expanding training sessions has terrible acoustics
• The AV equipment you’ve purchased to accommodate your expanding workforce is on back-order – and your new hires have been making do without

You could look for a new conference room or re-schedule upcoming training sessions until after your new equipment arrives. But your team collaboratively determines that the best way to mitigate both issues at once is by temporarily renting the high-quality sound and visual system they need.

Using benchmarks that include several weeks of feedback from session attendees, and random session spot-checks you conduct personally, you conclude the solution has worked.

Scenario #3: Marketing

You’ve invested heavily in product marketing, but still can’t meet your sales goals. Specifically, you missed your revenue target by 30% last year and would like to meet that same target this year.

After collecting and examining reams of information from your sales and accounting departments, you sit down with your marketing team to figure out what’s hindering your success in the marketplace.

Determining that your product isn’t competitively priced, you map out two viable solutions.

• Hire a third-party specialist to conduct a detailed market analysis.
• Drop the price of your product to undercut competitors.

Since you’re in a hurry for results, you decide to immediately reduce the price of your product and market it accordingly.

When revenue figures for the following quarter show sales have declined even further – and marketing surveys show potential customers are doubting the quality of your product – you revert back to your original pricing, revisit your problem solving process, and implement the market analysis solution instead.

With the valuable information you gain, you finally arrive at just the right product price for your target market and sales begin to pick up. Although you miss your revenue target again this year, you meet it by the second quarter of the following year.

Kickstart your collaborative brainstorming sessions and  try MindManager for free today !

Ready to take the next step?

MindManager helps boost collaboration and productivity among remote and hybrid teams to achieve better results, faster.

Why choose MindManager?

MindManager® helps individuals, teams, and enterprises bring greater clarity and structure to plans, projects, and processes. It provides visual productivity tools and mind mapping software to help take you and your organization to where you want to be.

Explore MindManager

Advertisement

Technological problem solving: an investigation of differences associated with levels of task success

• Open access
• Published: 02 June 2021
• Volume 32 , pages 1725–1753, ( 2022 )

Cite this article

You have full access to this open access article

• David Morrison-Love   ORCID: orcid.org/0000-0002-9009-4738 1  

9072 Accesses

Explore all metrics

Research into technological problem solving has shown it to exist in a range of forms and draw upon different processes and knowledge types. This paper adds to this understanding by identifying procedural and epistemic differences in relation to task performance for pupils solving a well-defined technological problem. The study is theoretically grounded in a transformative epistemology of technology education. 50 pupils in small groups worked through a cantilever problem, the most and least successful solutions to which were identified using a Delphi technique. Time-interval photography, verbal interactions, observations and supplementary data formed a composite representation of activity which was analysed with successively less contrasting groups to isolate sustained differences. Analyses revealed key differences in three areas. First, more successful groups used better and more proactive process-management strategies including use of planning, role and task allocation with lower levels of group tension. Second, they made greater use of reflection in which knowledge associated with the technological solution was explicitly verblised. This was defined as ‘analytical reflection’ and reveals aspects of pupils’ qualitative technical knowledge. Third, higher-performing groups exhibited greater levels of tacit-procedural knowledge within their solutions. There was also evidence that less successful groups were less affected by competition and not as comprehensive in translating prior conceptual learning into their tangible technological solutions. Overall findings suggest that proactive management, and making contextual and technical connections, are important for pupils solving well-defined technological problems. This understanding can be used to support classroom pedagogies that help pupils learn to problem solve more effectively.

Similar content being viewed by others

Investigating Preservice Teachers’ Educational Technology Skills: A Problem-Solving Process

Problem-Based Learning in Technology Education

Explore related subjects

• Artificial Intelligence
• Digital Education and Educational Technology

Avoid common mistakes on your manuscript.

Introduction

Problem solving is an activity, a context and a dominant pedagogical frame for Technology Education. It constitutes a central method and a critical skill through which school pupils learn about and become proficient in technology (Custer et al., 2001 ). Research has, among other things, been able to identify and investigate sets of intellectual and cognitive processes (Buckley et al., 2019 ; Haupt, 2018 ; Johnson, 1997 ; Sung & Kelly, 2019 ) and shown there to be conceptual, procedural, relational and harder-to-get-to forms of ‘technological knowledge’ involved when pupils develop technological solutions (de Vries, 2005 ; McCormick, 1997 , 2004 ; Rauscher, 2011 ). Some authors argue that technological problem solving (and design) is a situated activity (Jackson & Strimel, 2018 ; Murphy & McCormick, 1997 ; Liddament, 1996 ), but with social and context-independent processes also playing an important role (e.g. Jones, 1997 ; Winkelmann & Hacker, 2011 ). Within and across this vista, there has been strong interest in more open-ended, creative and design-based problem-solving (Lewis, 2005 , 2009 ), which Xu et al. ( 2019 ) notes became particularly prominent after 2006. These studies have helped to understand some of the challenges and pedagogies of design (Gómez Puente et al., 2013 ; Lavonen et al., 2002 ; Mioduser & Dagan, 2007 ; Mawson, 2003 ) including those that mitigate effects such as cognitive fixation (e.g. McLellan & Nicholl, 2011 ). Problem solving, it seems, is a pervasive idea in technology education research and policy. Middleton ( 2009 ) notes that problem solving is found in almost all international technology education curricula.

The pace, nature and complexity of contemporary societal challenges make it more critical than ever that technology classrooms prepare people who can think through and respond to technological problems effectively. It requires that we strengthen our understanding in ways that will ultimately be powerful for shaping classroom learning. One way of contributing to this is to learn more about the differences between learners who are more and less successful at technological problem solving. Studies that share a comparative perspective and/or a focus upon task success are relatively few. Doornekamp ( 2001 ) compared pupils (circa 13 years old) who solved technological problems using weakly structured instructional materials with those using strongly structured materials. It was shown that the latter led to statistically significant improvements in the quality of the technical solutions. More recently, Bartholomew & Strimel ( 2018 ) were able to show that, for open-ended problem solving, there was no significant relationship between prior experience and folio creation, but that more in-school school experience of open-ended problem solving corresponded to higher ranked solutions.

This paper contributes to this work by reporting on a study that compares groups of pupils during technological problem solving in order to identify areas of difference and the factors associated with more successful outcomes. Specifically, it addresses the question: ‘In terms of intellectual processes and knowledge, what are the differences in the modi operandi between groups of pupils that produced more and less successful technological solutions to a well-defined problem?’ Theoretically grounded in a transformative epistemology of technology education (Morrison-Love, 2017 ), the study identifies prominent procedural and epistemic differences in pupils’ thinking and technical solutions. Groups of pupils engaged with a structures problem requiring them to develop a cantilever bridge system which would facilitate safe travel across a body of water.

The paper begins by setting out the theoretical basis and conceptual framework for investigation before describing the comparative methodological and analytical approaches that were adopted. Following an analysis and presentation of key findings, conclusion and implications are discussed.

A theoretical basis for the study of technological problem solving

Despite there being no single comprehensive paradigm for technological problem solving, a theoretical grounding and conceptual framework necessary for this study are presented. At the theoretical level, this study is based upon a ‘transformative epistemology’ for technology education (Morrison-Love, 2017 ). From this, a ternary conceptual framework based upon mode, epistemology and process is developed to support study design and initiate data analysis.

A transformative epistemology for technology education (Morrison-Love, ibid) proposes that pupils’ technological knowledge and capability arises from the ontological transformation of their technical solution from ‘perdurant’ (more conceptual, mutable, less well-defined, partial) in the early stages, to ‘endurant’ (comprehensive, tangible, stable over time) upon completion. It proposes that technical outcomes exist in material and tangible forms and that to be technological (rather than, for example, social, cultural or aesthetic) these must somehow enhance human capabilities in their intended systems of use. For this study, the ideas of transformative epistemology support problem solving in which pupils build technological knowledge by iteratively moving from concept to tangible, material solution. Moreover, it means pupils are successful in this when their solutions or prototypes: (1) enhance existing human capabilities in some way, and (2) are sufficiently developed to be stable over time, beyond the problem-solving activity that created it.

A conceptual framework for technological problem solving

A ternary conceptual framework (Fig. 1 ) of mode, process and epistemology was developed from the literature in which the knowledge and cognitive/intellectual processes used by pupils are enacted in the ‘process application block’. This is like the ‘problem space’ described in a model proposed by Mioduser ( 1998 ). Collectively, the goal of creating a physical artefact, the solution itself, the epistemic and procedural dimensions reflect the four dimensions of technology identified by Custer ( 1995 ).

‘A conceptual framework for technological problem solving’

Mode and forms dimension

Although problem solving may be ‘technological’, several classifications of both problem type and problem solving are found in the literature. Ill-defined and well-defined problems build upon the earlier work of information processing and cognitive psychology (see Jonassen, 1997 ). Typically, these two forms reflect different extents to which the outcome is specified to the solver at the outset. Ill-defined problems are strongly associated with design and creativity, and Twyford and Järvinen ( 2000 ) suggest that these more open briefs promote greater social interaction and use by pupils of prior knowledge and experience. Additionally, two forms of troubleshooting were identified in the literature: emergent troubleshooting and discrete troubleshooting. MacPherson ( 1998 ) argues that ‘troubleshooting’ constitutes a particular subset of technological problem solving—something earlier recognised by McCade ( 1990 ), who views it as the identification and overcoming of problems encountered during the production or use of a technical solution. In this study, emergent troubleshooting occurs in the process of developing solutions in response to emergent problems (McCormick, 1994 ). Discrete troubleshooting is a process in which significant technical understanding is applied in a structured way (Schaafstal et al., 2000 ) to resolve something about an existing artefact.

Intellectual and cognitive process dimension

Studies often conceptualise cognitive processes discretely rather than hierarchically, and different studies employ different process sets. Williams ( 2000 ), identifies evaluation, communication, modelling, generating ideas, research and investigation, producing and documenting as important to technological problem solving, while DeLuca ( 1991 ) identifies troubleshooting, the scientific process, the design process, research and development, and project management. There are also studies that employ specific, or more established, coding schemes for sets of intellectual and cognitive processes. A detailed analysis of these is given Grubbs et al. ( 2018 ), although the extent to which a particular process remains discrete or could form a sub-process of another remains problematic. In DeLuca’s ( 1991 ) break down for example, to what extent are research and investigation part of design and does this depend on the scale at which we conceptualise different processes?

Regardless of the processes a study defines, it is typically understood that pupils apply them in iterative or cyclic fashion. This is reflected across several models from Argyle’s ( 1972 ) ‘Motor Skill Process Model’ (perception-translation-motor response) through to those of Miodusre and Kipperman ( 2002 ) and Scrivener et al. ( 2002 ) (evaluation-modification cycles) which pertain specifically to technology education. All these models bridge pupils’ conceptual-internal representations with their practical-external representations as they move towards an ontologically endurant solution and this is captured by the ‘Re-Application/Transformation Loop’ of the conceptual framework. Given that little is known about where differences might lie, the process set identified by Halfin ( 1973 ) was adopted due to its rigour and the breadth of thinking it encompasses. This set was validated for technology classrooms by Hill and Wicklein ( 1999 ) and used successfully by other studies of pupils technological thinking including Hill ( 1997 ), Kelley ( 2008 ) and Strimel ( 2014 ).

Epistemology dimension

The nature and sources of knowledge play a critical role for pupils when solving technological problems, but these remain far from straightforward to conceptualise. McCormick ( 1997 ) observes that the activity of technology education, and its body of content, can be thought of as ‘procedural knowledge’ and ‘conceptual knowledge’ respectively. Vincenti ( 1990 ), in the context of Engineering, makes the case for descriptive knowledge (things as they currently are) and prescriptive knowledge (of that with is required to meet a desired state) but also recognises knowledge can take on implicit, or tacit forms relating to an individual’s skill, judgement, and practice (Polanyi, 1967 ; Schön, 1992 ; Sternberg, 1999 ; Welch, 1998 ). Arguably, moving from concept to physical solution will demand from pupils a certain level of practical skill and judgement, and Morgan ( 2008 ) observes that procedural knowledge which is explicit in the early stages becomes increasingly implicit with mastery. Notably, in addition to conceptual, procedural and tacit forms of knowledge, there is also evidence that knowledge of principles plays a role. Distinct from impoverished notions of technology as ‘applied science’, Rophol ( 1997 ) shows that it is often technological principles, laws and maxims that are applied during problem solving rather than scientific ones. Frey ( 1989 ) makes similar observations and sees this form of knowledge arising largely from practice. In this study, knowledge of principles involves knowledge of a relationship between things. It is not constrained to those that are represented scientifically.

The conceptual framework finally accounts for pupils’ sources of knowledge during problem solving, building principally on a design knowledge framework of media, community and domain presented by Erkip et al. ( 1997 ). In this study, media includes task information, representations and materials; community includes teachers and peers, and domain relates to prior technological knowledge from within technology lessons and prior personal knowledge from out with technology lessons. Finally, the developing solution is itself recognised a source of knowledge that pupils iteratively engage with and reflect upon, even when it appears that limited progress in being made (Hamel & Elshout, 2000 ).

Methodology

The research question in this study is concerned with differences in the knowledge and intellectual processes used by pupils in moving from a perdurant to an endurant technical solution. From an exploratory stance, this elicits a dualistic activity system involving pupils’ subjective constructions of reality as well as the resultant tangible and more objective material solution. The study does not aim to investigate pupils’ own subjective constructions from an emic perspective, but rather seeks to determine the nature and occurrences of any differences during observable real-time problem-solving activity. As such, content rather than thematic analysis was used (Elo & Kyngäs, 2008 ; Vaismoradi et al., 2013 ) with concurrent data collection to build a composite representation of reality (Gall et al., 2003 , p.14). Complementary data provided insights into study effects, the classrooms and contexts within which problem-solving took place.

This study assumes that should differences exist, these will be discernible in the inferred cognitive processes, external material transformations, interactions and verbalisation (even though this tends to diminish as activity becomes more practical). Absolute and objective observation is not possible. This study also accepts that data gathering and analysis are influenced by theory, researcher fallibility and bias which will be explicitly accounted for as far as possible. Finally, while the conceptual framework provides an analytical starting point, it should not preclude the capture of differences that may lie elsewhere in the data including, for example, process that lie out with those identified by Halfin ( 1973 ).

Participants, selection and grouping

To support transferability, a representative spread of pupils from low, medium and high socio-economic backgrounds took part in this study. Purposeful, four-stage criterion sampling was used (Gall et al., 2003 , p.179). Stage one identified six schools at each socio-economic level from all Scottish secondary schools that presented pupils for one or more technology subjects with the Scottish Qualifications Authority. This was done using socio-economic data from the Scottish Area Deprivation Index, the Carstairs Index and pupil eligibility for subsidised meals. Secondary school catchment areas were used to account for pupil demographics as accurately as possible. All eighteen schools were subsequently ranked with one median drawn from low, medium and high bands of socio-economic deprivation (School 1: Low, School 2: Medium, School 3: High).

One class in each school was then selected from the second year of study prior to pupils making specific subject choices to minimise variations in curricular experience. In total, 3 class teachers and 50 pupils (20 female, 30 male) aged between 12 and 13 years old took part in the study. The group rather than the individual was defined as unit of study to centralise verbal interaction.

None of the pupils participating in this study had experience of group approaches such as co-operative learning and it was likely that groups might experience participation effects including inter-group conflict and interaction effects (Harkins, 1987 ; Sherif et al., 1961 ), social loafing (Salomon & Globerson, 1989 ), free-rider (Strong & Anderson, 1990 ) and status differential effects (Rowell, 2002 ). Relevant also to this study is evidence suggesting that gender effects can take place in untrained groups undertaking practical/material manipulation activities. To maximise interaction between group members and the material solution, thirteen single sex groups averaging four pupils were formed in order to: (1) minimise the marginalisation of girls with boys’ tendency to monopolise materials and apparatus in groups (Conwell et al., 1993 ; Whyte, 1984 ); (2) recognise boys’ tendency to respond more readily to other boys (Webb, 1984 ) and, (3) maximise girls’ opportunities to interact which is seen to erode in mixed groups (Parker & Rennie, 2002 ; Rennie & Parker, 1987 ). Hong et al. ( 2012 ) examines such gender differences in detail specifically within the context of technological problem solving. Teacher participation in group allocation minimised inter-group conflict and interaction effects although groups still experienced naturally fluctuating attrition from pupil absences (School 1 = 17.6%; School 2 = 2.5% and School 3 = 8.8%).

Identification of most and least successful solutions

The research question requires differences to be identified in terms of levels of success. The overall trustworthiness of any differences therefore depends upon the credible identification of the most and least successful solutions from the thirteen produced. Wholly objective assessment of the pupils’ solutions is not possible, and material imperfections in different solutions negated reliable physical testing across the three classes. Moreover, because the researcher earlier observed pupils while problem solving, neutrality of researcher judgement in establishing a rank order of group solutions was equally problematic. Everton and Green ( 1986 ) identify this biasing risk between and early and later stages of research as a form of contamination.

To address these limitations, a Delphi technique was design using the work of Gordon ( 1994 ), Rowe and Wright ( 1999 ) and Yousuf ( 2007 ). This was undertaken anonymously prior to any analysis and, in conjunction with the results of physical testing, enabled the four most successful and four least successful solutions to be confidently identified independently of the researcher. A panel of eight secondary school teachers was convened from schools out with the study. All panel members had expertise in teaching structures with no dependent relationships or conflicts of interest. Following Delphi training, and a threshold level of 75%, the four most and four least successful solutions on outcome alone were identified after two rounds. Qualitative content validity checks confirmed that panel judgements fell within the scope of the accessible information. 37/43 reasons given were ‘High’, with six considered ‘Medium’ because the reasoning was partially speculative. When triangulated with additional evidence from physical testing, two cohorts of four groups were identified and paired to form four dyads (Table 1 ).

Study design

As noted, ‘Structures’ was chosen as a topic area and was new to all participants. It was appropriate for setting well-defined problems and allowed pupils to draw upon a sufficiently wide range of processes and knowledge types in developing a tangible, endurant solution. In discussion with the researcher, teachers did not alter their teaching style and adopted pedagogy and formative interactions that would support independent thinking, reasoning and problem solving. This study involved a learning phase, followed by a problem-solving phase.

In the learning phase, groups engaged over three fifty-minute periods with a unit of work on structures which was developed collaboratively with, and delivered by, the three classroom teachers. This allowed pupils to interact with materials and develop a qualitative understanding of key structural concepts including strength, tension and compression, triangulation, and turning moments. During this time, pupils also acclimatised to the presence of the researcher and recording equipment which helped to reduce any potential Hawthorne effect (Gall et al., 2003 ). Structured observations, teacher de-briefs and questionnaires were used in this phase to capture study effects, unit content coverage and environmental consistency between the three classrooms. Content coverage and environmental consistency were shown to be extremely high. Scores from the unit activity sheets that pupils completed were used to gauge group understanding of key concepts.

The problem-solving phase took place over two circa 50-minute periods (range: 40–52 m) in which pupils responded to a well-defined problem brief. This required them to develop a cantilever bridge enabling travel across a body of water. This bridge would enhance people’s ability to traverse terrain (conditions for being ‘technological’) with maximal span rigidity and minimal deflection (conditions for an ontologically ‘endurant’ solution). All groups had access to the same range and number of materials and resources and were issued with a base board showing water and land on which to develop their solutions.

While video capture was explored in depth (Lomax & Casey, 1998 ), challenges in reliably capturing solution detail resulted in group verbalisation being recorded as audio. This was synchronised with time interval photography and supplemented with structured observer-participant observation that focused on a sub-set of observable processes from the conceptual framework (Halfin, 1973 ). The developing technical solutions were viewed as manifestations of the knowledge and intellectual processes used by pupils at different points in time through their cognitive and material interactions. Photographs captured the results of these interactions in group solutions every 3–4 min but did not capture interactions between pupils. The structured observational approach adopted continuous coding similar to that found in the Flanders System of Interaction analysis (Amatari, 2015 ) and was refined through two pilot studies. During each problem-solving session, groups were observed at least twice between photographs and, following each session, pupil questionnaires, teacher de-briefs and solution videos (360° panoramic pivot about the solution) were completed to support future analysis. Reflexive accounts by the researcher also captured critical events, observer and study effects.

Analytical approach

All data were prepared, time-synchronised and analysed in three stages. Core verbal data (apx. 12h) and photographic data (n = 206) were triangulated with observational and other data against time. The problem-solving phase for each class was broken into a series of 3–4 min samples labelled S = 1, S = 2, S = 3…with durations in each recorded in minutes and seconds. Verbal data were analysed using NVivo software using digital waveforms rather than transcribed files to preserve immediacy, accuracy and minimise levels of interpretation (Wainwright & Russell, 2010 ; Zamawe, 2015 ). Photographic data were coded for the physical developments of the solutions (e.g. adding/removing materials in particular places) allowing solution development to be mapped for different groups over time. Triangulation of data also allowed coding to capture whether individual developments enhanced or detracted from the overall function efficacy of the solution.

The first stage of analysis was immersive, beginning with an initial codebook derived from the conceptual framework. In response to the data this iteratively shifted to a more inductive mode. To sensitise the analysis to differences, the most successful and the least successful groups were compared first as is discussed by Strauss 1987 (Miles & Huberman, 1994 , p.58). Three frameworks of differences emerged from this: (1) epistemic differences, (2) process differences, and (3) social and extrinsic differences. These were then applied to dyads of decreasing contrast and successively  refined in response to how these differences were reflected in the wider data set. Seven complete passes allowed non-profitable codes to be omitted and frameworks to be finalised. A final stage summarised differences across all groups.

Analysis and findings

The analysis and findings are presented in two main parts: (1) findings from the learning phase, and (2) findings from the problem-solving phase. Verbal data forms a core data source throughout and coding includes both counts and durations (in minutes and seconds). Direct quotations are used from verbal data, although the pupils involved in the study were from regions of Scotland with differing and often very strong local dialects. Quotations are therefore presented with dialect effects removed:

Example data excerpt reflecting dialect: “See instead-e all-e-us watchin’, we could all be doin’ su-hum instead-o watchin’ Leanne..” Example data excerpt with dialect removed: “See instead of all of us watching, we could all be doing something instead of watching Leanne..”

Part 1: Findings from the Learning Phase

Both teacher and researcher observation confirmed that pupils in all three classes engaged well with the unit of work (50 pupils across 13 groups) with all 40 content indicators covered by each class. Teachers of classes 1 and 3 commented that the lesson pace was slightly faster than pupils were used to. As expected, different teaching styles and examples were between classes, but all pupils completed the same unit activity sheets. The teacher of class 2, for example, used man-made structures and insect wings to explore triangulation; and the teacher in class 3 talked about the improved stability pupils get by standing with their feet apart. The understanding reflected in activity sheets was very good overall and Table 2 illustrates the percentage of correct responses for each class in relation to each of the three core concept areas.

Though unit activity sheets are not standardised tests, the conditions of administration, scoring, standards for interpretation, fairness and concept validity discussed by Gall et al. ( 2003 , p.xx) were maintained as far as possible. Evidence did not show that representational/stylistic variations by teachers had any discernible effect on pupil understanding and was seen to maintain normality from the pupils’ perspective. Class 3 scored consistently highly across all conceptual areas, although the qualitative understanding of turning moments was least secure for all three classes. Non-completion of selected questions in the task sheets partially explains lower numerical attainment for this concept in class 1 and 2, however, it is unknown if omissions resulted from a lack of understanding. The figures in Table 2 are absence corrected to account for fluctuating pupil attendance at sessions: (17.6% pupil absence across sessions for class 1, compared with 8.8% and 2.5% for classes 3 and 3 respectively). Table 3 illustrates the percentage scores for activity sheets completed by groups in the more and less successful cohorts.

Observational and reflexive data highlighted evidence of some researcher and recorder effects. These were typically associated with pupils’ interest in understanding the roles of the researcher and class teacher, and discussion around what they could say while being recorded. These subsided over time for all but two groups in Class 1, but with no substantive effect on pupils’ technological thinking.

In summary, findings from the learning phase show that: (1) Pupils engagement was high, and all classes covered the core structural concepts in the unit; (2) pupil knowledge and understanding, as measured by activity sheet responses, was very good overall but scores for turning moments were comparatively lower, and (3) study effect subsided quite quickly for all but two groups and there was no evidence showing these to be detrimental to technological thinking. These differences are considered epistemic and are captured in the framework of difference in Fig. 5 .

Part 2: findings from the problem-solving phase

Part 2 begins by describing the differences from comparing the material solutions produced by the most and least successful groups (dyad 1). Subsequent sections report upon the three areas in which difference were found: epistemic differences, process differences and social and extrinsic differences. Each of these sections lead with the analysis from the most contrasting groups (dyad 1) before presenting the resultant framework of difference. They conclude by reporting on how the differences in these frameworks are reflected across the wider data set. As with findings across all sections, findings only account for areas of the conceptual framework in which differences were identified. For processes such as measuring and testing, no difference was found and other processes, such as computing, did not feature for any of the groups.

Differences in the solutions produced by the most & least successful groups (dyad 1)

Group 5′s solution was identified as the most successful and Group7′s solution was identified as the least successful. Overall, both of these groups engaged well with the task and produced cantilevers that are shown in Figs. 2 and 3 . The order in which different parts of the solutions were developed is indicated by colour with the lighter parts appearing earlier in problem solving than the darker parts. Figure 4 shows this cumulative physical development of each solution over time. Both groups shared a similar conceptual basis and employed triangulation above and below the road surface. Figure 4 shows that Group 5′s solution evolved through 36 developments, while Group 7 undertook 23 developments and chose to strip down and restart their solution at the beginning of the second problem solving session. Similarly, groups 6, 11 and 13 removed or rebuilt significant sections of their solution. Neither group 5 or 7 undertook any developments under the rear of the road surface, and the greatest percentage of developments applied to the road surface itself (Group 7: 30.6%; Group 5: 47.8%). For Group 5, it was only developments 5 and 6 (Fig. 2 ) which offered little to no functional structural advantage. All other developments contributed to either triangulation, rigidity or strength through configuration and material choice with no evidence of misconception, which was also noted by the Delphi panel. The orientation, configuration and choice of materials by Group 7 share similarities with Group 5 insofar as each reflected knowledge of a cognate concept or principle (e.g. triangulation). Delphi Panel Member 8 described Group 7′s solution as having a good conceptual basis. Key differences, however, lay in the overall structural integrity of the solution and the underdevelopment of the road surface (Fig. 3 , Dev.1 and Dev.5) which mean that Group 5 achieved a more ontologically endurant solution than Group 7 did. Evidence from Group 7′s discussion (S = 3, 3.34–3.37; S = 3, 3.38–3.39; S = 16, 3.26–3.30) suggests this is partly because of misconception and deficits in knowledge about materials and the task/cantilever requirements. This was also reflected in the group’s activity responses during structures unit in the learning phase. Alongside the photographic evidence and reflexive notes of the researcher, this suggest that there was  some difficultly in translating concepts and ideas into a practical form. This constitutes a difference in tacit-procedural knowledge between Group 5 and Group 7.

‘Group 5 solution schematic’

‘Group 7 solution schematic’

‘Cumulative development of tangible solutions’

Epistemic differences during problem solving

As well as the knowledge differences in the learning phase and the physical solutions, analysis of the most and least successful groups revealed epistemic differences in problem solving activity related to ‘task knowledge’ and ‘knowledge of concepts and principles’. The extent to which ‘knowledge’ can be reliably coded for in this context is limited because it rapidly becomes inseparable from process. Skills are processes which, in turn, are forms of enacted knowledge. Consequently, although Halfin ( 1973 ) defines idea generation as a knowledge generating process using all the senses, attempts to code for this were unsuccessful because it was not possible to ascertain with any confidence where one idea ended, and another began. Coding was possible, however, for ‘prior personal knowledge’, ‘task knowledge’ and ‘prior technological knowledge’. The analysis of these is present along with the resulting framework of epistemic difference with prior personal knowledge omitted on the basis that no differences between groups was found. The final section looks at how epistemic differences are reflected in the activity of the remaining groups.

Epistemic differences between the most & least successful groups (dyad 1)

Task knowledge is the knowledge pupils have of the problem statement and includes relatively objective parameters, conditions, and constraints. One key difference was the extent to which groups explicitly used this to support decision making. Group 5 spent considerably more time than Group 7 discussing what they knew and understood of the task prior to construction (1m10s vs. 8 s) but during construction, had more instances where their knowledge of the task appeared uncertain or was questioned (n = 6 for Group 5 vs. n = 2 for Group 7). Differences were also found in the prior technological knowledge used by groups. This knowledge includes core structural concepts and principles explored in the learning phase. As with task knowledge, Group 5 verbalised this category of knowledge to a far greater extent than Group 7, both apart from, and as part of, formative discussions with the class teacher (18:59 s vs. 14:43 s). In only one instance was the prior technological knowledge of Group 5 incorrect or uncertain compared with four instances for Group 7. These included misconceptions about triangulation and strength despite performing well with these in the learning phase. Furthermore, some instances of erroneous knowledge impacted directly upon solution development. In response to a discussion about rigidity and the physical performance of the road surface, one pupil stated: “Yes, but it is supposed to be able to bend in the middle..” (Group 7, S = 3, 3.34–3.37) meaning that the group did not sufficient attend to this point of structural weakness which resulted in a less endurant solution. No such occurrences took place with Group 5. More prominent and accurate use of this type of knowledge supports stronger application of learning into the problem-solving context and appeared to accompany greater solution integrity.

From these findings, and those from the learning phase, the framework of difference shown in Fig. 5 was developed:

‘Framework of epistemic differences from comparative analysis of Group 5 and 7’

Epistemic differences across all groups (dyads 1–4)

As with dyad 1, the more successful groups in dyads 3 and 4 scored higher (+ 14% and + 20.7%, respectively) in the learning phase compared with their less successful partner groups. This, however, was not seen with dyad 2. The less successful group achieved a higher average score of 86.3% compared with 71% and, despite greater fluctuations in pupil attendance, scored 100% for turning moments compared with 58% for the more successful group. Although comparatively minimal across all groups, more successful groups in each dyad tended to explicitly verbalise technological and task knowledge more than less successful groups. Furthermore, it was more often correct or certain for more successful groups. This was particularly true for dyad 2, although there was some uncertainty about the strongest shapes for given materials in, for example, Group 12 which was the more successful group of dyad 3. The greatest similarity in verbalised task knowledge was observed with the least contrasting dyad, although evidence from concept sketching (Figs. 6 , 7 ) illustrated a shared misunderstanding between both groups of the cantilever and task requirements.

‘Group 2 concept sketch’

‘Group 8 concept sketch’

The differences in tacit-procedural knowledge between Group 5 and 7 were reflected quite consistently across other dyads, with more successful groups showing greater accuracy, skill and judgement in solution construction. The more successful groups in dyads 2 and 3 undertook three material developments that offered little to no functional advantage, and each of the developments these groups undertook correctly embodied knowledge of cognate structural concepts and principles. Notably, Group 8 of dyad 4 was able to achieved this with no structural redundancy at all. Less successful groups, however, were not as secure in their grasp of the functional dependencies and interrelationships between different parts of their structural systems. The starkest example of this was with Group 4 of dyad 3, who explicitly used triangulation but their failure to physically connect it with other parts of the structure rendered the triangulation redundant. Group 2 of dyad 4 were the only group not to triangulate the underside of the road surface. Less successful groups tended to focus slightly more of their material developments in areas of the bridge other than the road surface, whereas the opposite tended to be true for the other groups. Significantly, while all groups in the study included developments that offered little to no functional advantage, it was only in the case of less successful groups that these impaired the overall functional performance of solutions in some way. Table 4 summarises the sustained epistemic difference across all four dyads.

Process differences

Analysis of the most contrasting dyad yielded process differences in: (1) managing (Halfin, 1973 ), (2) planning, and (3) reflection. Groups managed role and task allocation differently, as well as engaging in different approaches to planning aspects of solution development. Reflection, as a process of drawing meaning or conclusions from past events, is not explicitly identified by Halfin or the conceptual framework. Two new forms of reflection for well-defined technological problem solving (declarative reflection and analytical reflection) were therefor developed to account for the differences found. The analysis of the process differences is presented with the resulting framework for this dyad. The final section presents sustained process differences across all groups.

Difference in managing—role & task allocation & adoption (dyad 1)

The autonomous creation of roles and allocation of tasks featured heavily in the activity of Group 5. These typically clustered around agreed tasks such as sketching (S = 2, 1.46), and points where group members were not directly engaged in construction. In total, Group 5 allocated or adopted roles or task on 31 occasions during problem solving compared with only 7 for Group 7. Both groups did so to assist other members (Group 5, S = 16, 3.33–3.38; Group 7, S = 3, 0.37–0.41), to take advantage of certain skills that group members were perceived to possess (Group 5, S = 2, 1.47- 1.49; Group 7, S = 2, 2.03–2.06) and, for one instance in Group 7, to prevent one group member from executing something incorrectly (S = 16, 2.11–2.13). There was evidence, however, that Group 5 moved beyond these quite pragmatic drivers. Member often had more of a choice and, as shown in Excerpt 5, allocation and adoption is mediated by sense of ownership and fairness.

Excerpt 5: Idea Ownership (Sketching) Pupil ?: “You can’t draw on them..” Pupil 1: “You draw Chloe, I can’t draw..” Pupil 2: “I know I can’t draw on them, that’s why I doing them; no, because you, you had the ideas… because you had…” Pupil ?: “(unclear)” Pupil 3: “Just draw your own ideas, right, you can share with mine right…. Right, you draw the thread one, I’ll do the straw thing…” (Group 5, S  =  2, 1.46–1.59)

The effective use of role and task allocation appeared to play an important role in realising an effective technical solution, however, negative managerial traits were perhaps more significant.

Difference in managing—negative managerial traits (dyad 1)

Evidence of differences between Group 5 and 7 were found in relation to: (1) group involvement, and (2) fragmentation of group vision, which were found to be highly interrelated. Negative group involvement accounted for traits of dominance and dismissiveness. For Group 7, this was more prevalent earlier in the problem-solving activity where one group member tended to dominate the process. This pupil tabled 9 out of 11 proposals prior to working with physical materials and, at times, readily dismissed suggestions by other group members (See Excerpt 1). Moreover, ideas and proposals within the group were sometimes poorly communicated (Excerpt 2), which led to a growing level of disenfranchisement for some group members and a fragmented group vision for solution development.

Excerpt 1 Pupil 1:“We could do it that way…” (Pupils continue discussion without acknowledgement) Pupil 1:“You could do that..” Pupil 2:“Shut up, how are we going to do that?” Pupil 1:“Well you’re allowed glue, and you’re allowed scissors..” Several group members: “Shut-up!” (Group 7, S = 1, 2.07–2.28) Excerpt 2 “(Loud inhalation) Watch my brilliant idea… I need scissors.. Are you allowed scissors?” (Group 7, S = 1, 1.36–1.41)

The was some evidence of dismissiveness present with Group 5 also (e.g. S = 9, 1.32–1.46), however, group members were able to voice their ideas which appeared to support a better shared understanding among group members. Notably, Group 5 reached a degree of consensus about what they would do prior to constructing anything, whilst Group 7 did not. Even in these early stages, two of the four members of Group 7 made it very clear that they did not know what was happening (Excerpt 3).

Excerpt 3 Pupil 1: “What are you all up to?” Pupil 2: “Move you” Pupil 4: “No idea” Pupil 2: “You’re allowed to say hell are you not?” Pupil ?: “Helli-yeh” Pupil 2: “Hellilouya” (slight laughter) Pupil 3: “Right so were going to..(unclear) and do that..” Pupil 1: “What are you all up to?” Pupil 2: “Just… I know what he’s thinking of..” Pupil 4: “I don’t have a clue what you’re thinking of..” Pupil 3: “Neither do I..” (Group 7, S = 2, 0.15–0.33)

Occurrence like these contributed to a growing sense of fragmentation in the group. Verbal and observational data show this to have been picked up by the class teacher who tried to encourage and support the group to share and discussed ideas more fully. Despite this, the group lost their sense of shared vision about how to approach a solution and, part way through the first session, two group members attempted to begin developing a separate solution of their own (S-3, 2.52).

The final managerial difference between Group 5 and 7 was the way in which efforts were made to increase the efficiency of solution development. Seen as a positive managerial trait, both groups did this, but it was more frequent and more developed with Group 5. There were four examples of this with Group 7 in the form of simple prompts to speed the process up (E.g. S = 5:3.02–3.04; S = 6:2.22–2.23; S = 11: 1.34–1.35) and 25 examples with Group 5 involving prompts and orchestrating parallel rather than successive activity.

Differences in planning (dyad 1)

Differences emerged in how Group 5 and 7 thought about and prepared for future problem-solving activity. While the complexity of the pupils’ problem-solving prevented cause and effect from being attributed to planning decisions, four areas of difference were identified: (1) determining use of/amount of materials/resources, (2) sequencing, ordering or prioritising, (3) identification of global solution requirements, and (4) working through how an idea should be practically executed. Across both problem-solving sessions, Group 5 spent over three times as long as Group 7 did, engaging in these forms of planning (8m17s vs. 2.23 s), but Group 7 planned on almost twice as many occasions (n = 98 vs. n = 56). Both groups considered the availability of materials for, and matching of materials to, given ideas (e.g. Group 5, S = 5:3.38–3.48; Group 7, S = 4:2.20–2.34; S = 12:1.53–2.00) and both identified global solution requirements. At the start, Group 5 engaged in 12 min of planning in which they read task instructions (S = 1, 0.49–1.49), explored, tested, and compared the available materials (S = 1, 1.49–2.10), and agreed on a starting point. As shown in Excerpt 4, these discussions attempted to integrate thinking on materials, joining methods, placement. As the class teacher observed, Group 7 were eager to begin construction after 4m45s and did so without an agreed starting point. Pupils in this group explored materials in a more reactive way in response to construction.

Excerpt 4 “..a tiny bit of cardboard, right, this is the cardboard, right.. (picks up part) put glue on it so that’s on that, right.. (modelling part orientation) then put glue on it there so it sticks down.. something to stick it down, do you know what I mean?” (Group 5, S = 9, 2.10–2.20)

Despite similar types of planning processes, the planning discourse of Group 5 was more proactive, and this may have minimised inefficiencies and avoidable errors. For Group 7, two group members unintentionally drew the same idea (S = 2, 3.19–3.26), parts were taped in the wrong place (S = 17, 1.26–1.40) and others glued in the wrong order (S = 5, 1.28–1.30 and 1.48–1.56). Such occurrences, however, notably reduced after the group re-started their solution in the second session which also mirrored a 73% drop in poor group involvement. Communication played an important role in planning and there was no evidence of avoidable errors with Group 5.

Differences in reflection (dyad 1)

The most prevent differences in this study were found in how Group 5 and Group 7 reflected upon their developing solutions. Analysis revealed two main forms of reflection that were used differently by groups. ‘Declarative reflection’ lies close to observation and is defined by this study as reflection that does not explicitly reveal anything of a pupil’s knowledge of technical relationships within their solution, e.g.: “that’s not going to be strong…” (Group 7, S = 2, 0.49–0.51). This form of reflection was critical for both groups who used it heuristically to quality assure material developments, but it was used slightly more often by Group 7 (n = 164:4m30s vs. n = 145:4m07s). By contrast, ‘analytical reflection’ is defined as that which does reveal something of a pupil’s knowledge of technical relationships between two or more parts of a solution. Examples of this are shown in Excerpts 5 and 6 where pupils are reflecting upon an attempt made to support the underside of the road surface.

Excerpt 5: “It’s not going to work because it’s in compression and straws bend..” (Group 5, S = 9, 2.3–2.35) Excerpt 6: “no, that’ll be… oh, aye, because that would weight it down and it would go into the water.” (Group 5, S = 14, 3.35–3.38)

Looking across verbal and observational data, there was no consistent pattern to the use of declarative reflection but analytical reflection for both groups was almost exclusively anchored around, and promoted by, the practical enactment of an idea and could be associated with predictions about the future performance of their solution. Overall, both Group 5 and 7 reflected a similar number of times (n = 216 and n = 209, respectively) although the total amount of time spent reflecting was 17% longer for Group 5. This difference in time was accounted for by comparatively more analytical reflection in Group 5 (n = 75:3m47s vs. n = 45:2m10s for Group 7), particularly during the first half of problem solving. It was also interesting that Group 7 engaged with no analytical reflection at all prior to construction.

Findings from process management, planning and reflection led to the framework of difference in Fig. 8 . This also accounts for differences in the amount of time each group reflected upon the task detail, but this was extremely limited (Group 5: n = 7, 26 s; Group 7: n = 5, 10 s).

‘Framework of process differences from comparative analysis of Group 5 and 7’

Process differences across all groups (dyads 1–4)

Task reflection, attempts at increasing efficiency and differences of fragmented vision found with the most contrasting dyad were not sustained across remaining groups. The only sufficiently consistent difference in patterns of solution development was that more successful groups, on average, spent 18% longer in planning and discussion before beginning to construct anything.

Overall, the nature and patterns of good and poor group involvement from dyad 1 were reflected more widely, with some instances of deviation. The more successful group in dyad 4 had more significant and numerous examples of poor group involvement than did the less successful group (n = 16 vs. n = 10), although they made more effective use of roles and task allocation and spent longer engaged in planning processes. Dyad 2 deviated also insofar as the less successful group (13) actually had fewer avoidable errors than Group 6 who accidentally cut the incorrect parts (e.g. S = 15, 2.44–2.47), undertook developments that were not required (e.g. S = 6, 2.11–2.16) and integrated the wrong parts into their solution (e.g. S = 7, 1.10–1.13).

Differences in the nature and use of reflection was one of the most consistently sustained findings between the most and least successful cohorts. All four of the more successful groups engaged more heavily in reflective processes and more of this reflection was analytical in nature. This shows that reflection which explicitly integrates knowledge of technical relationships between different aspects of a solution plays an important role in more successful technical outcomes. Whilst declarative reflection remained important for all groups, it was also less prominent for groups in the less successful cohort. Table 5 summarises the sustained process difference across dyads 1, 2, 3 and 4.

Social & extrinsic differences (dyad 1)

Differences reported in this section lie out with the formal conceptual framework of the study but, nonetheless, were shown to play a role in the technological problem-solving activity of dyad 1. Differences between Group 5 and 7 emerged in three areas: (1) group tension, (2) effects of the classroom competitive dynamic, and (3) study effects. Group tension, which relates to aspects of interaction such as argumentative discourse, raised voices and exasperation, were negligible for Group 5 (n = 4, 0m24s) when compared with Group 7 (n = 38, 2m38s) and related exclusively to pupils having their voiced heard. For group 7, tension was evident during both sessions, but was more significant in the first session before re-starting the solution in session 2 and purposeful attempts to work more collaboratively with the support of the teacher (Group 7, S = 10, 0.36–1.29). Observations revealed that tension was typically caused by pupils failing to carry out practical processes to the standard of other group members, or breaking parts such as the thread supporting the road surface in the 36 th minute of Session 2.

Despite collaborative efforts within groups, there was a sense of competitive dynamic which appeared either to positively bias, negatively bias, or to not affect group activity. This competitive dynamic was present in groups comparing themselves to other groups in the class. Group 7 had 3.7 times as many instances of this as Group 5 with 73% of these negatively affecting the group. These included interference from and with other groups (S = 7, 0.07–0.12), attempting to copy other groups (S = 7, 1.14–1.22) and comparing the solutions of other groups to their own (S = 8, 2.55–2.59). In contrast, Group 5 appeared to be far less affected by perceptions of competition. Around a third of instances were coded as neutral, however, Group 7 experienced more instances of positive competitive effects than Group 5 did (n = 5 vs. n = 1).

Study effects were present for both groups often triggered by the arrival of the researcher at their table to observe or take photographs. The biggest difference in study effects was associated with the audio recorder. Recorder effects for Group 7 were three and half times that of Group 5 involving discussion about how it worked (Group 7, S = 10, 3.04–3.17), or about what was caught or not caught on tape (Group 7, S = 14, 1.01–1.45). Although questionnaire data showed that pupils in Group 5 felt that they talked less in the presence of the recorder, this was not supported by observations, verbal data, or the class teacher. From these findings, the framework of social and extrinsic difference in Fig. 9 was developed.

‘Framework of social & extrinsic differences from comparative analysis of Group 5 and 7’

Social & extrinsic differences across all groups (dyads 1–4)

Most of the social and extrinsic differences identified with Groups 5 and 7 were reflected to greater or lesser extents in other dyads. In addition to less successful groups being more susceptible to researcher and recorder effects, two specific points of interest emerged. Firstly, group tension was considerably more prominent for less successful groups than it was for more successful groups. Although no evidence of a direct relationship was established, tension appeared to accompany poor managerial traits and the changing of group composition (e.g. Group 8, Group 13). The most significant differences in tension were found with dyad 3. No occurrences were found for the most successful group and 29 were seen with the least successful group including aggressive and abrupt communication between pupils involving blame for substandard construction (S = 10, 2.28–2.38), through to name calling (S = 12, 0.20–0.22), arguing (S = 6, 1.46–2.10) and threats of physical violence (S = 11, 3.25–3.29).

Secondly, the more successful groups were influenced by the competitive class dynamic more than the less successful groups were. This is the only sustained finding that directly opposes what was found with dyad 1. These took the form of neutral or negative inter-group effects involving comparing and judging other groups (e.g. Group 6), espionage, copying or suspicion thereof (e.g. Group 6, 8 and 12). Table 6 summarises the sustained social and extrinsic differences across the more and less successful cohorts.

Discussion and Conclusions

This study established and applied three frameworks to capture the epistemic, procedural, and social and extrinsic differences between groups of pupils as they developed solutions to a well-defined technological problem. Social & extrinsic findings revealed higher levels of group tension for the less successful cohort, but that more successful groups elicited more negative responses to the competitive class dynamic created by different groups solving the same problem. Major findings about differences in knowledge and process are discussed. Thereafter, a three-part characterisation of thinking for well-defined technological problem solving is presented in support of pedagogy for Design & Technology classrooms.

The most important of those knowledge differences uncovered were found in: (1) the material development of the solution itself, and (2) the reflective processes used by groups during problem solving. The conceptual framework characterises ‘tacit-procedural knowledge’ as the implicit procedural knowledge embodied in technical skill, accuracy and judgement, and this was further refined in the solutions of more successful groups. Linked to this was the fact that several of the material developments for triangulation and strength were improperly realised by less successful groups which negatively impacted on the functional performance of their solutions. Often, this was despite evidence of a good conceptual understanding of triangulation, tension, and compression in the learning phase. An ontologically endurant solution requires stability over time and lesser developed aspects of tacit-procedural knowledge and knowledge application meant that this was not realised as fully as possible for some groups.

This can be partly explained by the challenge of learning transfer, or more accurately, learning application. Several notable studies have explored these difficulties in technology education (Brown, 2001 ; Dixon & Brown, 2012 ; Kelly & Kellam, 2009 ; Wicklein & Schell, 1995 ), but typically at a subject or interdisciplinary level. The findings of this study suggest that, even when the concepts in a learning unit are tightly aligned with a well-defined problem brief, some pupils find difficulty in applying them within a tangible, material context. It could be argued that more successful groups were better at connecting learning between different contexts associated with the problem-solving task and could apply this with more developed skill and judgement.

The second important knowledge difference arose in the various forms of reflection that groups engaged with. Reflection in this study supports pupils in cycling through the re-application/transformation loop in a similar way to the perception/translation/evaluation blocks of the iterative models of problem solving (Argyle, 1972 ; Miodusre & Kipperman, 2002 ; Scrivener et al., 2002 ). Surprisingly few studies explore ‘reflection’ as a process in technological thinking (Kavousi et al., 2020 ; Luppicini, 2003 ; Lousberg et al., 2020 ), and fewer still in the context of school-level technological problem solving. This study found that more successful groups reflected more frequently, and that more of this reflection was analytical insofar as it explicitly revealed knowledge of technical relationships between different variables or parts of their solution. Such instances are likely to have been powerful in shaping the shared understanding of the group. This type of reflection is significant because it takes place at a deeper level than declarative reflection and is amalgamated with pupils’ subject knowledge and qualitative understanding of their technical solution. This allowed pupils to look back and to predict by explicitly making connections between technical aspects of their solution.

The final area in which important differences were found was management of the problem-solving process which is accounted for by Halfin ( 1973 ) in his mental process set. When analysed, the more successful cohort exploited more positive managerial strategies, and fewer negative traits. They made more extensive and effective use of role and task allocation, spent more time planning ahead and longer in the earlier conceptual phase prior to construction. Other studies have also captured aspects of these for technology education. Hennessy and Murphy ( 1999 ) discuss peer interaction, planning, co-operation and conflict, and changing roles and responsibilities as features of collaboration with significant potential for problem solving in technology. Rowell ( 2002 ), in a study of a single pair of technology pupils, demonstrated the significance of roles and participative decisions as enablers and inhibiters of what pupils take away from learning situations. What was interesting about the groups involved in this study, was that the managerial approaches were collectively more proactive in nature for more successful groups. Less successful groups were generally more reactive to emergent successes or problems during solution development.

The problem-solving activity of pupils in this study was exceptionally complex and a fuller understanding of how these complexities interacted would have to be further explored. Yet, key differences in knowledge and process collectively suggest that effectively solving well-defined technological problems involves a combination of proactive rather than reactive process management, and an ability to make two different types of technology-specific connections: contextual connections and technical connections. Proactively managing is generic and involves planning, sequencing, and resourcing developments beyond those that are immediately in play to minimise avoidable errors with reference to problem parameters. It involves group members through agreed roles and task allocation that, where possible, capitalise on their strengths. Contextual connections involve effectively linking and applying technological knowledge, concepts, and principles to the material context that have been learnt form other contexts out with solution development. This is supported by skill and judgement in the material developments that embody this knowledge. Finally, technical connections appear to be important for better functioning solutions. These are links in understanding that pupils make between different parts of the developing solution that reveal and build knowledge of interrelationships, dependencies and how their solution works. In addition to helping pupils developing effective managerial approaches in group work, this suggests that pedagogical approaches should not assume pupils are simply able to make contextual and technical connections during technological problem solving.  Rather, pedagogy should actively seek to help pupils make both forms of connection explicit in their thinking.

This study has determined that proactive management, contextual and technical connections are important characteristics of the modus operandi of pupils who successfully solve well-defined technological problems. This study does not make any claim about the learning that pupils might have taken from the problem-solving experience. It does, however, provide key findings that teachers can use to support questioning, formative assessment and pedagogies that help pupils in solving well-structured technological problems more effectively.

Ethical approval

Ethical approval for this study was granted by the School of Education Ethics Committee at the University of Glasgow and guided by the British Educational Research Association Ethical Code of Conduct. All necessary permissions and informed consents were gained, and participants knew they could withdraw at any time without giving a reason. The author declares no conflicts of interest in carrying out this study.

Argyle, M. (1972). Anlaysis of the behaviour of an interactor. In A. Morrison & D. McIntyre (Eds.), The social psychology of teaching. Cox & Wyman Ltd.

Google Scholar  

Bartholomew, S. R., & Strimel, G. J. (2018). Factors influencing student success on open-ended design problems. International Journal of Technology and Design Education, 28 (3), 753–770. https://doi.org/10.1007/s10798-017-9415-2 .

Article   Google Scholar  

Brown, D. (2001). Cognitive science concepts and technology teacher education. The Journal of Technology Studies, 27 (1), 33–42. https://doi.org/10.21061/jots.v27i1.a.7 .

Buckley, J., Seery, N., & Canty, D. (2019). Investigating the use of spatial reasoning strategies in geometric problem solving. International Journal of Technology and Design Education, 29 (2), 341–362. https://doi.org/10.1007/s10798-018-9446-3 .

Conwell, C. R., Griffin, S., & Algozzine, B. (1993). Gender and racial differences in unstructured learning groups in science. International Journal of Science Education, 15 (1), 107–115. https://doi.org/10.1080/0950069930150109 .

Custer, R. L. (1995). Examining the dimensions of technology. International Journal of Technology and Design Education, 5 (3), 219–244. https://doi.org/10.1007/BF00769905 .

Custer, R. L., Valesey, B. G., & Burke, B. N. (2001). An Assessment model for a design approach to technological problem solving. Journal of Technology Education, 12 (2), 5–20. https://doi.org/10.21061/jte.v12i2.a.1 .

de Vries, M. J. (2005). The nature of technological knowledge: Philosophical reflections and educational consequences. International Journal of Technology and Design Education, 15 (2), 149–154. https://doi.org/10.1007/s10798-005-8276-2 .

DeLuca, V. W. (1991). Implementing technology education problem-solving activities. Journal of Technology Education, 2 (2), 1–10. https://doi.org/10.21061/jte.v2i2.a.2 .

Dixon, R. A., & Brown, R. A. (2012). Transfer of learning: Connecting concepts during problem solving. Journal of Technology Education, 24 (1), 2–17. https://doi.org/10.21061/jte.v24i1.a.1 .

Doornekamp, B. G. (2001). Designing teaching materials for learning problem solving in technology education. Research in Science & Technological Education, 19 (1), 25–38. https://doi.org/10.1080/02635140120046204 .

Elo, S., & Kyngäs, H. (2008). The qualitative content analysis process. Journal of Advanced Nursing, 62 (1), 107–115. https://doi.org/10.1111/j.1365-2648.2007.04569.x .

Erkip, F., Demirkan, H., & Pultar, M. (1997). Knowledge acquisition for design education. In IDATER 97 Conference, 1997 (pp. 126-132). Loughborough: Loughborough University.

Everton, C. M., & Green, J. L. (1986). Observation as inquiry and method. In M. C. Wittrock (Ed.), Handbook of research on teaching. (3rd ed., pp. 192–213). MacMillan.

Frey, R. E. (1989). A philosophical framework for understanding technology. Journal of Industrial Teacher Education, 27 (1), 23–35.

Gall, M. D., Gall, J. P., & Borg, W. R. (2003). Educational Research: an introduction . (7th ed.). Allyn and Bacon.

Gómez Puente, S. M., van Eijck, M., & Jochems, W. (2013). A sampled literature review of design-based learning approaches: A search for key characteristics. International Journal of Technology and Design Education, 23 (3), 717–732. https://doi.org/10.1007/s10798-012-9212-x .

Gordon, T. J. (1994). The delphi method. Futures research methodology, 2 (3), 1–30.

Grubbs, M. E., Strimel, G. J., & Kim, E. (2018). Examining design cognition coding schemes for P-12 engineering/technology education. International Journal of Technology and Design Education, 28 (4), 899–920. https://doi.org/10.1007/s10798-017-9427-y .

Halfin, H. H. (1973). Technology: A process approach. Doctoral Thesis, West Virginia University, West Virginia.

Hamel, R., & Elshout, J. J. (2000). On the development of knowledge during problem solving. European Journal of Cognitive Psychology, 12 (3), 289–322.

Harkins, S. G. (1987). Social loafing and social facilitation. Journal of Experimental Social Psychology, 23 (1), 1–18.

Haupt, G. (2018). Hierarchical thinking: A cognitive tool for guiding coherent decision making in design problem solving. International Journal of Technology and Design Education, 28 (1), 207–237. https://doi.org/10.1007/s10798-016-9381-0 .

Hennessy, S., & Murphy, P. (1999). The potential for collaborative problem solving in design and technology. International Journal of Technology and Design Education, 9 (1), 1–36. https://doi.org/10.1023/A:1008855526312 .

Hill, R. B. (1997). The design of an instrument to assess problem solving activities in technology education. Journal of Technology Education , 9 (1), 31–46.

Hill, R. B., & Wicklein, R. C. (1999). A factor analysis of primary mental processes for technological problem solving. Journal of Industrial Teacher Education, 36 (2), 83–100.

Hong, J.-C., Hwang, M.-Y., Wong, W.-T., Lin, H.-C., & Yau, C.-M. (2012). Gender differences in social cognitive learning at a technological project design. International Journal of Technology and Design Education, 22 (4), 451–472. https://doi.org/10.1007/s10798-011-9152-x .

Jackson, A., & Strimel, G. (2018). Toward a matrix of situated design cognition. CTETE Research Monograph Series, 1 (1), 49–65. https://doi.org/10.21061/ctete-rms.v1.c.3 .

Johnson, S. D. (1997). Learning technological concepts and developing intellectual skills. International Journal of Technology and Design Education, 7 (1–2), 161–180.

Jonassen, D. H. (1997). Instructional design models for well-structured and III-structured problem-solving learning outcomes. Educational Technology Research and Development, 45 (1), 65–94. https://doi.org/10.1007/BF02299613 .

Jones, A. (1997). Recent research in learning technological concepts and processes. International Journal of Technology and Design Education, 7 (1–2), 83–96. https://doi.org/10.1023/A:1008813120391 .

Kavousi, S., Miller, P. A., & Alexander, P. A. (2020). Modeling metacognition in design thinking and design making. International Journal of Technology and Design Education, 30 (4), 709–735. https://doi.org/10.1007/s10798-019-09521-9 .

Kelley, T., & Kellam, N. (2009). A theoretical framework to guide the re-engineering of technology education. Journal of Technology Education, 20 (2), 37–49. https://doi.org/10.21061/jte.v20i2.a.3 .

Kelley, T. R. (2008). Cognitive processes of students participating in engineering-focused design instruction. Journal of Technology Education, 19 (2), 15.

Lavonen, J., Meisalo, V., & Lattu, M. (2002). Collaborative problem solving in a control technology learning environment, a pilot study. International Journal of Technology and Design Education, 12 (2), 139–160. https://doi.org/10.1023/A:1015261004362 .

Lewis, T. (2005). Creativity a framework for the design/problem solving discourse in technology education. Journal of Technology Education . https://doi.org/10.21061/jte.v17i1.a.3 .

Lewis, T. (2009). Creativity in technology education: Providing children with glimpses of their inventive potential. International Journal of Technology and Design Education, 19 (3), 255–268. https://doi.org/10.1007/s10798-008-9051-y .

Liddament, T. (1996). Design and Problem-Solving. In IDATER 1996 Conference, 1996 (pp. 1-5). Loughborough: Loughborough University.

Lomax, H., & Casey, N. (1998). Recording social life: Reflexivity and video methodology. Sociological Research Online, 3 (2), 121–146.

Lousberg, L., Rooij, R., van Jansen, S., Dooren, E., & van der Zaag, E. (2020). Reflection in design education. International Journal of Technology and Design Education, 30 (5), 885–897. https://doi.org/10.1007/s10798-019-09532-6 .

Luppicini, R. (2003). Reflective action instructional design (raid): A designer’s aid. International Journal of Technology and Design Education, 13 (1), 75–82. https://doi.org/10.1023/B:ITDE.0000039569.05754.a8 .

MacPherson, R. T. (1998). Factors affecting technological trouble shooting skills. Journal of Industrial Teacher Education, 35 (4), 1–29.

Mawson, B. (2003). Beyond `the design process’: an alternative pedagogy for technology education. International Journal of Technology and Design Education, 13 (2), 117–128. https://doi.org/10.1023/A:1024186814591 .

McCade, J. (1990). Problem solving: Much more than just design. Journal of Technology Education, 2 (1), 1–13. https://doi.org/10.21061/jte.v2i1.a.5 .

McCormick, R. (1994). The problem solving in technology education (PSTE) project. International Journal of Technology and Design Education, 5 (2), 173–175. https://doi.org/10.1007/BF00766816 .

Mccormick, R. (1997). Conceptual and procedural knowledge. International Journal of Technology and Design Education, 7 (1–2), 161–180.

McCormick, R. (2004). Issues of learning and knowledge in technology education. International Journal of Technology and Design Education, 14 (1), 21–44. https://doi.org/10.1023/B:ITDE.0000007359.81781.7c .

McLellan, R., & Nicholl, B. (2011). “If I was going to design a chair, the last thing I would look at is a chair”: Product analysis and the causes of fixation in students’ design work 11–16 years. International Journal of Technology and Design Education, 21 (1), 71–92. https://doi.org/10.1007/s10798-009-9107-7 .

Middleton, H. (2009). Problem-solving in technology education as an approach to education for sustainable development. International Journal of Technology and Design Education, 19 (2), 187–197. https://doi.org/10.1007/s10798-008-9075-3 .

Miles, B. M., & Huberman, A. M. (1994). Qualitative data analysis: An expanded source book (2nd ed.). California: Sage Publications.

Mioduser, D. (1998). Framework for the study of cognitive and curricular issues of technological problem solving. International Journal of Technology and Design Education, 8 (2), 167–184. https://doi.org/10.1023/A:1008824125352 .

Mioduser, D. (2002). Evaluation/Modification cycles in junior high students’ technological problem solving. International Journal of Technology and Design Education, 12 (2), 123–138. https://doi.org/10.1023/A:1015256928387 .

Mioduser, D., & Dagan, O. (2007). The effect of alternative approaches to design instruction (structural or functional) on students’ mental models of technological design processes. International Journal of Technology and Design Education, 17 (2), 135–148. https://doi.org/10.1007/s10798-006-0004-z .

Morgan, K. (2008). Does Polanyi’s Tacit Knowledge Dimension Exist? In Polanyi Society Conference, 2008 . Chicago: Loyola University.

Morrison-Love, D. (2017). Towards a transformative epistemology of technology education: An epistemology of technology education. Journal of Philosophy of Education, 51 (1), 23–37. https://doi.org/10.1111/1467-9752.12226 .

Murphy, P., & McCormick, R. (1997). Problem solving in science and technology education. Research in Science Education, 27 (3), 461–481. https://doi.org/10.1007/BF02461765 .

Odiri Amatari, V. (2015). The instructional process: a review of flanders’ interaction analysis in a classroom setting. International Journal of Secondary Education, 3 (5), 43–49. https://doi.org/10.11648/j.ijsedu.20150305.11 .

Parker, L. H., & Rennie, L. J. (2002). Teachers’ implementation of gender-inclusive instructional strategies in single-sex and mixed-sex science classrooms. International Journal of Science Education, 24 (9), 881–897. https://doi.org/10.1080/09500690110078860 .

Polanyi, M. (1967). The tacit dimension . Routledge and Kegan Paul.

Rauscher, W. (2011). The technological knowledge used by technology education students in capability tasks. International Journal of Technology and Design Education, 21 (3), 291–305. https://doi.org/10.1007/s10798-010-9120-x .

Relations, U. o. O. I. o. G., & Sherif, M. (1961). Intergroup conflict and cooperation: The Robbers Cave experiment (Vol. 10): University Book Exchange Norman, OK.

Rennie, L. J., & Parker, L. H. (1987). Detecting and accounting for gender differences in mixed-sex and single-sex groupings in science lessons. Educational Review, 39 (1), 65–73. https://doi.org/10.1080/0013191870390107 .

Ropohl, N. (1997). Knowledge types in technology. International Journal of Technology and Design Education, 7 (1–2), 56–72.

Rowe, G., & Wright, G. (1999). The delphi technique as a forecasting tool: Issues and analysis. International Journal of Forecasting, 15 (4), 353–375. https://doi.org/10.1016/S0169-2070(99)00018-7 .

Rowell, P. M. (2002). Peer interactions in shared technological activity: A study of participation. International Journal of Technology and Design Education, 12 (1), 1–22. https://doi.org/10.1023/A:1013081115540 .

Salomon, G., & Globerson, T. (1989). When teams do not function the way they ought to. International journal of Educational research, 13 (1), 89–99.

Schaafstal, A., Schraagen, J. M., & van Berl, M. (2000). Cognitive task analysis and innovation of training: The case of structured troubleshooting. Human Factors: The Journal of the Human Factors and Ergonomics Society, 42 (1), 75–86. https://doi.org/10.1518/001872000779656570 .

Schön, D. A. (1992). The reflective practitioner: How professionals think in action . Routledge.

Scrivener, S. A. R., Liang, K. C., & Ball, L. J. (2002). Extending the design problem-solving process model: Requirements and outcomes. In: Common Ground: Proceedings of the 2002 International Conference of the Design Research Society. Staffordshire University Press, Stoke-On-Trent.

Sternberg, R. J. (1999). The theory of successful intelligence. Review of General Psychology, 4 (3), 292–316.

Strimel, G. J. (2014). Engineering design: A cognitive process approach. Doctoral Thesis, Old Dominion University, Norfolk, VA.

Strong, J. T., & Anderson, R. E. (1990). Free-riding in group projects: Control mechanisms and preliminary data. Journal of marketing education, 12 (2), 61–67.

Sung, E., & Kelley, T. R. (2019). Identifying design process patterns: a sequential analysis study of design thinking. International Journal of Technology and Design Education, 29 (2), 283–302. https://doi.org/10.1007/s10798-018-9448-1 .

Twyford, J., & Järvinen, E.-M. (2000). The formation of children’s technological concepts: A study of what it means to do technology from a child’s perspective. Journal of Technology Education, 12 (1), 17.

Vaismoradi, M., Turunen, H., & Bondas, T. (2013). Content analysis and thematic analysis: Implications for conducting a qualitative descriptive study—qualitative descriptive study. Nursing & Health Sciences, 15 (3), 398–405. https://doi.org/10.1111/nhs.12048 .

Vincenti, W. G. (1990). What engineers know and how they know it: Analytical studies from aeronautical history . The Johns Hopkins University Press.

Wainwright, M. (2010). Using NVivo audio-coding: Practical, sensorial and epistemological considerations . (pp. 1–4). Social Research Update.

Webb, N. M. (1984). Stability of small group interaction and achievement over time. Journal of Educational Psychology, 76 (2), 211.

Welch, M. (1998). Students’ use of three-dimensional modelling while designing and making a solution to a technological problem. International Journal of Technology and Design Education, 8 (3), 241–260. https://doi.org/10.1023/A:1008802927817 .

Whyte, J. (1984). Observing sex stereotypes and interactions in the school lab and workshop. Educational Review, 36 (1), 75–86. https://doi.org/10.1080/0013191840360107 .

Wicklein, R. C., & Schell, J. W. (1995). Case studies of multidisciplinary approaches to integrating mathematics, science and technologyeducation. Journal of Technology Education, 6 (2), 18.

Williams, P. J. (2000). Design: The only methodology of technology. Journal of Technology Education . https://doi.org/10.21061/jte.v11i2.a.4 .

Winkelmann, C., & Hacker, W. (2011). Generic non-technical procedures in design problem solving: Is there any benefit to the clarification of task requirements? International Journal of Technology and Design Education, 21 (4), 395–407. https://doi.org/10.1007/s10798-010-9131-7 .

Xu, M., Williams, P. J., Gu, J., & Zhang, H. (2019). Hotspots and trends of technology education in the international journal of technology and design education: 2000–2018. International Journal of Technology and Design Education . https://doi.org/10.1007/s10798-019-09508-6 .

Yousuf, M. I. (2007). Using experts` opinions through delphi technique. Practical Assessment, Research, and Evaluation, 12 (4), 1–8.

Zamawe, F. (2015). The Implication of Using NVivo software in qualitative data analysis: Evidence-based reflections. Malawi Medical Journal, 27 (1), 13. https://doi.org/10.4314/mmj.v27i1.4 .

Download references

Acknowledgements

I would like to thank Dr Jane V. Magill, Dr. Alastair D. McPhee and Professor Frank Banks for their support in this work as well as the participating teachers and pupils who made this possible.

Author information

Authors and affiliations.

School of Education, University of Glasgow, 11 Eldon Street, Glasgow, G3 6NH, Scotland

David Morrison-Love

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to David Morrison-Love .

Additional information

Publisher's note.

Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Rights and permissions

Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/ .

Reprints and permissions

About this article

Morrison-Love, D. Technological problem solving: an investigation of differences associated with levels of task success. Int J Technol Des Educ 32 , 1725–1753 (2022). https://doi.org/10.1007/s10798-021-09675-5

Download citation

Accepted : 25 April 2021

Published : 02 June 2021

Issue Date : July 2022

DOI : https://doi.org/10.1007/s10798-021-09675-5

Share this article

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Technology education
• Well-defined problem solving
• Secondary school
• Learning differences
• Find a journal
• Publish with us
• Track your research

Teaching Problem-Solving Skills

Many instructors design opportunities for students to solve “problems”. But are their students solving true problems or merely participating in practice exercises? The former stresses critical thinking and decision­ making skills whereas the latter requires only the application of previously learned procedures.

Problem solving is often broadly defined as "the ability to understand the environment, identify complex problems, review related information to develop, evaluate strategies and implement solutions to build the desired outcome" (Fissore, C. et al, 2021). True problem solving is the process of applying a method – not known in advance – to a problem that is subject to a specific set of conditions and that the problem solver has not seen before, in order to obtain a satisfactory solution.

Below you will find some basic principles for teaching problem solving and one model to implement in your classroom teaching.

Principles for teaching problem solving

• Model a useful problem-solving method . Problem solving can be difficult and sometimes tedious. Show students how to be patient and persistent, and how to follow a structured method, such as Woods’ model described below. Articulate your method as you use it so students see the connections.
• Teach within a specific context . Teach problem-solving skills in the context in which they will be used by students (e.g., mole fraction calculations in a chemistry course). Use real-life problems in explanations, examples, and exams. Do not teach problem solving as an independent, abstract skill.
• Help students understand the problem . In order to solve problems, students need to define the end goal. This step is crucial to successful learning of problem-solving skills. If you succeed at helping students answer the questions “what?” and “why?”, finding the answer to “how?” will be easier.
• Take enough time . When planning a lecture/tutorial, budget enough time for: understanding the problem and defining the goal (both individually and as a class); dealing with questions from you and your students; making, finding, and fixing mistakes; and solving entire problems in a single session.
• Ask questions and make suggestions . Ask students to predict “what would happen if …” or explain why something happened. This will help them to develop analytical and deductive thinking skills. Also, ask questions and make suggestions about strategies to encourage students to reflect on the problem-solving strategies that they use.
• Link errors to misconceptions . Use errors as evidence of misconceptions, not carelessness or random guessing. Make an effort to isolate the misconception and correct it, then teach students to do this by themselves. We can all learn from mistakes.

Woods’ problem-solving model

Define the problem.

• The system . Have students identify the system under study (e.g., a metal bridge subject to certain forces) by interpreting the information provided in the problem statement. Drawing a diagram is a great way to do this.
• Known(s) and concepts . List what is known about the problem, and identify the knowledge needed to understand (and eventually) solve it.
• Unknown(s) . Once you have a list of knowns, identifying the unknown(s) becomes simpler. One unknown is generally the answer to the problem, but there may be other unknowns. Be sure that students understand what they are expected to find.
• Units and symbols . One key aspect in problem solving is teaching students how to select, interpret, and use units and symbols. Emphasize the use of units whenever applicable. Develop a habit of using appropriate units and symbols yourself at all times.
• Constraints . All problems have some stated or implied constraints. Teach students to look for the words "only", "must", "neglect", or "assume" to help identify the constraints.
• Criteria for success . Help students consider, from the beginning, what a logical type of answer would be. What characteristics will it possess? For example, a quantitative problem will require an answer in some form of numerical units (e.g., $/kg product, square cm, etc.) while an optimization problem requires an answer in the form of either a numerical maximum or minimum.

Think about it

• “Let it simmer”.  Use this stage to ponder the problem. Ideally, students will develop a mental image of the problem at hand during this stage.
• Identify specific pieces of knowledge . Students need to determine by themselves the required background knowledge from illustrations, examples and problems covered in the course.
• Collect information . Encourage students to collect pertinent information such as conversion factors, constants, and tables needed to solve the problem.

Plan a solution

• Consider possible strategies . Often, the type of solution will be determined by the type of problem. Some common problem-solving strategies are: compute; simplify; use an equation; make a model, diagram, table, or chart; or work backwards.
• Choose the best strategy . Help students to choose the best strategy by reminding them again what they are required to find or calculate.

Carry out the plan

• Be patient . Most problems are not solved quickly or on the first attempt. In other cases, executing the solution may be the easiest step.
• Be persistent . If a plan does not work immediately, do not let students get discouraged. Encourage them to try a different strategy and keep trying.

Encourage students to reflect. Once a solution has been reached, students should ask themselves the following questions:

• Does the answer make sense?
• Does it fit with the criteria established in step 1?
• Did I answer the question(s)?
• What did I learn by doing this?
• Could I have done the problem another way?

If you would like support applying these tips to your own teaching, CTE staff members are here to help.  View the  CTE Support  page to find the most relevant staff member to contact. 

• Fissore, C., Marchisio, M., Roman, F., & Sacchet, M. (2021). Development of problem solving skills with Maple in higher education. In: Corless, R.M., Gerhard, J., Kotsireas, I.S. (eds) Maple in Mathematics Education and Research. MC 2020. Communications in Computer and Information Science, vol 1414. Springer, Cham. https://doi.org/10.1007/978-3-030-81698-8_15
• Foshay, R., & Kirkley, J. (1998). Principles for Teaching Problem Solving. TRO Learning Inc., Edina MN.  (PDF) Principles for Teaching Problem Solving (researchgate.net)
• Hayes, J.R. (1989). The Complete Problem Solver. 2nd Edition. Hillsdale, NJ: Lawrence Erlbaum Associates.
• Woods, D.R., Wright, J.D., Hoffman, T.W., Swartman, R.K., Doig, I.D. (1975). Teaching Problem solving Skills.
• Engineering Education. Vol 1, No. 1. p. 238. Washington, DC: The American Society for Engineering Education.

Catalog search

Teaching tip categories.

• Assessment and feedback
• Blended Learning and Educational Technologies
• Career Development
• Course Design
• Course Implementation
• Inclusive Teaching and Learning
• Learning activities
• Support for Student Learning
• Support for TAs
• Learning activities ,

14 Major Tech Issues — and the Innovations That Will Resolve Them

Members of the Young Entrepreneur Council discuss some of the past year’s most pressing technology concerns and how we should address them.

The past year has seen unprecedented challenges to public-health systems and the global economy. Many facets of daily life and work have moved into the digital realm, and the shift has highlighted some underlying business technology issues that are getting in the way of productivity, communication and security.

As successful business leaders, the members of the  Young Entrepreneur Council understand how important it is to have functional, up-to-date technology. That ’ s why we asked a panel of them to share what they view as the biggest business tech problem of the past year. Here are the issues they ’ re concerned about and the innovations they believe will help solve them.

Current Major Technology Issues

• Need For Strong Digital Conference Platforms
• Remote Internet Speed and Connections
• Phishing and Data Privacy Issues
• Deepfake Content
• Too Much Focus on Automation
• Data Mixups Due to AI Implementation
• Poor User Experience

1. Employee Productivity Measurement

As most companies switched to 100 percent remote almost overnight, many realized that they lacked an efficient way to measure employee productivity. Technology with “ user productivity reports ”  has become invaluable. Without being able to “ see ”  an employee in the workplace, companies must find technology that helps them to track and report how productive employees are at home. — Bill Mulholland , ARC Relocation

2. Digital Industry Conference Platforms

Nothing beats in-person communication when it comes to business development. In the past, industry conferences were king. Today, though, the move to remote conferences really leaves a lot to be desired and transforms the largely intangible value derived from attending into something that is purely informational. A new form or platform for industry conferences is sorely needed. — Nick Reese , Elder Guide

3. Remote Internet Speed and Equipment

With a sudden shift to most employees working remotely, corporations need to boost at-home internet speed and capacity for employees that didn ’ t previously have the requirements to produce work adequately. Companies need to invest in new technologies like 5G and ensure they are supported at home. — Matthew Podolsky , Florida Law Advisers, P.A.

4. Too Much Focus on Automation

Yes, automation and multi-platform management might be ideal for big-name brands and companies, but for small site owners and businesses, it ’ s just overkill. Way too many people are overcomplicating things. Stick to your business model and what works without trying to overload the process. — Zac Johnson , Blogger

5. Phishing Sites

There are many examples of phishing site victims. Last year, I realized the importance of good pop-up blockers for your laptop and mobile devices. It is so scary to be directed to a website that you don ’ t know or to even pay to get to sites that actually don ’t  exist. Come up with better pop-up blockers if possible. — Daisy Jing , Banish

6. Data Privacy

I think data privacy is still one of the biggest business tech issues around. Blockchain technology can solve this problem. We need more and more businesses to understand that blockchains don’t just serve digital currencies, they also protect people’s privacy. We also need Amazon, Facebook, Google, etc. to understand that personal data belongs in the hands of the individual. — Amine Rahal , IronMonk Solutions

7. Mobile Security

Mobile security is a big issue because we rely so much on mobile internet access today. We need to be more aware of how these networks can be compromised and how to protect them. Whether it ’ s the IoT devices helping deliver data wirelessly to companies or people using apps on their smartphones, we need to become more aware of our mobile cybersecurity and how to protect our data. — Josh Kohlbach , Wholesale Suite

8. Deepfake Content

More and more people are embracing deepfake content, which is content created to look real but isn ’ t. Using AI, people can edit videos to look like someone did something they didn ’ t do and vice versa, which hurts authenticity and makes people question what ’ s real. Lawmakers need to take this issue seriously and create ways to stop people from doing this. — Jared Atchison , WPForms

9. Poor User Experience

I ’ ve noticed some brands struggling with building a seamless user experience. There are so many themes, plugins and changes people can make to their site that it can be overwhelming. As a result, the business owner eventually builds something they like, but sacrifices UX in the process. I suspect that we will see more businesses using customer feedback to make design changes. — John Brackett , Smash Balloon LLC

10. Cybersecurity Threats

Cybersecurity threats are more prevalent than ever before with increased digital activities. This has drawn many hackers, who are becoming more sophisticated and are targeting many more businesses. Vital Information, such as trade secrets, price-sensitive information, HR records, and many others are more vulnerable. Strengthening cybersecurity laws can maintain equilibrium. — Vikas Agrawal , Infobrandz

11. Data Backup and Recovery

As a company, you ’ ll store and keep lots of data crucial to keeping business moving forward. A huge tech issue that businesses face is their backup recovery process when their system goes down. If anything happens, you need access to your information. Backing up your data is crucial to ensure your brand isn ’ t at a standstill. Your IT department should have a backup plan in case anything happens. — Stephanie Wells , Formidable Forms

12. Multiple Ad and Marketing Platforms

A major issue that marketers are dealing with is having to use multiple advertising and marketing platforms, with each one handling a different activity. It can overload a website and is quite expensive. We ’ re already seeing AdTech and MarTech coming together as MAdTech. Businesses need to keep an eye on this convergence of technologies and adopt new platforms that support it. — Syed Balkhi , WPBeginner

13. Location-Based Innovation

The concentration of tech companies in places like Seattle and San Francisco has led to a quick rise in living costs in these cities. Income isn ’ t catching up, and there ’ s stress on public infrastructure. Poor internet services in rural areas also exacerbate this issue. Innovation should be decentralized. — Samuel Thimothy , OneIMS

14. Artificial Intelligence Implementation

Businesses, especially those in the tech industry, are having trouble implementing AI. If you ’ ve used and improved upon your AI over the years, you ’ re likely having an easier time adjusting. But new online businesses test multiple AI programs at once and it ’ s causing communication and data mix-ups. As businesses settle with specific programs and learn what works for them, we will see improvements. — Chris Christoff , MonsterInsights

Recent Corporate Innovation Articles

• Submit A Post
• EdTech Trainers and Consultants
• Your Campus EdTech
• Your EdTech Product
• Your Feedback
• Your Love for Us
• EdTech Product Reviews

ETR Resources

• Mission/Vision
• Testimonials
• Our Clients
• Press Release

Problem-Solving Activities With the Help of Technology

Problem-solving is one of the most vital and basic skill which is required by every one of us in the 21 st century . We feel the need of this skill quite frequently in our daily lives, and especially children should develop it at quite a young age to cope up with problems in education as well as other domains, throughout their lives.

The importance of developing this skill today is such that, it is even highlighted in the Common Core standards and has become a necessary component of any curriculum. Problem-solving directly implies decision-making, which is another important skill, not only for academics but for success in life in general.

Problem-solving comes with numerous benefits. Teaching kids the art of problem-solving has many associated advantages, like, it teaches them how to avoid conflicts in school and in their daily lives, it strengthens their empathy skills, it helps them develop positive attributions  and it is utmost required for school readiness and academic success. Generally, we would solve problems by identifying the problem, listing its possible solutions, weighing them one by one, choosing a solution to try, putting it into practice and evaluating it. Though this technique works for us most of the times, it has now become conventional and tedious. With the introduction of technology in every domain of our lives, why not introduce it to problem-solving as well. Now, when technology comes to aid us in problem-solving, it can quite revolutionize and rejuvenate the entire experience of it.

Technology supports problem-solving in a number of ways. It enables you to identify problems quicker and easier and helps you better analyze a complex problem. Technology students are especially encouraged to be innovative and to want to improve a current situation by encountering and solving problems, in an advanced way. There can be different approaches to teaching problem-solving with the aid of technology :

Students should be encouraged to concentrate not on whimsical wants or fanciful products, rather they should apply their considerable problem solving skills to attain something substantial that will improve their present situation and benefit them in the future.

They should be encouraged to find solutions from a broad range of technological and non-technological realms.

The focus and procedure of teaching problem solving using technology should be flexible. This can be directed by how the teacher helps the student select a problem and frame the context of a problem.

Students should examine situations (big and small, near and far, individual and societal) and use their creative problem solving abilities to try to plan what is best.

They should be taught to weigh short-term gains and costs with long-term gains and costs by keeping in view the educational reform, personal lifestyle changes it may lead to with the incorporation of new technology in regulation with governmental action.

The tendency in education should be to employ the term ‘problem solving’ generically to include such diverse activities as coping with marital problems and trouble-shooting electronic circuits.

It can be stated that, different types of problem situations (personal or technological) require different kinds and levels of knowledge and capability and one must be willing enough to adopt different approaches in different situations, which is eased by the inclusion of technology in problem-solving activities.

Effective and responsible national leaders and corporate executives are those with enough backbone to do what they believe is best for the nation or corporation, in spite of mass opinion. The select solutions that are holistic, sometimes more technology-dependent, other times involved with laws, communication and other social arenas. They do not blindly accept the premise that their current product or service is the single best solution to a problem. If this is the type of person a technology teacher hopes their students will become, then specific educational experiences should be designed to empower students with those independent, risk-taking abilities where the goal is what is best.

However, the best solution to a technological problem may be non- technological. Students who are practiced in considering this wider range of alternatives will be better prepared to face the demands of global citizenry than those who merely make yet another CD rack. It is critical for a technology teacher to revisit their definition and philosophy of technology, analyzing its assumptions and bias. That definition should be individually crafted by that teacher, so that it is honest and accurate, accommodates a variety of belief systems and lays the path for a wondrous technological journey for the student and teacher.

You’re invited to share your views, additional knowledge or clarify doubts on the context. So go ahead and comment, the Comment Box awaits you.

If you enjoyed reading the article, you can register HERE to receive weekly email alerts. Follow us

Latest EdTech News To Your Inbox

Stay connected.

Sign in to your account

Username or Email Address

Remember Me