{"id":247,"date":"2013-05-25T16:20:23","date_gmt":"2013-05-25T23:20:23","guid":{"rendered":"http:\/\/edwinli.com\/ux-2020-09-28-archive-dev01\/?page_id=247"},"modified":"2016-01-14T16:35:05","modified_gmt":"2016-01-15T00:35:05","slug":"process","status":"publish","type":"page","link":"https:\/\/edwinli.com\/ux-2020-09-28-archive\/temp-portfolio\/process\/","title":{"rendered":"Design Processes, Artifacts, and Work Style"},"content":{"rendered":"

Design Processes, Artifacts, and Work Style<\/h1>\n
\"A<\/a>

A collage of my work artifacts: paper and whiteboard sketches, Balsamiq Mockups prototypes, Photoshop prototypes fed into interactive on-device prototypes, HTML\/CSS prototypes, and UI specifications.<\/p><\/div>\n

Design Processes, Artifacts, and Work Style<\/h1>\n

What Am I Like As A Designer?<\/h2>\n

How do I work, and what am I like to work with?<\/p>\n

There are many ways to answer that, and here are a few, more focused questions that should shed light on that overall question:<\/p>\n

    \n
  1. With what UX design processes am I conversant, and how flexible am I with those processes?<\/li>\n
  2. What artifacts do I typically produce in my design work?<\/li>\n
  3. How do I work with those around me, from other interaction designers and UX professionals to management, product management, developers, business stakeholders, marketing, legal, etc.?<\/li>\n<\/ol>\n

    Design Process and Artifacts<\/h2>\n

    I believe that there is no One True User Experience Design process, but, rather, many different approaches and tools with the same goal\u2014a design that “fits” with users’ behavior and how they think about their domain of activity.<\/p>\n

    There are quite a number of processes, frameworks, and tools that have been developed and articulated to get to that goal. These include Norman and Draper’s User-Centered Design<\/a>, Constantine and Lockwood’s Usage-Centered Design<\/a>, Alan Cooper’s Goal-Directed Design<\/a> (which pioneered the use of Personas), and Beyer and Holzblatt’s Contextual Design<\/a>.<\/p>\n

    I’ve used each of these and am familiar with them to varying degrees, but which one is the best to use? As with so many UX questions, the answer is, “It depends.” It depends on things like the UX team’s skills and background, the project’s timeline, the corporate environment (whether and how fully management supports UX priorities), the type of project or product, and many other factors.<\/p>\n

    So the best approach is familiarity and expertise in as many of these approaches and tools as possible, then choosing the ones that fit any given situation.<\/p>\n

    That said, the UX process of any particular project will generally have some subset of these general stages:<\/p>\n

      \n
    1. Domain research.<\/span> Are there aspects of the domain that may be identified as domain structure or constraints that may influence or be taken advantage of in the ultimate design? This is a phase in which the UX team learns about the things that matter in the domain for which they are designing the product. What things matter, how can they be used\/interacted with, how they influence each other, who has what rights to see, use, or edit what, how are these things and activities related to other tools, products, or processes that will be outside the scope of your product?<\/li>\n
    2. User behavior research.<\/span> How can users current behavior in the current domain-state be described? Does that behavior suggest positives or negatives with respect to accomplishing their goals within the domain? Are there regularities that may be taken advantage of when positive or done away with when negative? What tools do they use now? How are those tools embedded in the fabric of their activity or their activity “ecosystem”?<\/li>\n
    3. Market research.<\/span> Are there solutions already out there? What\u2019s out there that is related? How well do they support users in their activities and goals? How are they strong or weak with respect to your design and experience goals?<\/li>\n
    4. Digesting the data into design-useful artifacts.<\/span> This process may include diagramming, card sorting, Post-It note affinity diagrams\/sorting, and re-representing the notes and data in various ways. Products of this process may include diagrams, personas, scenarios, sketches, lists of problems, lists of requirements, usage models, content models, navigation models, task models (e.g., essential use cases<\/a>), etc. Of particular inspiration to me a this stage is a quote by Herbert Simon (from his book, Sciences of the Artificial, 3rd Edition<\/a>): \u201csolving a problem simply means representing it so as to make the solution transparent.\u201d<\/strong> This means trying many different approaches, framing and reframing the problem that you’re trying to solve in search of different ways to understand and capture the problem, choosing promising ones, creating designs to follow them, and iterating upon those, going as deeply as you need to in order to choose the most promising designs. This stage often blends and flows back and forth with the next stage, Design.\n
        \n
      1. Sample artifacts: Digesting data for personas\n\t\t