The feature design process as described on this page explores creating a new, validated product feature. The process works great when your product has a user problem, but no clearly defined solution. You can explore multiple solutions or ideas until you land on one that sticks.
The feature design process has a number of steps that are designed to produce a successful output from the product team. This means clearly defining the user problem, and validating prototypes before development starts. Although it may be more upfront work than a traditional design/development process, it saves significant time by aligning stakeholders early, and having confidence in a solution before engineers start their work.
To be able to adequately solve a user problem, you need to make sure it is clearly defined (and is actually the problem). You could go through this whole feature design process and create a solution for a problem that doesn't really exist. This is why it's very important to validate your user problem, to make sure the solution you create does provide value to users.
Often before you start the feature design process you will have a vague idea of what the user problem is. This will usually come about from direct feedback from users, or it is discovered through analysing how users use your product. This is a good starting point, but it is not enough to start brainstorming solutions.
First, you need to make sure the user problem you identified is the real user problem, not one user problem layered on another. Finding the root cause of a user problem can often be a difficult process, but it's important to make sure you're solving for the right solution.
At Poliigon, our support team was a great resource to discover user pain points. Over the years we had a number of users voicing their concerns that they couldn't download Poliigon assets fast enough. They had to go through the user flow of clicking on an asset, opening the asset modal, selecting their download options, and then clicking download. This flow is fine for a user downloading a few assets, but it falls apart for a power-user wishing to download hundreds of assets. One user even said to us that downloading multiple assets felt like a second job.
Our User Problem Hypothesis: We believe that users want to be able to download multiple assets that have been purchased already as well as download + purchase multiple new assets.
Although we had multiple users suggest that downloading multiple assets took too long, we needed to do some digging to find out why users wished to speed up this flow. As a result, we conducted user interviews with questions surrounding downloading multiple assets on Poliigon. We learnt a lot about Poliigon users during this interview, and discovered pain points even outside of the multiple download scope.
Many users suggested some sort of batch downloading to solve this issue. We also discovered the reasons which demographic of users wanted to download multiple assets, and the context why. We also discovered a number of key insights to how users interpret purchases and downloads, and how they prefer to use the site for downloading multiple assets. This influx of information was great, but it was important to be able to consolidate the information relevant for this project.
As a result of this process, we were confident that our users find it time consuming to download multiple assets, allowing us to move on to the brainstorming stage of the feature design process.
The next stage of the process is brainstorming ideas and solutions to the user problem. Before we could start brainstorming, constraints needed to be defined for the project and brainstorming session.
Although the purpose of the brainstorming exercise to to explore ideas that don't come to mind first, it's important to restrict the responses. This way we can target our brainstorming more towards real world solutions that may make an impact.
These constraints include constraints around the project solution, as well as feasibility constraints. We need to define what the bare minimum criteria is to solve the user problem, as well as what technological, timeline and resource constraints there are.
From these constraints, we generate questions to answer under a time restriction. The resulting ideas and solutions are then consolidated and sorted into like ideas, eventually distilled down to a set of solutions that can be tested. This process lets us select ideas that solve our user problem, and are feasible to develop.
The prototype testing process lets us iteratively explore and validate the ideas and solutions we came up with in the prioritisation process.
Before creating prototypes, we need to come up with clear objectives. Why are we creating this prototype, and what are we looking to learn? Sometimes a prototype is not the correct way of validating a solution or idea. For this example, we were confident in our solution, but had questions around how the UI would actually function. This is a great opportunity to create a prototype to test with users.
Our Proposed Solution: Add a button which will let users purchase + download assets from the grid in a single click.
Our proposed solution was to create a button on the asset grid that allows user to purchase in a single click. Although a bulk download system was discussed as a solution, we discovered a number of downsides that impacted the user problem negatively. This solution solves the user problem for power users, while also improving the experience for users even without this user problem. Before going right in and developing this solution, I created a fully interactive prototype to test with users.
Once the prototype was created, we put it in front of our users through an unmoderated test. We asked a number of clarifying questions along with the prototype to fully understand how and why they made the decisions they did during the usability test. This method allowed us to get feedback very quickly, and we could immediately answer the questions we set at the start of the prototyping pieces. We discovered the button was clear in its function, but its secondary button (that allows users to change their default download settings) was not.
We were happy with our responses from the prototype test, but needed to come up with a solution for default downloads. Instead of running another prototype test (as we had gained enough data from previous tests), we decided to add default download options to the account dropdown and restyled the default download link in the asset boxes.
Our Solution: Add a button which will let users purchase + download assets from the grid in a single click. Users will also be able to preview and edit their default download settings prior to download via a link below the download button, and through the account dropdown.
As a result of these tests, we had a validated solution to our user problem as well as assets ready for the development team. The only tasks left after this process was creating additional minor supporting UI documents.
At this stage of the project, we have an extremely clear and concise product requirements document, with data to back up decisions to stakeholders. We also have all files ready for developers who can get started on their feature development process immediately.
Going through the feature design process lets us have confidence in our solution, reducing disruptive changes and revisions later in the product cycle.
The project discussed on this page is still in development! Soon you will see the feature on the Poliigon site and I will update this page with the results.
This process is great for every team member. For us product designers it gives us the peace of mind behind our decisions, and for engineers they can be confident any revisions will be minimal. It speeds up both the design and development process, letting us ship products faster.
Get in touch to discuss what will make your next project a success. Do you instead just want to chat about design, or have a couple questions? No worries, let's chat.
Get in Touch!
