{
    "version" : "https://jsonfeed.org/version/1",
    "content" : "guides",
    "type" : "single",
    "title" : "Principle 1: Simple is hard |Digital.gov",
    "description": "Principle 1: Simple is hard",
    "home_page_url" : "/preview/gsa/digitalgov.gov/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/","feed_url" : "/preview/gsa/digitalgov.gov/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/guides/hcd/design-concepts/simple-is-hard/index.json","item" : [
    {"title" :"Principle 1: Simple is hard","date" : "2023-07-24T09:00:00-05:00","date_modified" : "2024-07-05T22:14:24-04:00","primary_image" : { "uid" : "hcd-design-concepts", "alt" :
  "A woman sits on top of a lightbulb surrounded by gears, graphs, and computers", "width" :
  "1200", "height" :
  "630", "credit" :
  "UnitoneVector/iStock via Getty Images", "caption" :
  "", "format" :
  "png" },"branch" : "cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings",
      "filename" :"simple-is-hard.md",
      
      "filepath" :"guides/hcd/design-concepts/simple-is-hard.md",
      "filepathURL" :"https://github.com/GSA/digitalgov.gov/blob/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/content/guides/hcd/design-concepts/simple-is-hard.md",
      "editpathURL" :"https://github.com/GSA/digitalgov.gov/edit/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/content/guides/hcd/design-concepts/simple-is-hard.md","url" : "/preview/gsa/digitalgov.gov/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/guides/hcd/design-concepts/simple-is-hard/","content" :"\u003cp\u003e“How long will this take?” has to be one of the most terrifying questions any designer will be asked when embarking on the design phase. The simple answer: one can’t know — but rational time constraints can be useful. What we do know, from years of experience and many design case studies, is that getting to a simple, easy-to-understand, and useful solution to any design problem is the result of many rounds of iteration, problem-solving, and testing. \u003c/p\u003e\n\u003ch2 id=\"budget-time-people-and-patience\"\u003eBudget time, people, and patience\u003c/h2\u003e\n\u003cp\u003eLeadership and clients should not expect a design solution to be completely finished in a month, especially if the team is working on multiple projects either together or apart, but rationally defining the term of the design phase can help.\u003c/p\u003e\n\u003ch3 id=\"making-decisions\"\u003eMaking decisions\u003c/h3\u003e\n\u003cp\u003eA successful design phase requires the team to make a lot of decisions. Some of these include: what to design, how to make a model or prototype of it, who to test with, how to test it, how to get on those peoples’ calendars, how long to wait before finding other people to test with, how to integrate their feedback, and how to move through iterations on that feedback.\u003c/p\u003e\n\u003cp\u003eThis process can be anxiety-inducing, as it means the design won’t meet all the needs of all the participants. This decision-making is, however, necessary. What a design team is trying to do is to make a precisely useful solution for a precise problem, not to make a large, unwieldy solution that tries (and fails) to solve all the problems encountered by the participants.\u003c/p\u003e\n\n\n\n\n\n\n\u003carticle class=\"dg-ring\" aria-labelledby=\"6af01956d79764115384b0ad6a89dbfb\"\u003e\n  \u003ch2 id=\"6af01956d79764115384b0ad6a89dbfb\" class=\"dg-ring__title\"\u003eCase in point\u003c/h2\u003e\n  \u003ch3 id=\"the-semester-model-as-a-rational-time-constraint\"\u003eThe semester model as a rational time constraint\u003c/h3\u003e\n\u003cp\u003eWe will go further into the details of scheduling a design phase in the \u003ca href=\"/preview/gsa/digitalgov.gov/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/guides/hcd/design-operations/\"\u003eHCD Design Operations Guide\u003c/a\u003e, but for now, one useful rule of thumb is based on a familiar time unit, the academic semester. The semester model can also be compared to “pics” in the Agile process. \u003c/p\u003e\n\u003cdiv class=\"box \"\u003e\n  Agile is a process for rapid, iterative digital product development, often used by developers and engineers. Learn more about the Agile process in \u003ca href=\"https://digital.gov/topics/agile/\"\u003eDigital.gov’s resources on Agile.\u003c/a\u003e\n\u003c/div\u003e\n\u003cp\u003eIn the semester model, timelines generally consist of twelve to fifteen weeks of continuous work. Graduate thesis-level design projects typically take an entire semester, with students primarily working on their own or with a tight team, and focusing on nothing else. If your team can follow this model (narrow focus on the immediate task), then a semester (12 - 15 weeks) might be a good timeline for producing design work that has been developed through an iterative process and tested with either one or two rounds of participants, depending on how easy it is to schedule time with them. At 12 weeks, you can reasonably be able to offer your leadership and stakeholders a (hopefully brief) report on your design phase, including iterations and testing, and share your plan to move into secondary testing and piloting. We’ll cover this process in more detail in the \u003ca href=\"/preview/gsa/digitalgov.gov/cms/news/2024/07/2024-07-02-case-study-increasing-access-to-required-bankruptcy-meetings/guides/hcd/design-concepts/feedback/\"\u003eFeedback section\u003c/a\u003e.\u003c/p\u003e\n\n\u003c/article\u003e\n\n"}
  ]
}