<style>

  @import url('https://fonts.googleapis.com/css?family=Nanum+Gothic+Coding&display=swap');
</style>

<nav id="navbar">
  <header class="h1">Design and User Experience</header>
  <ul>
    <li><a class="nav-link" href="#Basics_of_User_Experience_(UX)">Basics of User Experience (UX)</a></li>
    <li><a class="nav-link" href="#Double_Diamond">Double Diamond</a></li>
    <li><a class="nav-link" href="#Setting_the_Stage">Setting the Stage</a>
      <ul>
        <li><a class="nav-link" href="#-_Updating_your_Challenge_Statement">- Updating your Challenge Statement</a></li>
      </ul>
      <li><a class="nav-link" href="#Validating_the_Problem">Validating the Problem</a>
        <ul>
          <li><a class="nav-link" href="#-_Internal_Interviews_with_Stakeholders">- Internal Interviews with Stakeholders</a></li>
          <li><a class="nav-link" href="#-_Lightning_Talks">- Lightning Talks</a></li>
          <li><a class="nav-link" href="#-_user_interviews">- User Interviews</a></li>
          <li><a class="nav-link" href="#-_Ethnographic_Research">- Ethnographic Research</a></li>
          <li><a class="nav-link" href="#-_Gathering_it_Altogether">- Gathering it Altogether</a></li>

        </ul>

  </ul>
</nav>

<main id="main-doc">
  <section class="main-section" id="Basics_of_User_Experience_(UX)">
    <header>Basics of User Experience (UX)</header>

    <article>
      <p>This article introduces the basics of UX to help teams, products, startups and companies to create a robust and meaningful process for developing a better experience for their users and customers. You could use different parts of the process individually
        but they work best if you follow a series of steps.</p>

      <p>This guide is put together from the work of Mustafa Kurtuldu and this guide also borrows quite a bit from the Design Sprint methodology that mutliple teams across Google use to troubleshoot and solve challenges such as the Self Driving Car and Project
        Loon.
      </p>
    </article>
  </section>

  <section class="main-section" id="Double_Diamond">
    <header>Double Diamond</header>

    <article>
      <p>
        This flow work is based on what we in UX cicles call the double diamon, made popular by the British Design Council where your team diverges to understand an idea through research and then converges to define the challenge, diverges to sketch it individually,
        share the ideas, decide on what the best way forward is, test and validate.
      </p>
      <img src="https://developers.google.com/web/fundamentals/design-and-ux/ux-basics/images/double-diamond.png?hl=es" alt="Image of Design and UX Double Diamond" />
      <p>The Double Diamond design process model pioneered by the British Design Council. The steps involved in these phasses of a project are; <b>Understand, Define, Diverge, Decide, Prototype and Validate.</b></p>
    </article>
  </section>
  <section class="main-section" id="Setting_the_Stage">
    <header>Setting the Stage</header>
    <article>
      <p>First thing is to start with the underlying challenge at hand and write it out like a proposal, asking yourself, “what is the problem I’m actually trying to solve?”. The challenge statement is the brief you are setting for the project that includes
        your goal.</p>

      <p>This challenge could be for an existing product feature that needs to be refined or a completely new product altogether. Whatever your task may be, simply adjust the language to fit the goal you are trying to achieve. A statement should be tied
        to your team goals, focused on your audience, inspiring and concise.</p>

      <p>These are some real life examples of products that have been tried and tested;</p>
      <ul>
        <li>Design a system to manage the treatment and follow-up care of patients with clubfoot.</li>

        <li>Create an app that simplifies complex financial systems and pare them down to the essentials.</li>

        <li>Design a consistent mobile app across different platforms without sacrificing the brand.</li>
        <ul>
    </article>
  </section>

  <section class="main-section" id="-_Updating_your_Challenge_Statement">
    <header>- Updating your Challenge Statement</header>
    <article>
      <p> Once you have written several variations of the goal, present it to your team to get a consensus. You may want to include a deadline as this will help the team focus on the problem. So with the added adjustments, the list above could be:</p>
      <ul>
        <li>Design a system to manage the treatment and follow-up care of children under the age of 2 with clubfoot for launch in Q1 this year.</li>
        <li>Create a simple financial app that allows you to buy and sell shares at the tap of a button without prior knowledge of the financial world, with initial launch on July 2017.</li>
        <li>Produce a design guide that is flexible across multiple platforms and positions the company's brand effectively on each platform by the end of this year.</li>
      </ul>
      <p>When the challenge statement is finished, display it in a prominent place so that you can see it while you work. You will need to refer back to it constantly, perhaps even updating or modifying it throughout your project.</p>
    </article>
  </section>

  <section class="main-section" id="Validating_the_Problem">
    <header>Validating the Problem</header>
    <article>
      <p>The next step is to research the challenge and learn about the problem. What you need to discover is whether your team's understanding of the problem is valid. Quite often we look at problems from our own point of view, which is dangerous as most
        of us in tech are actually power users and are in fact a minority of users. We are a vocal minority and can be fooled into thinking something is actually a problem when it isn’t. </p>
      <p>This for example can often be seen in the way we assume by providing code that all users or readers would understand what we are trying to portray;</p>
      <p>
        <code>function greetMe(yourName) { alert("Hello " + yourName); }
        greetMe("World"); 
        </code>

        <code>if (true) { let y = 5; } console.log(y); // ReferenceError: y is not
