A framework for communicating (or designing) any project
For those interview presentations, website portfolio projects, or just to improve your own process designing solutions..
As a product designer who’s interviewed others as well as viewed plenty of portfolios, I often see a common link missing when it comes to how projects are communicated. Arguably, this is the most important link — the link between the solution they’re showing, and the problem they were attempting to solve. If this thread is lost, the project falls apart. Not only in communicating the project to others after it’s done, but also in the design process as you move towards solutions.
I’m writing this out to give others an outline they can follow for communicating a UX project in an effort to give others a narrative they can follow whenever they are designing, or communication a project to others. You can think of each question as a slide deck in a presentation… This is arguably as important for Product Managers, but the lines of these roles often blur. Both need to be able to communicate (and persuade) to someone why something is worth doing.
Some things here will be more relevant to the individual trying to communicate a project (website, presentation, interview, etc), but it should have some value for your design process as well. If you start every project with these and continually assess them as you move through the design process, your process for creating a more intentional solution will improve.
1. Starting with a problem
a. What is a problem someone (or some entity) has?
Rarely do you enter a product design project without there being some trigger (an inability to complete a specific task, a lack of conversion, customer complaints, unhealthy metrics, etc). This should include a bit about who has this problem, and when the problem arises (what is the context?)… but if nothing else, it should be a single sentence of the problem someone (or some business) has. If you need more then a sentence to communicate this, you’re doin’ it wrong.
If you’re working on an Product Design portfolio website, make this part impossible to miss for each project. Like, the first thing someone reads with annoyingly big font. Do it. Please?
b. Why does solving this problem matter?
Ultimately, what are the implications of change? And for who? Put another way, ‘by solving this problem, the result will be X, which will allow for or provide Y’. Is that change sufficient to invest the necessary time in solving the problem? If not, then stop and reevaluate.
c. What does success look like? (Goals!)
This can often be broken into two buckets. Qualitative impacts, and quantitative impacts. Quantitative should be data driven, and tangible. ‘Reduce setup time to under 2 minutes for 90% of our users.’ ‘Increase signup conversion of those who come to our webpage from 4% to 6%.’
An example of a qualitative impact would be, ‘a simpler experience’. These goals are your north star as you move through the project, and if you’re communicating a design project, state these early and often.
2. Looking at the problem
a. What were key insights you learned by looking more deeply into the problem?
These are often the basis for how you start to think about the needs to potential solutions. It could be simple statements for customers that you commonly hear, metrics you uncovered that showed patterns of usage, or a deeper understanding of the mental model of why there is complexity is the current experience.
b. What were the reasons you uncovered as to why the problem exists?
Often the problem you’re trying to solve is a function of smaller problems that additively, led to the problem — i.e. if you are experiencing digestion problems, this may not be solely due to your diet, it could be related to your organs… (weird example, but you get it). Each of these sub-problems require different investigation and have different weights to the side-effects of the problem. Understand these and communicate them clearly. Categorizing and weighing is your friend — A: 60% of the problem, B: 30% of the problem, C: 10% of the problem.
c. What does the user/entity need for their problem to be solved?
This is arguably one of the most important steps in any process. Before moving onto a final solution, it’s imperative you’ve communicated in as simple terms as possible what the user needs for this problem to be solved. This should be based on everything you’ve uncovered and mentioned in the goals/discovery stage.
d. Given those needs, what possible solutions did you come up with that might help solve the problem?
This is essentially the ideating stage (guessing + checking). There are an infinite amount of ways to both frame problems, and also come up with possible solutions. What did you choose and why?
3. The solution to a problem
a. Of the possible solutions, what solution did you chose?
The unveiling! Show what you landed on… Ohhh. Ahhhh.
b. Why did you choose that solution, given the users problem (context + needs), and the constraints?
The solution without some additional explanation won’t get you very far… Here’s where you say why you went with the final solution. A mentor once gave me a great tip when communicating/speaking to design projects I was presenting during interviews — ‘Be able to look at your final design and for each element on the page, be able to say I choose to do this because ________.’ The blank there can be a need, a piece of information you learned through feedback, or even a constraint you had during the project (the cost to build it was lower then another solution).
c. What was the result of that solution? — did you succeed?
Look back at what your goals and the measurement of success for the project (1c, above). How’d ya do? Good? Bad? Either or, speak to this. Want to go one step further? Tell the audience what you would do differently next time.
Hopefully this is of some help to those out there looking to hone in on how you communicate a Product Design project, or any other problem you’re working on solving. If you think it may help others out, feel free to share.
