![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/circle.jpeg\")
<\/a>The whole of the process in all its Freudian glory (all illustrations by me)<\/p><\/div>\n
That is why following a rigorous process \u2014 even when time is tight \u2014 is key to getting to that point B with as much confidence and data about the solution as possible and \u2014 additionally \u2014 to make it a little easier the following times (and to build an exhaustive documentation for future generations to come).<\/p>\n
1. Understand the\u00a0problem<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1JDwprV_DD-4C1t5Q4DflaA.jpeg\")
<\/a>Problems need understanding too<\/p><\/div>\n
First off, how did this request come to life? Was it a customer request, the CEO\u2019s idea, a roadmap step towards the achievement of The Vision? Understanding where that issue on Jira or email or post it with the request came from is pivotal. Discerning the actual problem that triggered the request from the messenger\u2019s added interpretation is often hard and also easy to overlook (and let\u2019s face it, less time consuming).<\/p>\n
Traveling back to that initial spark that triggered it means making sure the starting point of the design is the actual problem, and not one of the possible solutions.<\/p>\n
Gather insights from customer care, from the CEO, from the Head of Product, whoever and \u2014 kind of like a Sigmund Freud of Product Design \u2014 dig into that until you hit the source, the original event that sparked the request.<\/p>\n
2. Research the problem and gather\u00a0data<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1ddePyPmVjgUEUlCTmEQaCA.jpeg\")
<\/a>Probing that problem is part of the\u00a0solution<\/p><\/div>\n
Step two means getting really good at bothering people and googling things. Once identified that event (might be a childhood trauma or a customer complaint) it\u2019s now time to get as much information as possible on it.<\/p>\n
How are other people handling that issue? Is it a widespread problem or a niche issue? Is there a way we can split that problem into smaller problems? And, most importantly, gather data on it.<\/p>\n
Even if we are talking about a completely new feature and\/or the product is still to be developed, there are metrics that relate to it (to some extent) that can be used. If it\u2019s an improvement of an existing feature it should<\/em> be easier getting use data from analytics or any kind of metrics that should<\/em> have been implemented.<\/p>\n3. Re-frame the\u00a0problem<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1eWm3VEXR8OOb7lDylpD6dg.jpeg\")
<\/a>Blue steel\u00a0\u2122<\/p><\/div>\n
With all that information by now, it should be easy to get a better picture of the problem and the context is exists in. Reframing the problem means getting a different set of eyes and looking at it from another perspective (see J.W. Getzels works on the \u201cProblem of the Problem\u201d and creative problem solving), thus spoiling it from any previous bias or interpretation that might have been added while collecting it.<\/p>\n
So, while the original request might have been \u201cwe need a feature that allows to transfer money to the user when the balance is low\u201d (which is a request that already contains the solution), the problem that originated it might have been \u201ctransferring money to the user is time consuming and requires constantly checking the balance\u201d.<\/p>\n
This new framing of the problem opens up new paths towards the solution (either implement a scheduler, or an automatic alert when the balance is low).<\/p>\n
4. Design the\u00a0solution<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1v7DtBmuit2zTHBNyJvG0Gw.jpeg\")
<\/a>The Vitruvian Solution<\/p><\/div>\n
The problem is now identified and data is available to put it into the wider context of the product. It is now time to frame the solution as in \u201cdecide which one of these paths is leading to the solution better fit for the problem\u201d.<\/p>\n
For this purpose it can be useful to put in the form of questions which features should the solution have \u2014 \u201cshould the user be able to set an automatic reminder?\u201d \u201cShould the user be able to import events?\u201d \u2014 and build a list of possible solution approaches. The aim is to narrow down the options and form an assumption that will be tested with a prototype.<\/p>\n
Since the aim is testing the assumption, the prototype would ideally be assumption-centered, ideally stripped from all the frills and unnecessary details that might distract the user when testing.<\/p>\n
At this step it is also ideal to chat with the developers and anyone else that will be involved in the process (QA, wider design team, customer care) to gather their insights on the solution from their perspective.<\/p>\n
5. Test the\u00a0solution<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1ntzjOH6hIm8Iae6jICLQng.jpeg\")
<\/a>\u201cI wonder why they are making me take a math\u00a0test\u201d<\/p><\/div>\n
Depending on the resources and time available, user testing<\/a> is always both challenging and necessary.<\/p>\nEven if the resources are low and time is tight, testing a sample of users that is representative of the larger user base of the product is extremely important, even more so than having a large sample which is not representative and thus, biased (see the Literary Digest case in 1936).<\/p>\n
Collecting notes \u2014 or better yet record the audio \u2014 in the most exhaustive way means it is easier if the interviews are conducted with the help of a UX researcher (if possible, or at least another human being who can write) in order to keep both the quality of the notes and the interview high.<\/p>\n
6. Implement the\u00a0solution<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1x9iGOrNVqpGhNBbeEfdmpQ.jpeg\")
<\/a>Not suited for children under\u00a03<\/p><\/div>\n
So now, is the assumption validated or not? If so, what are the pain points and strengths of the design? Assuming it all went well (assumption validated and minor pain points) the prototype will have to be turned into actual screens and requirements to give the developers. In order to pave the path for future iterations, defining which are the KPIs and success indicators of the feature is a mandatory task that might require help from other team members (marketing people, BE and FE devs).<\/p>\n
In case the assumption was not tested it would be necessary to go back to the previous step of designing the solution or even reviewing the problem itself, and start again.<\/p>\n
When designing a complex solution \u2014 to, most likely, a complex problem \u2014 one of the possible strategies might be beginning with implementing the simplest version of the solution, and add complexity over time and releases.<\/p>\n
7. Ship the\u00a0feature<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1cGhQi-bu3oMSW9VR4MhWsg.jpeg\")
<\/a>Arrrrrrrr!<\/p><\/div>\n
Well, this is self explanatory. Just get it out there and let the world know it is out there.<\/p>\n
8. Follow the feature\u2019s success<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1-iS0o-6nsFu8RnRJjL4s5A.jpeg\")
<\/a>Did he also make the best dressed\u00a0list?<\/p><\/div>\n
If everything was rightly done metrics should now be available for gathering.<\/p>\n
Checking in with customer care and giving them the heads up about what is going on and setting a preferential channel for customer feedbacks regarding all aspects of the new feature is also a good idea to monitor the the situation.<\/p>\n
9. Did the solution solve the\u00a0problem?<\/h2>\n![\"\"](\"https:\/\/marvel7077.wpengine.com\/wp-content\/uploads\/2018\/02\/1_4AplAayI8PgFIj-3H3xqQ.jpeg\")
<\/a>Solutions need understanding, too<\/p><\/div>\n
The feature has been shipped and available to the public for some time now (weeks or months), and depending on the roadmap and other issues it should be time to ask the question: did the larger user base actually found the problem solved by the implemented solution?<\/p>\n
In the perfect world, there are large parties and gathering being held to celebrate the simple brilliant beauty of the solution and world famine is now a memory just because of this feature\u2019s problem solving abilities.<\/p>\n
In reality, not everyone is pleased (users and\/or teammates), other issues have arisen and it might be time to solve niche problems or \u2014 regardless the entire process \u2014 we might have missed the mark.<\/p>\n
So, let\u2019s keep faith in the process and start all over again (with more insight).<\/p>\n
Rinse +\u00a0repeat<\/h2>\n
This article was originally published on Francesca's Medium page<\/a>.\u00a0<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Getting from point A to point B is sometimes messy even when we are simply walking \u2014 wondering if the path is right, if we are going in the right direction, what if we took that shortcut and so on. But when point A is a user problem and point B is an implemented feature, it\u2019s like navigating in open… Read More ￫<\/a><\/p>\n","protected":false},"author":210,"featured_media":14458,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[493],"tags":[],"class_list":["post-14429","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-design"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n
<\/a>Problems need understanding too<\/p><\/div>\n
First off, how did this request come to life? Was it a customer request, the CEO\u2019s idea, a roadmap step towards the achievement of The Vision? Understanding where that issue on Jira or email or post it with the request came from is pivotal. Discerning the actual problem that triggered the request from the messenger\u2019s added interpretation is often hard and also easy to overlook (and let\u2019s face it, less time consuming).<\/p>\n
Traveling back to that initial spark that triggered it means making sure the starting point of the design is the actual problem, and not one of the possible solutions.<\/p>\n
Gather insights from customer care, from the CEO, from the Head of Product, whoever and \u2014 kind of like a Sigmund Freud of Product Design \u2014 dig into that until you hit the source, the original event that sparked the request.<\/p>\n
2. Research the problem and gather\u00a0data<\/h2>\n<\/a>Probing that problem is part of the\u00a0solution<\/p><\/div>\n
Step two means getting really good at bothering people and googling things. Once identified that event (might be a childhood trauma or a customer complaint) it\u2019s now time to get as much information as possible on it.<\/p>\n
How are other people handling that issue? Is it a widespread problem or a niche issue? Is there a way we can split that problem into smaller problems? And, most importantly, gather data on it.<\/p>\n
Even if we are talking about a completely new feature and\/or the product is still to be developed, there are metrics that relate to it (to some extent) that can be used. If it\u2019s an improvement of an existing feature it should<\/em> be easier getting use data from analytics or any kind of metrics that should<\/em> have been implemented.<\/p>\n3. Re-frame the\u00a0problem<\/h2>\n<\/a>Blue steel\u00a0\u2122<\/p><\/div>\n
With all that information by now, it should be easy to get a better picture of the problem and the context is exists in. Reframing the problem means getting a different set of eyes and looking at it from another perspective (see J.W. Getzels works on the \u201cProblem of the Problem\u201d and creative problem solving), thus spoiling it from any previous bias or interpretation that might have been added while collecting it.<\/p>\n
So, while the original request might have been \u201cwe need a feature that allows to transfer money to the user when the balance is low\u201d (which is a request that already contains the solution), the problem that originated it might have been \u201ctransferring money to the user is time consuming and requires constantly checking the balance\u201d.<\/p>\n
This new framing of the problem opens up new paths towards the solution (either implement a scheduler, or an automatic alert when the balance is low).<\/p>\n
4. Design the\u00a0solution<\/h2>\n<\/a>The Vitruvian Solution<\/p><\/div>\n
The problem is now identified and data is available to put it into the wider context of the product. It is now time to frame the solution as in \u201cdecide which one of these paths is leading to the solution better fit for the problem\u201d.<\/p>\n
For this purpose it can be useful to put in the form of questions which features should the solution have \u2014 \u201cshould the user be able to set an automatic reminder?\u201d \u201cShould the user be able to import events?\u201d \u2014 and build a list of possible solution approaches. The aim is to narrow down the options and form an assumption that will be tested with a prototype.<\/p>\n
Since the aim is testing the assumption, the prototype would ideally be assumption-centered, ideally stripped from all the frills and unnecessary details that might distract the user when testing.<\/p>\n
At this step it is also ideal to chat with the developers and anyone else that will be involved in the process (QA, wider design team, customer care) to gather their insights on the solution from their perspective.<\/p>\n
5. Test the\u00a0solution<\/h2>\n<\/a>\u201cI wonder why they are making me take a math\u00a0test\u201d<\/p><\/div>\n
Depending on the resources and time available, user testing<\/a> is always both challenging and necessary.<\/p>\nEven if the resources are low and time is tight, testing a sample of users that is representative of the larger user base of the product is extremely important, even more so than having a large sample which is not representative and thus, biased (see the Literary Digest case in 1936).<\/p>\n
Collecting notes \u2014 or better yet record the audio \u2014 in the most exhaustive way means it is easier if the interviews are conducted with the help of a UX researcher (if possible, or at least another human being who can write) in order to keep both the quality of the notes and the interview high.<\/p>\n
6. Implement the\u00a0solution<\/h2>\n<\/a>Not suited for children under\u00a03<\/p><\/div>\n
So now, is the assumption validated or not? If so, what are the pain points and strengths of the design? Assuming it all went well (assumption validated and minor pain points) the prototype will have to be turned into actual screens and requirements to give the developers. In order to pave the path for future iterations, defining which are the KPIs and success indicators of the feature is a mandatory task that might require help from other team members (marketing people, BE and FE devs).<\/p>\n
In case the assumption was not tested it would be necessary to go back to the previous step of designing the solution or even reviewing the problem itself, and start again.<\/p>\n
When designing a complex solution \u2014 to, most likely, a complex problem \u2014 one of the possible strategies might be beginning with implementing the simplest version of the solution, and add complexity over time and releases.<\/p>\n
7. Ship the\u00a0feature<\/h2>\n<\/a>Arrrrrrrr!<\/p><\/div>\n
Well, this is self explanatory. Just get it out there and let the world know it is out there.<\/p>\n
8. Follow the feature\u2019s success<\/h2>\n<\/a>Did he also make the best dressed\u00a0list?<\/p><\/div>\n
If everything was rightly done metrics should now be available for gathering.<\/p>\n
Checking in with customer care and giving them the heads up about what is going on and setting a preferential channel for customer feedbacks regarding all aspects of the new feature is also a good idea to monitor the the situation.<\/p>\n
9. Did the solution solve the\u00a0problem?<\/h2>\n<\/a>Solutions need understanding, too<\/p><\/div>\n
The feature has been shipped and available to the public for some time now (weeks or months), and depending on the roadmap and other issues it should be time to ask the question: did the larger user base actually found the problem solved by the implemented solution?<\/p>\n
In the perfect world, there are large parties and gathering being held to celebrate the simple brilliant beauty of the solution and world famine is now a memory just because of this feature\u2019s problem solving abilities.<\/p>\n
In reality, not everyone is pleased (users and\/or teammates), other issues have arisen and it might be time to solve niche problems or \u2014 regardless the entire process \u2014 we might have missed the mark.<\/p>\n
So, let\u2019s keep faith in the process and start all over again (with more insight).<\/p>\n
Rinse +\u00a0repeat<\/h2>\n
This article was originally published on Francesca's Medium page<\/a>.\u00a0<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"Getting from point A to point B is sometimes messy even when we are simply walking \u2014 wondering if the path is right, if we are going in the right direction, what if we took that shortcut and so on. But when point A is a user problem and point B is an implemented feature, it\u2019s like navigating in open… Read More ￫<\/a><\/p>\n","protected":false},"author":210,"featured_media":14458,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[493],"tags":[],"class_list":["post-14429","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-design"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n
<\/a>Probing that problem is part of the\u00a0solution<\/p><\/div>\n
Step two means getting really good at bothering people and googling things. Once identified that event (might be a childhood trauma or a customer complaint) it\u2019s now time to get as much information as possible on it.<\/p>\n
How are other people handling that issue? Is it a widespread problem or a niche issue? Is there a way we can split that problem into smaller problems? And, most importantly, gather data on it.<\/p>\n
Even if we are talking about a completely new feature and\/or the product is still to be developed, there are metrics that relate to it (to some extent) that can be used. If it\u2019s an improvement of an existing feature it should<\/em> be easier getting use data from analytics or any kind of metrics that should<\/em> have been implemented.<\/p>\n Blue steel\u00a0\u2122<\/p><\/div>\n With all that information by now, it should be easy to get a better picture of the problem and the context is exists in. Reframing the problem means getting a different set of eyes and looking at it from another perspective (see J.W. Getzels works on the \u201cProblem of the Problem\u201d and creative problem solving), thus spoiling it from any previous bias or interpretation that might have been added while collecting it.<\/p>\n So, while the original request might have been \u201cwe need a feature that allows to transfer money to the user when the balance is low\u201d (which is a request that already contains the solution), the problem that originated it might have been \u201ctransferring money to the user is time consuming and requires constantly checking the balance\u201d.<\/p>\n This new framing of the problem opens up new paths towards the solution (either implement a scheduler, or an automatic alert when the balance is low).<\/p>\n The Vitruvian Solution<\/p><\/div>\n The problem is now identified and data is available to put it into the wider context of the product. It is now time to frame the solution as in \u201cdecide which one of these paths is leading to the solution better fit for the problem\u201d.<\/p>\n For this purpose it can be useful to put in the form of questions which features should the solution have \u2014 \u201cshould the user be able to set an automatic reminder?\u201d \u201cShould the user be able to import events?\u201d \u2014 and build a list of possible solution approaches. The aim is to narrow down the options and form an assumption that will be tested with a prototype.<\/p>\n Since the aim is testing the assumption, the prototype would ideally be assumption-centered, ideally stripped from all the frills and unnecessary details that might distract the user when testing.<\/p>\n At this step it is also ideal to chat with the developers and anyone else that will be involved in the process (QA, wider design team, customer care) to gather their insights on the solution from their perspective.<\/p>\n \u201cI wonder why they are making me take a math\u00a0test\u201d<\/p><\/div>\n Depending on the resources and time available, user testing<\/a> is always both challenging and necessary.<\/p>\n Even if the resources are low and time is tight, testing a sample of users that is representative of the larger user base of the product is extremely important, even more so than having a large sample which is not representative and thus, biased (see the Literary Digest case in 1936).<\/p>\n Collecting notes \u2014 or better yet record the audio \u2014 in the most exhaustive way means it is easier if the interviews are conducted with the help of a UX researcher (if possible, or at least another human being who can write) in order to keep both the quality of the notes and the interview high.<\/p>\n Not suited for children under\u00a03<\/p><\/div>\n So now, is the assumption validated or not? If so, what are the pain points and strengths of the design? Assuming it all went well (assumption validated and minor pain points) the prototype will have to be turned into actual screens and requirements to give the developers. In order to pave the path for future iterations, defining which are the KPIs and success indicators of the feature is a mandatory task that might require help from other team members (marketing people, BE and FE devs).<\/p>\n In case the assumption was not tested it would be necessary to go back to the previous step of designing the solution or even reviewing the problem itself, and start again.<\/p>\n When designing a complex solution \u2014 to, most likely, a complex problem \u2014 one of the possible strategies might be beginning with implementing the simplest version of the solution, and add complexity over time and releases.<\/p>\n Arrrrrrrr!<\/p><\/div>\n Well, this is self explanatory. Just get it out there and let the world know it is out there.<\/p>\n Did he also make the best dressed\u00a0list?<\/p><\/div>\n If everything was rightly done metrics should now be available for gathering.<\/p>\n Checking in with customer care and giving them the heads up about what is going on and setting a preferential channel for customer feedbacks regarding all aspects of the new feature is also a good idea to monitor the the situation.<\/p>\n Solutions need understanding, too<\/p><\/div>\n The feature has been shipped and available to the public for some time now (weeks or months), and depending on the roadmap and other issues it should be time to ask the question: did the larger user base actually found the problem solved by the implemented solution?<\/p>\n In the perfect world, there are large parties and gathering being held to celebrate the simple brilliant beauty of the solution and world famine is now a memory just because of this feature\u2019s problem solving abilities.<\/p>\n In reality, not everyone is pleased (users and\/or teammates), other issues have arisen and it might be time to solve niche problems or \u2014 regardless the entire process \u2014 we might have missed the mark.<\/p>\n So, let\u2019s keep faith in the process and start all over again (with more insight).<\/p>\n This article was originally published on Francesca's Medium page<\/a>.\u00a0<\/em><\/p>\n","protected":false},"excerpt":{"rendered":" Getting from point A to point B is sometimes messy even when we are simply walking \u2014 wondering if the path is right, if we are going in the right direction, what if we took that shortcut and so on. But when point A is a user problem and point B is an implemented feature, it\u2019s like navigating in open… Read More ￫<\/a><\/p>\n","protected":false},"author":210,"featured_media":14458,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[493],"tags":[],"class_list":["post-14429","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-product-design"],"acf":[],"yoast_head":"\n\n\n\n\n\n\n\n\n\n\n\n\n\t\n\t\n\n\n\n\n\t\n3. Re-frame the\u00a0problem<\/h2>\n
<\/a>4. Design the\u00a0solution<\/h2>\n
<\/a>5. Test the\u00a0solution<\/h2>\n
<\/a>6. Implement the\u00a0solution<\/h2>\n
<\/a>7. Ship the\u00a0feature<\/h2>\n
<\/a>8. Follow the feature\u2019s success<\/h2>\n
<\/a>9. Did the solution solve the\u00a0problem?<\/h2>\n
<\/a>Rinse +\u00a0repeat<\/h2>\n