All creative agencies depend upon exhibiting effective problem solving skills. No project is simple, and working with clients requires the design and development team to interpret the clients requests and turn them into a working solution. This inevitably leads to problems, and solving these problems is critical to delivering a project that meets the expectation of the client.
Perhaps you need to fit seven images into a twelve-column layout, or maybe you’re got to find a way to create repeated, looping animations in CSS with delays. Whatever the problem, be it design, strategy or code, there are many methods to use to help you to solve them. Here are some creative ways to solve these everyday issues, including some useful techniques that help identify problems and potential failure points before you even start a project.
Created by revolutionary thinker and problem-solver Edward de Bono, Six Thinking Hats coerces you to critique a product with a preset state of mind, allowing you to approach each project with a different perspective. It leads to more balanced and rounded analysis, which in turn can help you solve various problems with your project.
Whilst most people don’t actually wear coloured hats when using this technique, buying a set of funny coloured hats and using the technique as a team makes problem solving your projects enormous fun. You could even involve your clients!
- White Hat – This is the fact hat, and is all about data and information that is factual and indisputable.
- Red Hat – This is the feelings and emotions hat, this is the hat that encourages you to think using your instinct. How does a design make you feel? There is no need to justify your feelings and emotions and they should not be challenged, but accepted openly.
- Yellow Hat – This is the positive hat. Whilst using this hat, you must think positively. What do you like about the design? Look for any possible benefits.
- Black Hat – This is the stern, judgemental hat. Don’t confuse this with negativity – rather this is about being critical and identifying flaws, as well as being cautious.
- Green Hat – The creative hat, this is about thinking differently as to how a design could fulfill its potential. Try to think of ideas you would never normally consider.
- Blue Hat – The process hat, this hat is to ensure that whilst using six thinking hats that the group are following the correct procedure. It is also about identifying the aims and objectives of the session.
So how to use six thinking hats? Throughout the session, one individual needs to always wear the blue hat. This individuals role is to keep the session on track, as well as identifying and pinpointing the goals and aims to be looked at. The blue hate wearer should guide the session and ensure nobody goes off too much on a tangent.
The rest of the group should adopt each hat at a time. Some people prefer the whole group to wear the same hat, others find the method works better when each person wears a different hat. For a smoother, more efficient session it is better for everyone to wear the same hat, as it helps participants stay on track.
FMEA (Failure Mode & Effects Analysis)
An FMEA is a process where you identify any potential point at which a produce or service could fail. In regards to a website, you might identify a failure point as a button failing to trigger a certain event. You then use a scoring system to prioritise each possible failure and the relevant action. An FMEA is usually drawn up as a table, for example:
Image source: http://asq.org/learn-about-quality/process-analysis-tools/overview/fmea.html
The process is as follows:
- Identify a function – e.g. clicking a “Checkout” button
- Identify each way that function could fail – e.g. the button fails to take the user to the checkout page, or the button takes the user to an incorrect page
- Identify the potential effect of failure – e.g. the customer is dissatisfied and leaves the website
- Score the severity of the failure on a scale of 0-10 – e.g. 9
- Identify the potential root cause of the failure – e.g. there in an error in the code
- Give the failure an occurrence score on a scale of 0-10, this is an estimate of the probability of failure – e.g. 3
- Establish process controls, these are methods for preventing this failure from reaching the customer – e.g. debugging the code
- Give the failure a detection rating, this is how likely the process controls are to detecting the potential problem – e.g. 8
- Calculate the risk priority number or RPN, this is Severity (S) x Occurrence (O) x Detection (D). This is how you ultimately priorities which potential failures to work through first – e.g. 76
- Identify recommended actions – e.g. ask development team to debug code
- Lastly – you can choose to then note down the result of the action and any other notes.
An FMEA is quite a complex and drawn out process, so for small scale websites and digital products it’s recommended to either simplify the FMEA process by removing from it any step that is irrelevant, or by adopting a more simplified problem solving process. Many agencies will simply test their products for weakness instead – however the strength in FMEA is that it can identify potential failure before a site has even been built, allowing developers to already have the potential problems in mind before they code. This can help avoid encountering bugs later down the line.
QFD (Quality Function Deployment)
Much like an FMEA, a QFD is more of a preventative measure rather than solving existing problems. A QFD is a tool mostly used in engineering, but it can be interpreted and translated into a useful method for web development teams. A QFD differs from an FMEA in that rather than identifying potential failure points, it looks to convert customer requirements into actual engineering characteristics. Put simply, it encourages you to listen to the needs of your client and turn those needs into actual, functional solutions.
A QFD is difficult to explain how to create in words, rather, this interactive demo explains all the different components effectively. It’s a little dated looking, but it works well to explain a QFD and how to create one. Due to the relative complexity of a QFD, it is another tool more useful for large scale projects.
Po (Lateral Thinking)
Another term coined by Edward De Bono, Po involves the creation of an entirely new idea that potentially leads to a solution of a problem. In the case of web design, a Po could be discarding a mock-up and creating an entirely new design, even if only a small portion of the original design was problematic. Po works by allowing you to approach a project with an entirely fresh perspective.
Po is also about implementing ideas that may otherwise be discarded – for example ideas that are silly or have no evidence to back them up. As a slightly extreme example, you may have a problem whereby users of a website find the font is not appealing and friendly, leading to a Po of utilising the comic sans font. You would never have actually used comic sans, but the idea of doing so in turn leads to researching a similar (but higher quality) font that has a more friendly feel, similar to comic sans. If it wasn’t for this Po, you may never have used the font you ended up implementing.
Po can be fun to experiment with clients, by running sessions with clients and users where random, thoughtless ideas are all chucked in and given consideration and even implemented – leading to a potential working solution.
So there you have it – some interesting techniques and tools – not just for solving problems, but preventing problems. Like any tool, they can be twisted and adapted to suit your working style. For example, the QFD is quite complicated but your agency may devise a similar method that is far more simple, but has the same effect.
These tools can also be a fun and engaging way to interact with clients. If you use any of them, or have other suggestions – let us know!
Looking for more tips?
Jump on our mailing list & get digital goodness straight to your inbox; including helpful tips, tricks and the latest articles surrounding marketing, web design and branding.Sign up →