When solving a design problem it's easy to focus on the user's problem and forget about the constraints that need to be addressed by the business and the technology to solve the problem. I find myself guilty of not paying attention to detail sometimes.
The below diagram is common to find in design-related articles. It illustrates that for a solution to be successful it needs to have equal parts desirable to the user, feasibility to build, and viability for the business to sell. If one of these elements isn't fully understood, our design fails. I've had some experience recently where the push to solve the customer problem has meant that the technology and business issues haven't been fully understood and we hit problems.
How might we test the quality of our design decision before we settle on a solution? In Ryan Singers' book, Shape up, when the designer is shaping (concept) their designs, he says that he tests the ideas in his notebook. Trying to understand it from a number of different angles to see if it will work. This got me thinking about the way that I can approach this. For the customer to be able to play our their desirers, I want to know what the business and the technology needs to do to enable this. Can the design solution fit?
Model:
Sketching
The method has low overheads and risks. The designer can use this method with simple tools like a pencil and paper or an iPad. The practice takes a few minutes to plot out as a rough pass. The designer should aim to keep this method as low fi as possible.
Demand & Flow
Understand the demand of the product system or service plays from the user point of view. We should be aiming to solve the right problem. This method doesn't help the designer uncover the demand or user desires, but it does help the designer design for a specific demand from the user.
The user flow and the flow of the feature are well understood. The designer needs to fully understand the flow of the user through the product, system, or service. This will help them adjust to any changes to the solution that may need to happen due to tech and business constraints. Then the designer also needs to fully understand the flow of the user through their solution.
Mapping
Plot the intended action by the user. We have a strong understanding of the user desirer at this point in the flow. This tool takes this action and maps the business and technology around it.
The method outputs a result the user is trying to achieve. We map out the desired solution. This gives the designer a reference point to frame the business and technology issues from the perspective of the desirer of the user and the output we need. It's similar to saying how do we get from point A to point B.
A profitable solution, with a sustainable business model. The designer asks the question of the business on how they would approach helping the customer achieve their desirer so that we can achieve a particular outcome. Is it possible for the business to do what they need to do to achieve the outcome? The issue the designer may face is they have designed a solution that is too expensive for the business to implement or requirer too many manual processes. This may mean that the designer needs to rethink their solution.
A feasible solution, building on the strengths of your current operational capabilities. The designer asks questions about the technology to understand how it can help the user and the business achieve their desirer. Similar to a point 6. We may need to adjust our design when the technology can't deliver the want we need in our timescale or requirer too large of a project to deliver the result. In these cases, we will need to plan out either how we deliver this or readjust our design. This is especially important when designing over legacy systems.
Collaborate
Reviewing with the team to validate assumptions. This process can be started as a best guess unless you have a clear understanding of the technology and business. But it's worth showing the team your sketches so that they can validate your thinking. You may have missed parts that need to be added. The clearer you are on the detail the better the design will be and the better it will be implemented.
I've been using this process recently, I'm finding that the solutions that I'm designing are a lot more thought out. The conversations I'm having with developers, BA, PO, and stakeholders are much more productive.
