Quais são algumas maneiras de criar produtos inovadores e fáceis de usar?

All these statements are true, and you have to do all these things when you are a product designer. But the best way to understand your audience better is to use the product you’re designing for. When you’re on both sides, it improves your work quality and helps you identify problems and user needs, leading to better results.

And that can vary depending on the product or what it is that you are building. There are 3 levels of personas and 99% of what is taught out there is biased. Age, what they do, giving them a picture or income is all a bias. You start with all user groups, then filter via Venn Diagrams or comparables of commonalities and differences to find the correct user group to concentrate on. Use both qual and quant data and never make assumptions. User Satisfaction is not a great measure of anything. Also, make sure you understand from the beginning what the measurement of success is for the user! Make it measurable and time-bound. Then use that throughout to make sure you are using the right design patterns for that user.

I don't believe starting with the users is always the right thing to do. Starting with a desired business outcome, or goal, helps product, design, and development teams focus their efforts on work that is likely to generate the best business outcomes. Once you have a goal, breaking the goal down into the strategies that are likely to help the team reach the goal will further focus the work. Finally, the team must define the measurable objectives that you'll need to achieve in order to complete each strategy. With the work broken down this way, your team will have a much higher chance of identifying the users that will be impacted by the work you have identified as the highest priority. These are the users you want to focus on helping.

In my experience, a product has to be built with the users in mind. To acheive that, understanding the users is a MUST. Since a product is a solution that solves the users needs, extensive research on the users, buyers and customers should be the first step of the process.

First, we must ask ourselves whether it is a new feature of an existing product or service or a completely new product or service. In the second case, we must first understand with a good competition benchmark, what is the market base from which we start and what users expect to find. We must also collect best practices and understand the business vertical. With all this in mind, is when we can begin to investigate what our target market is and then go deeper until we can generate empathy with properly built UX personas.

One interesting phenomenon when developing ideas is structural fixidness i.e. the way designs conform to the standard convention of predecessors. Take electric vehicles as an example. Wheel mounted motors and base mounted batteries mean there's no specific reason why they conform to the layout of internal combustion engine vehicles yet most have the layout of an engine bay, cabin and trunk. Imagine a configuration with no engine bay and how that might benefit some users visibility and parking. SCAMPER and SIT processes are a great way to break this habit with ideation methodologies like subtraction, multiplication, division and task unification.

Of course ideas based on what the user would do or not is great. The key is to do this workshop style and bring Product and Engineering into the process. All agree on what can be done, make them all aware of what the users' needs are, not forgetting the measurable part I love a priority grid where everyone agrees on which things are feasible and what has the most impact for the user. Engineering being there will help to let UX know when something they are thinking will take 10 seconds and 6 API calls to load. All the marketing and competitor analysis should be done before you get to this point.

If you have well-defined business goals, strategies, and objectives you should be able to do the user research to support those objectives. The result of that research should include user segments (personas) and their related scenarios. A scenario describes something specific that your users need to be able to achieve. Weighting those scenarios by how important they are to the user, how hard they are for the user to achieve, and how frequently the user needs to achieve them will provide your team with the raw ingredients that are needed to conduct ideation sessions to generate both iterative and innovative ideas.

Be prolific. However... Idea generation is important but it depends on how well the research was done and what insights learned. Make sure to prioritize the assumptions and center the hypotheses around themes so you can generate ideas around how might we create a solution to these problems.

A great way to generate ideas is to get in a room (or a virtual one) and run an "Ideasflow" session. There's a great book on the topic, aptly named "Ideasflow," and the concept is simple. Get your team to think about any idea that you can think of to improve whatever area you work in within 5 minutes. Go heads down and simply write anything that comes to mind. You'll be surprised by what comes out of this simple session alone!

Most MVP's should be run as evaluations and tests first. Before you get to your MVP, it's easy to run demand generation tests, fake-door tests and understand the viability and value of your idea. From there, you can use simple tools like Paper Prototypes, or if you have a design system in place, use something like Figma to create a solid prototype to show it off to prospects and customers. While this is occurring, you can easily create a Lean Canvas (for a whole product) or Product Canvas (for a feature) to answer meaningful questions, such as what target market you are going after, KPI's, outcomes and more.

To begin, you should validate that: 1) Users agree that the problem you are trying to solve is in fact a problem 2) That the solution to the problem you are solving is a solution that users are interested in engaging with 3) That this solution solves the problem better by some measure than other solutions your users might already employ 4) That users are willing to compensate you for your solution 5) How much compensation users will be willing to pay for your solution The answers to each of these questions are important to understand individually but together they help you understand the validity and viability of your solution along with the size of the opportunity. This is the information needed to decide if you should proceed.

Start with sketches on paper. Always. Test with the Subject Matter Experts first. Sketches you can throw away, and it helps you think about the flow and more holistically than going straight to the computer. Also too many companies ask for A/B testing when they really are asking for a preference test. Lean models are great, but should also be done long before this point. One of the FIRST things to be done so you know if something should even be done, or understand if the business needs even meet with the users' needs.

Before you choose a method for validating ideas, you must identify what you are trying to validate and the kind of feedback you want. This will inform how you approach any testing, from the questions you ask users to the metrics used to indicate success or failure.

In my experience, start with interaction design; user flows, information architecture, sitemaps, and wireframes. These methods give you the blueprint for the experience you want to deliver. 💡Take this opportunity to validate decisions on the intended interactions without the distraction of visual elements like colors, content and typography.

Just like sketching on paper first, user flows are mandatory to understand and see if there is too many steps or where there are awkward interactions. Look at the transitions between pages and tasks. It is easy to use design patterns, but making sure they are the right ones for the users and the tasks is key. I also always recommend storyboards. It is sometimes easier to see how things flow when you storyboard it out. Again, getting rid of any awkwardness early.

Whoa, whoa, whoa. I know in HCD where this process comes from test is after, but testing early and OFTEN is key to measuring success. Are the measures to shorten the time to a task, eliminate unnecessary pages, whichever measurement and time-bound thing you had in mind from the beginning should be tested with anything new. If any design system or patterns are being used by the time you get to high fidelity things should have already be tested several times by this point. Making sure you are able to pivot when needed instead of testing too late when the visual problem-solving is done.

When teaching a course or leading a workshop on Design Thinking, I often start with the statement: "Today's problem began as yesterday's solution." We owe it to our planet and future generations to ramp up the level of scrutiny for any innovation that we may want to introduce to the world, because history amply demonstrates how short-sighted and irresponsible we are with it. Make sure your great, new idea does not turn into a "problem" for your grandchildren to cope with, in addition to the many others we are already leaving behind for them.

Again, while mentioned at this point, testing starts early and is done often. Also you should have done the measurement of success for the user early on as well. In Agile, in and Epic so the designs are done so they feed the features. You should be only making necessary tweaks by stories and way ahead of development. DO this along side business measurements of success. Product does that and UX does the users' measurement of success.

Usability testing occurs much earlier when understanding your users. User testing should be conducted during the idea validation and design phases to get the most value from this activity. This ensures that what is being built delivers delightful experiences that meet user's needs. 💡Consider how you can capture user feedback after the product launches. This feedback is extremely valuable.

Know more and more about users. Be in constant interaction with your users and observe their story. Validate with a test version of actual product. This will make you understand whether the users' challenges are addressed properly or not.

Its good to know constraints or factors that add complexity to the problem and solution. These can be rules and regulations for a particular industry or how a product solution is just one of many in an entire ecosystem in the tech stack. These factors are out of your control but use this knowledge to guide your decisions during product research and development.