defined
   </code>

        <code>const MY_OBJECT = {"key": "value"}; MY_OBJECT.key = "otherValue";
   </code>

        <code>if (condition_1) { statement_1; } else if (condition_2) { statement_2;
} else if (condition_n) { statement_n; } else { statement_last; }
   </code>

        <code>var n = 0; var x = 0; while (n < 3) { n++; x += n; }
                                            </code>
        <p> It is very easy to assume that your team would understand the code provided by you, but sometimes it is necessary to ensure that each member understands the concept by explaining the provided code. </p>
        <p>There are various methods of collecting data to validate your team's understanding of the challenge. Each one depends on your team and if you have access to users. The objective is to have a better understanding of the problem at hand.</p>
    </article>
  </section>

  <section class="main-section" id="-_Internal_Interviews_with_Stakeholders">
    <header>- Internal Interviews with Stakeholders</header>
    <article>
      <p>Interviews with stakeholders can be informative for discovering insights across a company or team. The interviewing process involves interviewing each team member and stakeholder at your company, from marketing to accounts. This will help you find
        what they think the real challenges are and what they think potential solutions could be. When I say solution I am not speaking about technical solutions here, but rather what would be the best case scenario and end goal for the company or product.
        For example using the challenges above “having our clubfoot software in 80% of medical facilities by the end of the year” would be a great goal to aim for.</p>
      <p>
        There is one caveat. This method of validation is the least favoured as it prevents team discussion and collaboration, potentially creating a siloed atmosphere in an organization. Nevertheless it can yield some good information about the clients and the
        design challenge that you could otherwise miss. </p>
    </article>
  </section>

  <section class="main-section" id="-_Lightning_Talks">
    <header>- Lightning Talks</header>
    <article>
      <p>
        This is similar to the internal interviews, but this time you get every stakeholder into a single room. Then you Elect five or six of those stakeholders (marketing, sales, design, accounts, research etc.) to give a talk, each focusing on the challenge
        from their perspective for a maximum of 10 minutes. The topics they must cover in their presentation should be:</p>
      <ul>
        <li>Goals of the business</li>
        <li>Challenges of the project from their point of view (these could be technical, research gathering, design creation etc..)</li>
        <li>User research that you have currently</li>
      </ul>
      <p>
        Leave 5 minutes at the end for questions, with an elected person taking notes throughout. Once you are done you might want to update the challenge to reflect new learnings. The goal is to collect a list of bullet points that can drive a feature or flow
        that helps your achieve your products goal.</p>
    </article>
  </section>

  <section class="main-section" id="-_user_interviews">
    <header>- User Interviews</header>
    <article>
      <p>User interviews are a great way to learn about a person's pain points in any given task. This is perhaps the best way of learning about the user's journey, pain points, and flow. Arrange at least five user interviews, more if you have access to
        them. The sorts of questions you ask them should include:</p>
      <ul>
        <li>How do they complete an existing task? For example, say you want to solve the challenge for the financial app above, you could ask them “how do you buy shares and stocks at the moment?”</li>
        <li>What do they like about this flow?</li>
        <li>What do they dislike about this flow?</li>
        <li>What similar products does the user currently use
          <ul>
            <li>What do they like?</li>
            <li>What do they dislike?</li>
            <li>If they had a magic wand and could change one thing about this process what would it be?</ul>
          </li>
      </ul>

      <p>The idea of interviewing is to get the user to speak about the challenges they have. It is not a discussion point for you, which is why you must remain as quiet as possible. This is even true when a user stops speaking, always wait a moment as they
        could be gathering their thoughts. You would be surprised at how much someone will continue to speak after they have stopped for a few seconds.</p>

      <p>Take notes throughout and if possible record the conversation to help you capture anything you might have missed. The goal is to compare the challenge to the user insights that you gather. Do they align? Did you learn anything that helps you update
        your challenge statement?</p>
    </article>
  </section>

  <section class="main-section" id="-_Ethnographic_Research">
    <header>- Ethnographic Research</header>
    <article>
      <p>Seeing users in their natural environment is a great way to understand how they solve their own challenges.</p>

      <p>This is where you observe the user in the field, in context while doing something like how they do their shopping, how they travel to work, how they send SMS messages etc.. The reason is in some cases people will tell you what they think you want
        to hear. But if you watch users perform actions and tasks on their own it can be insightful. Basically you are observing without interfering, noting things which they find easy or difficult and things they may have missed. The goal is to immerse
        yourself in the user's environment to better empathize with their pain points.</p>

      <p>This technique usually involves some work done over a longer period of time and requires a researcher to lead this part of the project. But it is perhaps the most insightful as you get to see a group of people that you are studying in their natural
        environments.
      </p>
    </article>
  </section>

  <section class="main-section" id="-_Gathering_it_Altogether">
    <header>- Gathering it Altogether</header>
    <article>
      <p>Once you have completed the learnings phase of your project you need to take one last look at your challenge. Are you on the right path? Is there anything you need to adjust? Write down all of the things you have learnt and group them into categories.
        These could become the basis of a feature or a flow, depending on the problem you are solving. They could also be used to update and revise the challenge.</p>

      <p>Once you have enough feedback and insight it is time to apply that knowledge to creating a project map.</p>
    </article>
  </section>

  <section id="More_Information">
    <article>
      <p>
        <a class="bottomlink" href="https://developers.google.com/web/resources/contributors/mustafa" target="blank">For more information please visit Mustafa Kurtuldu's site
        </a>
      </p>
    </article>
  </section>
</main>

<!-- 

Hello Camper!

For now, the test suite only works in Chrome! Please read the README below in the JS Editor before beginning. Feel free to delete this message once you have read it. Good luck and Happy Coding! 

- The freeCodeCamp Team 

-->